1249250 - Displaying a PNG image with an ICC profiles disables color management

Status: RESOLVED FIXED

(Core :: Graphics: Color Management, defect)

Description

[etienne.sandre]

Attachment: images.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

I displayed PNG images encoded in a wide gamut color space (Prophoto RGB). The gfx.color_management.mode is 1 (default)

 - Image 1 contains the chromaticities information (PNG cHRM block)
 - Image 2 contains the chromaticities and an embedded ICC profile (PNG iCCP block)
 - Image 3 is reference, encoded in standard sRGB

Images 2 and 3 are displayed properly in Adobe Photoshop, which recognizes the ICC profile. Image 1 is not color managed properly by photoshop, which works with ICC profiles only, and not with simple chromaticities tags.




Actual results:

Image 1, which has chromaticities information (cHRM info), is properly color managed and displayed with good colors

Image 2 (cHRM and iCCP information) is not color managed by photoshop, and the image looks totally wrong as ProphotoRGB is a very wide gamut space

This shows that firefox handes well custom chromaticities coordinate tags in PNG files, but it stops doing so when there is an ICC profile. The ICC profile is not handled properly.


Expected results:

The three images should have looked identical

Comment 1

[Benoit Girard (:BenWa)]

I bet it uses a ICCv4 profile with a color lookup table and doesn't provide TRC curves. We've had an experimental mode behind 'gfx.color_management.enablev4' but no one has been able to fix the performance blocker issues.

Comment 2

[etienne.sandre]

There is a typo, one should read firefox instead of photoshop at the end.

Correct comment:

 - Image 1 contains the chromaticities information (PNG cHRM block)
 - Image 2 contains the chromaticities and an embedded ICC profile (PNG iCCP block)
 - Image 3 is reference, encoded in standard sRGB

Images 2 and 3 are displayed properly in Adobe Photoshop, which recognizes the ICC profile. Image 1 is not color managed properly by photoshop, which works with ICC profiles only, and not with simple chromaticities tags.




Actual results:

Image 1, which has chromaticities information (cHRM info), is properly color managed and displayed with good colors

Image 2 (cHRM and iCCP information) is not color managed by firefox, and the image looks totally wrong as ProphotoRGB is a very wide gamut space

This shows that firefox handes well custom chromaticities coordinate tags in PNG files, but it stops doing so when there is an ICC profile. The ICC profile is not handled properly.


Expected results:

The three images should have looked identical

Comment 3

[Benoit Girard (:BenWa)]

Attachment: image2.icc

~/Downloads/images> convert image1.png image1.icc
convert: no color profile is available `image1.icc' @ error/meta.c/WriteMETAImage/2321.
~/Downloads/images> convert image2.png image2.icc
(attached)
~/Downloads/images> convert image3.png image3.icc
convert: iCCP: too many profiles `image3.png' @ warning/png.c/MagickPNGWarningHandler/1832.
convert: no color profile is available `image3.icc' @ error/meta.c/WriteMETAImage/2321.

Comment 4

[Benoit Girard (:BenWa)]

image2.icc only contains TRC. We might be rejecting it as invalid in our sanity checking.

Comment 5

[etienne.sandre]

The primary issue is not that firefox can't handle some types of ICC profiles. But when he can't handle the profile, it should fall back to the chromaticities attributes instead of skipping color management.

Comment 6

[Benoit Girard (:BenWa)]

That sounds reasonable. Thanks for clarifying.

Comment 7

[Tine Gornik]

I can confirm same problem.
I use 48 - 64 bit png's ( ProPhoto RGB profile ) for photography but newer versions of firefox ignore all profiles stored in PNG files.

If i use FireFox 28 or latest chrome version, everything works fine, but not in new firefox.
I can't understand how very old FireFox version 28 works perfectly fine and always uses embedded profiles, newer just ignores all profiles and sets everything to sRGB.
This was working perfectly fine before in FireFox 28, but new FireFox breaks it. :(

Examples:
http://www.spcphoto.com/

FireFox 28 vs FireFox 47 x64:
https://support.cdn.mozilla.net/media/uploads/images/2016-06-15-19-07-00-a94d78.png

I also reporter this problem here:
https://support.mozilla.org/en-US/questions/1127354

Comment 8

[Tine Gornik]

Latest working version of FireFox is 33.1.1
Color management breaks in FireFox 34.0 Beta 1

Comment 9

[Glenn Randers-Pehrson]

I've pushed a patch to libpng-1.6.24beta03 GIT repository that fixes this bug for image2.png.  image3.png is invalid because the PNG format does not allow both the iCCP chunk and the sRGB chunk to be present, so the sRGB chunk gets discarded.

Comment 10

[etienne.sandre]

(In reply to Glenn Randers-Pehrson from comment #9)

The PNG specification DOES allow iCCP and sRGB chunk. Where did you get this information from?

From the ISO/W3C PNG specification:

"An sRGB chunk or iCCP chunk, when present and recognized, overrides the cHRM chunk"

http://www.libpng.org/pub/png/spec/iso/index-object.html#11cHRM

Comment 11

[etienne.sandre]

Oops, apologies, I misread your comment. This was about iCCP+sRGB, not iCCP+cHRM

The specification is not as strict as you say but recommends not to combine these chunks:

"It is recommended that the sRGB and iCCP chunks do not both appear in a PNG datastream"

Comment 12

[Glenn Randers-Pehrson]

Right, it is a recommendation.  libpng16 discards the sRGB chunk if both iCCP and sRGB are present, and issues a warning (by default, firefox discards warnings, so you have to enable logging to see any libpng warnings).  It's undefined which chunk should be discarded; if both are present, libpng16 always discards sRGB. So does libpng12. pngcheck keeps whichever appears first in the file and discards the other.

Comment 13

[Glenn Randers-Pehrson]

Some of your images have a cHRM chunk but no gAMA chunk.  Firefox only uses the cHRM chunk if gAMA is also present, to create a color profile (see image/decoders/nsPNGDecoder.cpp, around line 487):

  // Check gAMA/cHRM chunks
  if (!profile &&
       png_get_valid(png_ptr, info_ptr, PNG_INFO_gAMA) &&
       png_get_valid(png_ptr, info_ptr, PNG_INFO_cHRM)) {
    qcms_CIE_xyYTRIPLE primaries;
    qcms_CIE_xyY whitePoint;

    png_get_cHRM(png_ptr, info_ptr,
                 &whitePoint.x, &whitePoint.y,
                 &primaries.red.x,   &primaries.red.y,
                 &primaries.green.x, &primaries.green.y,
                 &primaries.blue.x,  &primaries.blue.y);
    whitePoint.Y =
      primaries.red.Y = primaries.green.Y = primaries.blue.Y = 1.0;

    double gammaOfFile;

    png_get_gAMA(png_ptr, info_ptr, &gammaOfFile);

    profile = qcms_profile_create_rgb_with_gamma(whitePoint, primaries,
                                                 1.0/gammaOfFile);

    ...
  }

Comment 14

[Glenn Randers-Pehrson]

Attachment: v00-1249250-fix-multiple-iCCP-sRGB-handling

The v00 patch is the same as what will appear in libpng-1.6.24

Comment 15

[Glenn Randers-Pehrson]

Fixed when bug #1291986 (update intree libpng to version 1.6.24) landed.