Sdwebimage: GIF loads rotated if imageview was previously used to load JPG

[ericeddy]

New Issue Checklist

• [x] I have read and understood the CONTRIBUTING guide
• [x] I have read the Documentation
• [x] I have searched for a similar issue in the project and found none

Issue Info

Info | Value |
-------------------------|-------------------------------------|
Platform Name | ios
Platform Version | 10+
SDWebImage Version | 4.4.2
Integration Method | cocoapods
Xcode Version | Xcode 9.4
Repro rate | 100% given the steps
Repro with our demo prj | - -
Demo project link | - -

Issue Description and Steps

When I load a Gif into the same FLAnimatedImageView that was previously used to load a JPG(which was taken with the camera), the gif appears to be rotated. But if I load that same cached Gif without it previously loading the JPG, the Gif isn't rotated.

This is happening in a tableview which has tableviewcells that have FLAnimatedImageView's on them.

• Have a table view with cells that are half the screen tall ( makes the cell reloading happen quicker )
• Have a data source provide 5 gif urls and then 5 Jpg urls
• Open the VC, see the Gifs load and play properly
• Scroll to the Jpgs, see them load and display properly
• Scroll back to the Gifs, any cell that was previously displaying a Jpg will now be displaying their Gif rotated

Similar Issue: https://github.com/rs/SDWebImage/issues/1317

From what I've found in my searches this has something to with the JPG having EXIF metadata and the Gif not, but I'm unsure what I can do to fix the issue.

One of the JPG's causing the issue: https://skrumble-dev-assets.s3.amazonaws.com/chats/5b4cadeaf1ad970f5063416b/4744214435480065278.jpg

[ericeddy]

Even easier way to reproduce it is,
I select a JPG from my Photo library & load it into an image view, then I select a gif from my photo library and load it into the same image view, the displayed Gif is rotated.

[dreampiggy]

It seems a FLAnimatedImageView bug. UIImageView and our decoder always process the EXIF to image orientation correctly.

Could you please help to provide a demo that can trigger this issue ? Maybe we can figure it out quickly.

[ericeddy]

Here's a test repo link:
https://github.com/ericeddy/FLAnimatedImage-RotationIssue

I've noticed that using just any jpg doesn't cause it, like random jpgs from the internet cause it to occur sporadically,
But using images taken with the phone's camera will cause it 100% of the time, and using a landscape photo vs using a portrait photo will add an extra 90 degrees to the rotation

[dreampiggy]

@ericeddy After some test and my experiment, I can confirm it's a BUG in FLAnimatedImage third party library itself. I've create a MR to the FLAnimatedImage repo. You can push them to merge it and solve this problem.

Now I can talk about the reason that cause this problem. At first, you should have basic knowledge of UIView-CALayer, if you don't know them, you should watch Understanding UIKit Rendering before reading the below.

What cause this problem

FLAnimatedImageView, it's a UIImageView subclass, which manually specify CALayer.contents with the current rendering frame's CGImage. And they use a CADisplayLink as a timer, to refresh current frame, finally produce the visual animation.

However, CALayer itself, contains a private property, called contentsTransform. You can check the private header of CALayer. CALayer will calculate current UIImage.imageOrientation and translate to CGAffineTransform to render the bitmap. Why they to do this it's because it does not actually take rotation on CGImage's bitmap when you create UIImage with -[UIImage imageWithCGImage:scale:orientation:], The both scale and imageOrientation are just hint to the CALayer's property contentsScale and contentsTransform. So that CALayer use the contentsTransform to actually do rotation about the bitmap.

Which means, actually, CALayer draw its contents, based on the both public CALayer.transform and private CALayer.contentsTransform two properties.

See the screenshot during View Debug and print out the CALayer information. The actually CALayer.contents bitmap show the correct orientation, but the rendering result cause a rotation because the CALayer contains a contentsTransform = CGAffineTransform (0 1.06667; -0.9375 0; 375 0), which is a right-90 degress rotation.

After I use KVO to observe this contentsTransform changes, I found that the only write on this property was happend on -[UIImageView setImage:] function call with a non-nil UIImage. The non-nil is really important, when you sepcify nil, the contentsTransform property leave there without reset to identity transform. (Because UIKit assume you don't touch layer.contents and so they don't need to reset the state)

So now, you may know the reason now. Correct, the previous JPEG image which contains non-Up image orienation will change the conrtentsTransform, but the newly set FLAnimatedImage does not clear that transform, cause the final rotation. I check the current FLAnimatedImage code and finally find the bug. The root case is that -[FLAnimatedImage setAnimatedImage:] does not do the correct thing, to reset the super UIImageView state about image.

- (void)setAnimatedImage:(FLAnimatedImage *)animatedImage
{
    if (![_animatedImage isEqual:animatedImage]) {
        if (animatedImage) {
            // Clear out the image.
            super.image = nil;   // -> This will not reset `contentsTransform`, not actually "Clear out the image."
            // Ensure disabled highlighting; it's not supported (see `-setHighlighted:`).
            super.highlighted = NO;
           //...
    }
}

Solution

The naive solution, it's quite simple, firstlly call super.image = non-nil image and then call super.image = nil. Only one line code and the issue disappear.

--- a/FLAnimatedImage/FLAnimatedImageView.m
+++ b/FLAnimatedImage/FLAnimatedImageView.m
@@ -101,6 +101,7 @@
 {
     if (![_animatedImage isEqual:animatedImage]) {
         if (animatedImage) {
+            // Reset `contentsTransform` state
+            super.image = animatedImage.posterImage;
             // Clear out the image.
             super.image = nil;
             // Ensure disabled highlighting; it's not supported (see `-setHighlighted:`).

From my personal opinion, I think they should always call [super setImage:] during [FLAnimatedImageView setAnimatedImage:]. If you don't call super, you may loss internal consistent behavior during subclass. But anyway, this fix is much simpler.

Current workaround ?

Yes. FLAnimatedImage seems no longer maintained, though I fire the PR, it may take long time to merge in (or may be forever :) ). And it's the why we create our Animated Image solution in SDWebImage 5.0.0-beta.

For our FLAnimatedImage+WebCache, the simple way to fix this, it's just use the code above, call super.image = animatedImage.posterImage before super.animatedImage = animatedImage. I will create another PR fix for SDWebImage/GIF subspec.

[dreampiggy]

@ericeddy See #2406. The fix (hack) from ourself to solve the problem :)

And is there anyone who also face this issue ? You can push FLAnimatedImage team (I don't know whether they still maintain that repo or not) to merge the PR. It can solve the bug from the root case, instead of hacking code from our user level.

[ericeddy]

Thank you for such a thought out and fast response!
I think for the meantime I'm going to go ahead with your suggestion and use 5.0.0-beta, I tried out how it works in the demo and it seems to be working well,

Again, Thank you for all this work, I really appreciate it!