PNG8 colour support broken

[paperboyo]

Hello,

Please let me know, if this belongs in main application bug reports.

TLDR: Embed color profile checkbox in Export As... does not work correctly with PNG (Smaller File (8-bit)) option.

Irrespective of document colour space and the state of the above checkbox all PNG8 output contains sRGB (and gAMA!) chunks. Effectively and confusingly – Embed color profile is always ON and always embeds sRGB chunk even if the document is in e.g. ProPhotoRGB. This is dangerous and can result in widely wrong colour.

It’s also impossible to save a PNG8 file without an embedded profile (sRGB chunk).

To add insult to injury, latest Photoshop does not recognize sRGB chunks so treats all Export As... PNG8 output as Untagged on opening.

Latest Photoshop 2017.1.1 (Windows version tested) contains an outdated pngquant 2.1.1. Later versions support better colour management.

Also see: https://github.com/adobe-photoshop/generator-assets/issues/417

Unrelatedly, it would be mighty cool if Photoshop/Generator added controls over pngquant’s quality parameter.

Regards m.

Attached are files created in sRGB and ProPhotRGB colour spaces and saved via Export As... as PNG8 using different combinations of checkbox states. png8 Export As 2017.1.1 tests.zip

This is pngcheck output on zipped files

``` pngcheck.exe -v *.png File: ProPhoto_8_convert_embed.png (4611 bytes) chunk IHDR at offset 0x0000c, length 13 405 x 243 image, 8-bit palette, non-interlaced chunk iTXt at offset 0x00025, length 331, keyword: XML:com.adobe.xmp uncompressed, no language tag no translated keyword, 310 bytes of UTF-8 text chunk gAMA at offset 0x0017c, length 4: 0.45455 chunk sRGB at offset 0x0018c, length 1 rendering intent = perceptual chunk PLTE at offset 0x00199, length 765: 255 palette entries chunk tRNS at offset 0x004a2, length 254: 254 transparency entries chunk IDAT at offset 0x005ac, length 3139 zlib: deflated, 32K window, maximum compression chunk IEND at offset 0x011fb, length 0 No errors detected in ProPhoto_8_convert_embed.png (8 chunks, 95.3% compression). File: ProPhoto_8_convert_NOTembed.png (4611 bytes) chunk IHDR at offset 0x0000c, length 13 405 x 243 image, 8-bit palette, non-interlaced chunk iTXt at offset 0x00025, length 331, keyword: XML:com.adobe.xmp uncompressed, no language tag no translated keyword, 310 bytes of UTF-8 text chunk gAMA at offset 0x0017c, length 4: 0.45455 chunk sRGB at offset 0x0018c, length 1 rendering intent = perceptual chunk PLTE at offset 0x00199, length 765: 255 palette entries chunk tRNS at offset 0x004a2, length 254: 254 transparency entries chunk IDAT at offset 0x005ac, length 3139 zlib: deflated, 32K window, maximum compression chunk IEND at offset 0x011fb, length 0 No errors detected in ProPhoto_8_convert_NOTembed.png (8 chunks, 95.3% compression). File: ProPhoto_8_NOTconvert_embed.png (4611 bytes) chunk IHDR at offset 0x0000c, length 13 405 x 243 image, 8-bit palette, non-interlaced chunk iTXt at offset 0x00025, length 331, keyword: XML:com.adobe.xmp uncompressed, no language tag no translated keyword, 310 bytes of UTF-8 text chunk gAMA at offset 0x0017c, length 4: 0.45455 chunk sRGB at offset 0x0018c, length 1 rendering intent = perceptual chunk PLTE at offset 0x00199, length 765: 255 palette entries chunk tRNS at offset 0x004a2, length 254: 254 transparency entries chunk IDAT at offset 0x005ac, length 3139 zlib: deflated, 32K window, maximum compression chunk IEND at offset 0x011fb, length 0 No errors detected in ProPhoto_8_NOTconvert_embed.png (8 chunks, 95.3% compression). File: ProPhoto_8_NOTconvert_NOTembed.png (4611 bytes) chunk IHDR at offset 0x0000c, length 13 405 x 243 image, 8-bit palette, non-interlaced chunk iTXt at offset 0x00025, length 331, keyword: XML:com.adobe.xmp uncompressed, no language tag no translated keyword, 310 bytes of UTF-8 text chunk gAMA at offset 0x0017c, length 4: 0.45455 chunk sRGB at offset 0x0018c, length 1 rendering intent = perceptual chunk PLTE at offset 0x00199, length 765: 255 palette entries chunk tRNS at offset 0x004a2, length 254: 254 transparency entries chunk IDAT at offset 0x005ac, length 3139 zlib: deflated, 32K window, maximum compression chunk IEND at offset 0x011fb, length 0 No errors detected in ProPhoto_8_NOTconvert_NOTembed.png (8 chunks, 95.3% compression). File: sRGB_8_convert_embed.png (4347 bytes) chunk IHDR at offset 0x0000c, length 13 405 x 243 image, 8-bit palette, non-interlaced chunk iTXt at offset 0x00025, length 331, keyword: XML:com.adobe.xmp uncompressed, no language tag no translated keyword, 310 bytes of UTF-8 text chunk gAMA at offset 0x0017c, length 4: 0.45455 chunk sRGB at offset 0x0018c, length 1 rendering intent = perceptual chunk PLTE at offset 0x00199, length 759: 253 palette entries chunk tRNS at offset 0x0049c, length 252: 252 transparency entries chunk IDAT at offset 0x005a4, length 2883 zlib: deflated, 32K window, maximum compression chunk IEND at offset 0x010f3, length 0 No errors detected in sRGB_8_convert_embed.png (8 chunks, 95.6% compression). File: sRGB_8_convert_NOTembed.png (4347 bytes) chunk IHDR at offset 0x0000c, length 13 405 x 243 image, 8-bit palette, non-interlaced chunk iTXt at offset 0x00025, length 331, keyword: XML:com.adobe.xmp uncompressed, no language tag no translated keyword, 310 bytes of UTF-8 text chunk gAMA at offset 0x0017c, length 4: 0.45455 chunk sRGB at offset 0x0018c, length 1 rendering intent = perceptual chunk PLTE at offset 0x00199, length 759: 253 palette entries chunk tRNS at offset 0x0049c, length 252: 252 transparency entries chunk IDAT at offset 0x005a4, length 2883 zlib: deflated, 32K window, maximum compression chunk IEND at offset 0x010f3, length 0 No errors detected in sRGB_8_convert_NOTembed.png (8 chunks, 95.6% compression). File: sRGB_8_NOTconvert_embed.png (4347 bytes) chunk IHDR at offset 0x0000c, length 13 405 x 243 image, 8-bit palette, non-interlaced chunk iTXt at offset 0x00025, length 331, keyword: XML:com.adobe.xmp uncompressed, no language tag no translated keyword, 310 bytes of UTF-8 text chunk gAMA at offset 0x0017c, length 4: 0.45455 chunk sRGB at offset 0x0018c, length 1 rendering intent = perceptual chunk PLTE at offset 0x00199, length 759: 253 palette entries chunk tRNS at offset 0x0049c, length 252: 252 transparency entries chunk IDAT at offset 0x005a4, length 2883 zlib: deflated, 32K window, maximum compression chunk IEND at offset 0x010f3, length 0 No errors detected in sRGB_8_NOTconvert_embed.png (8 chunks, 95.6% compression). File: sRGB_8_NOTconvert_NOTembed.png (4347 bytes) chunk IHDR at offset 0x0000c, length 13 405 x 243 image, 8-bit palette, non-interlaced chunk iTXt at offset 0x00025, length 331, keyword: XML:com.adobe.xmp uncompressed, no language tag no translated keyword, 310 bytes of UTF-8 text chunk gAMA at offset 0x0017c, length 4: 0.45455 chunk sRGB at offset 0x0018c, length 1 rendering intent = perceptual chunk PLTE at offset 0x00199, length 759: 253 palette entries chunk tRNS at offset 0x0049c, length 252: 252 transparency entries chunk IDAT at offset 0x005a4, length 2883 zlib: deflated, 32K window, maximum compression chunk IEND at offset 0x010f3, length 0 No errors detected in sRGB_8_NOTconvert_NOTembed.png (8 chunks, 95.6% compression). No errors were detected in 8 of the 8 files tested. ```

[mcilroyc]

Thanks for the detailed bug report(s) @paperboyo. cc @chadrolfs.

[paperboyo]

Hi,

Still not fixed in CC2018 (19.0.0, Mac): pngquant is at 2.2, so a tad less outdated, but the problems with PNG8 still persist :sadpanda:.

Something for probably another place, but it looks like Photoshop itself morphed from not being able to recognise sRGB PNG chunks at all to suddenly seeing them everywhere (in Untagged images devoid of these chunks). Kind of goes more hand-in-hand with broken Generator now, I suppose 😉.

Regards m.

[paperboyo]

pngquant is at 2.2

Still at 2.1.1 on Windows (19.0.0). Windows version also differs now from a Mac one in not being able to recognise sRGB chunks in PNGs saved out using Export As, Smaller File, Embed Profile option.

[paperboyo]

Also the new overhauled PNG support through Save As... lost the ability to embed colour profiles completely compared to earlier versions.

[EDIT: Apologies, only images in sRGB colour space cannot have profiles embedded through Save As... Owl is a bit less surprised. Just a bit.]

[fosterbrereton]

This was a conscious decision to omit sRGB color profiles from PNG in the event the PNG was encoded in sRGB. Please see part of the rationale here.

[paperboyo]

This was a conscious decision to omit sRGB color profiles from PNG in the event the PNG was encoded in sRGB.

Oh, oh, totally wanted to repeat the owl! Twice! 😄 Please treat this just as a discussion, feel free to close whenever and thank you for responding!

I see two issues here:

1. A strategy, in line with the times but also with specs, safe but not overly constraining. Here, I do not agree with the decision, but there are pros and cons. Cons and discussing the partial rationale – below.
2. Having a consistent operation and philosophy within the application, checkboxes doing what they say they do, app recognising its own output, giving users the same choices in similar scenarios. Here, the problems are much more objective.

Ad. 2. Currently, the checkboxes are misleading, produce output that differs from the other file formats or other parts of the app for the same file format, they realise the same thing differently (oversized iCCP or sRGB chunk) or they simply don’t do what they say they will. Mac and Windows version behave differently (and both are wrong). Even if the decision is final, I think there are things to be fixed (and checkboxes to be greyed out). I hope it might be reversed, though, you never know, Timo and Gernot got their Linear Gamma in Colour Settings years after The Gamma Flame Wars, ask Mr. Cox 😉. Photoshop is not an unmanned one-click-shop, it should protect me, but without taking away the freedom.

Ad 1. This decision means:

• no predictability and no control over whether one wants to protect the colour (embed) or match the CSS/else for dumb clients (leave untagged)
• wrong colour at default Firefox settings, the more wrong, the wider the gamut
• ditto for all Chrome versions but the very last one
• danger of misinterpreting PNGs – and a sure misinterpretation when just clicking OKOKOK – whenever one’s Colour Settings are set to sth other than sRGB, including all default press-related original Colour Settings presets (yes, they ask what to do with untagged images by default, but can we expect users to make a good decision here if we don’t trust them when saving PNGs?). And no, I don’t think hiding the problem by misinterpreting untagged PNGs as sRGB silently (sic! only on a Mac!) is the right solution

I respectfully disagree with my esteemed colleague @pornel on some of the recommendations and reasoning presented in the above link.

Not wanting to bloat this post any more and discussing this here in His absence, I prefer to quote other parts of his excellent site:

Non-standard and filesize-heavy embedded color profiles are converted to most efficient, minimal alternative profiles.

&

When necessary, ImageOptim API embeds a custom, very small ICC color profile in photo files for accurate color reprduction on wide-gamut displays.

In my humblest of opinions, the only proper way forward re:PNG colour for the app as sophisticated as Photoshop is what’s at the bottom of this thread, if only for consistency. Unless the whole of the ocean liner will be slowly hijacked and will steer in this questionable, safe, and, ultimately, boring destination.

BTW, Export As… being able to not only use sRGB chunks for PNG but a minimal sRGB-compatible ICC profile for JPG (as, most unfortunately, DCF EXIF is not widely recognised), would be mighty cool! And sliders for pngquant quality! More, not less 😜!

Thank you for the great tool!

Regards m.

[paperboyo]

While some of the original issues reported seems fixed, not everything is.

This was a conscious decision to omit sRGB color profiles from PNG in the event the PNG was encoded in sRGB

So this decision was retracted in version 23.0. Very good decision (the retraction, that is). Firefox still hasn’t fix its colour management… The owl is happy.

Sadly, despite Release notes advertising

Improved 'Export As': Better color profile handling

colour profile support while saving PNGs is still having trouble with grayscale imagery. As an example, the Export As… despite having Convert to sRGB unchecked (and Embed Color Profile checked) embeds sRGB profile in a PNG Gray Gamma 1.8 or Dot Gain 20% grayscale images…

Export As… still doesn’t know how to shave off 2,6KB by writing sRGB chunk instead of a full profile. Photoshop still can’t understand sRGB chunk on opening a PNG image. Pngquant is still 7 years old. Adobe expressed interest in supporting JXL. I’m excited. But I worry a bit too…

Closing as lost hope… and it wasn’t the most correct place for these owls anyhow.