iphone screen shot(png) fails to decode

[lidarbtc]

This happens in , only iphone screen shot.

picture with iphone camera -> work well
png, jpeg and etc.... -> work well
but iphone screen shot(png) -> not work

Expected

expected = work well with decode.

Actual behaviour

thread 'rocket-worker-thread' panicked at 'called `Result::unwrap()` on an `Err` value: Decoding(DecodingError { format: Exact(Png), underlying: Some(Format(FormatError { inner: DuplicateChunk { kind: ChunkType { type: iCCP, critical: false, private: false, reserved: false, safecopy: false } } })) })', src/main.rs:304:22

this bug will procced with only "row iphone screenshot"
if I edit(like a crop... blur... etc...) screenshot with iphone photo app -> work well.

Reproduction steps

let mut img = ImageReader::open(format!("./static/images/{}.png", imagename))
                    .unwrap()
                    .decode()
                    .unwrap(); <- error!

[HeroicKatora]

Looks like it's embedding two iCCP (color management) chunks, which is invalid. Most likely, the editing software takes one of them out of the image before resaving. Do you have an example file to verify?

[kangalio]

I'm also running into this problem in my project. Can reproduce in a blank project with

fn main() {
    image::open("wafles-mine.png").unwrap();
}

and the following file:

Versions:

• image 0.24.5
• png 0.17.7

[HeroicKatora]

$ pngfix /tmp/203021635-572a99fb-cf36-4a89-8281-58328567cec3.png 
zTXt OK  maximum 15 15 10002 21457 /tmp/203021635-572a99fb-cf36-4a89-8281-58328567cec3.png
iCCP OK  default 15 15 2595 3144 /tmp/203021635-572a99fb-cf36-4a89-8281-58328567cec3.png
iCCP OK  default 12 12 2595 3144 /tmp/203021635-572a99fb-cf36-4a89-8281-58328567cec3.png
IDAT OK  maximum 15 15 4987 16448 /tmp/203021635-572a99fb-cf36-4a89-8281-58328567cec3.png

This is supposed to be valid?

Unless a cICP chunk exists, a PNG datastream should contain at most one embedded profile, whether specified explicitly with an iCCP or implicitly with an sRGB chunk.

Suppose we interpret should too strongly and should rather ignore the duplicate? After all, the chunk is technically not critical but that seems like a potential hazard to me if we only report one.

An iCCP chunk contains zlib/deflate compressed data. The two chunks are both identified as Photoshop ICC profile and start with bytes 48 89 and 78 9C respectively, meaning two different compression settings had been used in their creation. Still, most data actually ends up being the same. Is that the same data, which is short enough to be mostly unaffected by the window size?

[kangalio]

Suppose we interpret should too strongly and should rather ignore the duplicate?

I think so

Still, most data actually ends up being the same. Is that the same data, which is short enough to be mostly unaffected by the window size?

I'm not sure what data you mean here. The zlib/deflate compressed data of the iCCP chunk? What does it have to do with the window size? (disclaimer: I haven't delved into image formats before)

[kangalio]

That issue has only started happening with 0.17.4, which makes sense, because image-rs/image-png#334 was merged by then

[anforowicz]

FWIW, it seems that the reference implementation ignores subsequent iCCP chunks https://github.com/glennrp/libpng/blob/f8e5fa92b0e37ab597616f554bee254157998227/pngrutil.c#L1396-L1407 and treats them as a benign error https://github.com/glennrp/libpng/blob/f8e5fa92b0e37ab597616f554bee254157998227/pngrutil.c#L1623-L1633.

IIUC this is unlike the PR at image-rs/image-png#361 which replaces the iCCP info with the latest encountered iCCP chunk.