iOS 17/macOS 14 PNG image render wrong by default, only works when disable force decode

[DaoPinWang-git]

original image

display image

[dreampiggy]

At least, you need to provide a sample URL for reproduction and debug...

Also, the issue template should provide the version of SDWebImage and iOS version you used

[DaoPinWang-git]

@dreampiggy sorry...

    lazy var cImageView: UIImageView = {
        let imageView = UIImageView()
        imageView.sd_setImage(with: URL(string: "https://user-images.githubusercontent.com/18020236/269165495-6a0069f8-582c-4faf-81ae-49879df63af9.png")) { image, _, _, url in

        }
        return imageView
    }()

image url: https://user-images.githubusercontent.com/18020236/269165495-6a0069f8-582c-4faf-81ae-49879df63af9.png

iOS: 17.0; SDWebImage: 5.18.1

[dreampiggy]

Seems not reproducible in our SDWebImage Demo.

I guess it's because your own project's code, for example you use some template image or filter, dark mode (with alpha image) which effect the rendering result.

You can compare the rendering result with MacOS or iPhone native Preview.app to see the differences.

[DaoPinWang-git]

@dreampiggy You need to use iOS 17 debug

[dreampiggy]

I mean, is this behavior different from Apple's other native App ? Like Photos or Preview, and even on macOS 14 and tvOS 17

If not, it's not SDWebImage's bug, it's Apple's bug, you'd better to fire radar to Apple

---

Give you a simple demo code, without any use of SDWebImage at all

let data = Data(url: URL(string: url))!
let image = UIImage(data: data)!
imageView.image = image

Is this render issue still not correct ?

[dreampiggy]

Or you can choose not to use ImageIO (Apple's Image decoder), use the open-source libpng instead.

https://github.com/glennrp/libpng

[dreampiggy]

TestPNGRender.zip

Give you the demo and run by yourself, is this behavior different from SDWebImage ? Note the background view use .black color and your PNG contains alpha channel

[dreampiggy]

I guess this is not bug. The PNG is alpha image so it can blend with the background. I don't think these two render result is different, because They are on different background

You should not use that lldb debugger render to blame me, it has another background view which is grey, not the white one

[DaoPinWang-git]

sorry my fault，i tried to download the image using the iOS API, but got a different result from SDWebImage

    imageView1.frame = CGRect(x: 10, y: 110, width: 295, height: 73)
    view.addSubview(imageView1)
    
    imageView2.frame = CGRect(x: 10, y: 200, width: 295, height: 73)
    view.addSubview(imageView2)
    
    
    imageView1.sd_setImage(with: URL(string: "https://user-images.githubusercontent.com/18020236/269165495-6a0069f8-582c-4faf-81ae-49879df63af9.png")) { image, _, _, url in
    }
    
    
    let url = URL(string: "https://user-images.githubusercontent.com/18020236/269165495-6a0069f8-582c-4faf-81ae-49879df63af9.png")!

    let session = URLSession.shared
    let task = session.dataTask(with: url) { (data, response, error) in
        if let error = error {
            print("Error: \(error)")
            return
        }
        
        guard let data = data,
              let image = UIImage(data: data)
              else {
                print("Invalid image data")
                return
        }
        
        DispatchQueue.main.async {
            self.imageView2.image = image
        }
    }

    task.resume()

in iOS 16.4 simulator

in iOS 17.0 simulator

[dreampiggy]

Disable the force decode and try again. Use that "avoidDecodeImage" options (or use new API called context[.forceDecodePolicy] = .never)

SDWebImage by default actually just do simple:

1. Use ImageIO to decode Data into UIImage
2. Use UIGraphicsImageRenderer to force-decode (because the ImageIO returned back CGImage is lazy, we mostly do not want lazy for Web images)

I guess this maybe something bug of CoreGraphics

I will test again on my demo later. Note: SDWebImage supports file URL as well, so we don't need URLSession or any network, just put that image into App bundle and load via fileURL to compare render result

[dreampiggy]

Can reproduce on iOS 17 simulator. There are render differences when enable/disable force decode (via avoidDecodeImage or imageForceDecodePolicy)

See:

Enable Force Decode (default)

Disable Force Decode

Change Force Decode Solution

SDImageCoderHelper.defaultDecodeSolution = .uiKit

You can also use this to force enable the UIKit (UIImage.prepareForDisplay) decode solution, which also works. Only the old CoreGraphics based decode solution does not work.

[DaoPinWang-git]

thx!!! 👏👏👏 🎉🎉🎉

[dreampiggy]

Open currently, seems need to fire radar to Apple or find some way for better workaround.

[dreampiggy]

Decide to upload this to Apple for radar:
TestPNGRender.zip

[dreampiggy]

FB13196663

[lyandy]

It seems like there are some bugs in UIGraphicsImageRenderer
A very simple demo is here: ios_17_image_test
It's not SDWebImage's bug

[dreampiggy]

Update:

It's not bug of UIKit team actually :)

It's bug of ImageIO team

The decoded CGImage contains Wrong BitmapInfo, which store the RGB into pre-multiplied form (which means, each R is actually R * Alpha).

It should use the kCGImageAlphaPremultipliedFirst or kCGImageAlphaPremultipliedFirst to indicate the consumer (We and UIKit team), but however, then return the kCGImageAlphaLast or kCGImageAlphaFirst, which means it's not pre-multiplied.

A stupid and shit code quality.

[dreampiggy]

New Demo code

TestPNGRender.zip

Left iOS 16, Right iOS 17

The first RGB pixel value is not equal, the iOS 17 one seems Premultiplied the alpha value, which makes each pixel RGB become smaller (or in visible, ligher)

[dreampiggy]

The alphaInfo shows the CGImage use RGBA8888 and non-premultiplied

Check the first pixel value

iOS Version	16	17
R	154	30
G	231	45
B	231	45
A	50	50

Compare

Each R in iOS 17 is the premultiply result of R in iOS 16. But CGImage still report non-premultiplied

30 = 154 * (50 / 255)
45 = 231 * (50 / 255)
45 = 231 * (50 / 255)

[dreampiggy]

Apple still don't reply for this issue. And this Bug exits on iOS 17.2 Beta 1🤮
I re-submit with a new radar FB13322401
https://github.com/dreampiggy/iOS17IndexedPNGDecodeBug

[dreampiggy]

This should be fixed (hacked) by #3634

[dreampiggy]

Finally released 5.18.5

@DaoPinWang-git @lyandy Please have a try. This workaround only make all PNG decoded from SDWebImage works, but not using the hook for system SDK, which need Apple to fix.

[jiangxiaopeng]

Finally released 5.18.5

@DaoPinWang-git @lyandy Please have a try. This workaround only make all PNG decoded from SDWebImage works, but not using the hook for system SDK, which need Apple to fix.

upgrade 5.18.5, our debug ipa no problem, but the testflihgt ipa not fix

[jiangxiaopeng]

Finally released 5.18.5
@DaoPinWang-git @lyandy Please have a try. This workaround only make all PNG decoded from SDWebImage works, but not using the hook for system SDK, which need Apple to fix.

upgrade 5.18.5, our debug ipa no problem, but the testflihgt ipa not fix

@dreampiggy

[dreampiggy]

Finally released 5.18.5

@DaoPinWang-git @lyandy Please have a try. This workaround only make all PNG decoded from SDWebImage works, but not using the hook for system SDK, which need Apple to fix.

upgrade 5.18.5, our debug ipa no problem, but the testflihgt ipa not fix

What's the difference between testflight build ? I means maybe about the real device or simulator

Apple may optimize different image format based on Hardware media codec, so make sure you test on the same devices...

[dreampiggy]

@jiangxiaopeng
Or if you believe this is still something not handled by SDWebImage, provide a demo for me to invesitgate using the real device. (Also, with your iPhone model and OS version)

I guess there are something mismatch between simulator and real device

[dreampiggy]

@jiangxiaopeng

You're correct. Use 5.18.9, the final old PR contains typo and only enabled in Debug configuration 😃

[jiangxiaopeng]

hah, It's not SDWebImage's bug,

[MichaelSSY]

Can reproduce on iOS 17 simulator. There are render differences when enable/disable force decode (via avoidDecodeImage or imageForceDecodePolicy)

See:

Enable Force Decode (default)

## Disable Force Decode ## Change Force Decode Solution 

SDImageCoderHelper.defaultDecodeSolution = .uiKit

You can also use this to force enable the UIKit (UIImage.prepareForDisplay) decode solution, which also works. Only the old CoreGraphics based decode solution does not work.

I have found that if placeholderImage is set, there may still be issues. Could you please help me check the following settings:

let URL=URL (string:“ https://user-images.githubusercontent.com/18020236/269165495-6a0069f8-582c-4faf-81ae-49879df63af9.png )!
let image=SDImageCache. shared. imageFromCache (forKey: URL. absoluteString)
self. imageView1. sd_setImage (with: URL, placeholderImage: image, options: [. avoidDecodeImage])

[MichaelSSY]

It's strange. The image cached on the disk looks normal, but once it's taken out, there will be a problem displaying it

let url = URL(string: "https://user-images.githubusercontent.com/18020236/269165495-6a0069f8-582c-4faf-81ae-49879df63af9.png")!
let image = SDImageCache.shared.imageFromCache(forKey: url.absoluteString)
self.imageView2.image = image