Guetzli doesn't seem to respect PNG color profiles

[jeffrey-friedl]

I don't know whether this is a problem with Guetzli, but I thought I'd report it. The attached PNG looks very different when its embedded color profile is respected, but Guetzli doesn't seem to respect it or include it (or any metadata) in the JPEG produced.

The resulting JPEG looks dark and drab... the color has shifted because the color data was assumed to be something (sRGB?) instead of being treated as the ProPhotoRBG that it is.

One could just copy the color profile over to the resulting JPEG, but since Guetzli takes into account human perception, one would assume that it should analyze the proper colors to begin with, so it should apply the color profile before actually inspecting the colors as data.....

[jan-wassenberg]

That's correct, we do assume sRGB. We have seen incorrect/broken PNG gAMA and JFIF ICC profiles, so interpreting them might be counterproductive. For the moment we've left it up to the user (who knows best what the inputs actually are) to convert to a known color space, i.e. sRGB.

[Smilebags]

How would implementing alternate color spaces work? Would it be possible to access the system color profiles by name? If so, (this would probably quite a bit of work) it might be possible to choose a color space with a parameter like --colorspace ProPhotoRGB

[robryk]

To add to what @jan-wassenberg said, the behaviour of image viewers is inconsistent here. Many browsers and desktop image viewers ignore color profiles in JPEG files. Some others (notably Preview on Mac) do take them into account.

@Smilebags That depends on whether we are considering color spaces close to SRGB, or very far from it. For spaces close to SRGB that would involve transforming to SRGB when we call Butteraugli. For spaces that are far away from SRGB, it would also involve retuning and/or modifying the coefficient importance heuristics.

[kornelski]

One more important thing to note is that JPEG has highest color precision in sRGB.

Any larger profile requires more than 8 bits of precision. While JPEG theoretically supports 12-bit mode, in practice all viewers support only 8-bit mode. So you either have to use sRGB or you will have lower quality image with posterization caused by stretching of values to fit the large color space. ProPhoto is especially terrible choice for 8-bit image formats.

[jeffrey-friedl]

Thanks for the reply @jan-wassenberg. If sRGB is assumed regardless of a specific indication otherwise, it might perhaps be good to at least mention it in the docs. Better still would be to recognize it and throw an error, to remind the user who might have forgotten to convert to sRGB.

@Smilebags (greatname), color profiles are included in the image, or (for two common, specific known color spaces) referenced by flags. This introduction to digital-image color spaces that I wrote 10 years ago still explains it well: http://regex.info/blog/photo-tech/color-spaces-page1

@robryk, it's true that not all software respects color profiles, but these days it's fair to say that most does. In any case, we're not talking about random software here, but software that specifically concerns itself with the perception of color, and of the visual quality of the result (not to mention that it's software from Google, which sets the bar high to begin with).

@pornel, I'm not sure what to make of "JPEG has highest color precision in sRGB", since at face value it's not true (One can certainly make a color space that describes fewer colors, thereby describing those it handles with more precision, which is great if all the image's colors can be represented). In any case, if an image contains colors that sRGB can not even describe, but ProPhotoRGB can, then ProPhotoRGB is anything but "terrible", so I don't understand the basis of your statements. I think you overestimate the effect of the larger color space here; indeed, for colors that both can describe, sRGB is slightly more precise, but I don't think it's possible to come up with an example image where the difference is expressed in "posterization" that a human can perceive. However, interpreting color data in a different space than it was created can be obviously manifest, as the example image I attached in the initial post demonstrates.

[Smilebags]

Great post, very informative. I'll do a test to see how much difference it'll make and post the results. Between sRGB and ProPhoto. The other thing is potential 16bit input support?

[ghost]

@pornel @jeffrey-friedlI understand both your points and ultimately agree with

but I don't think it's possible to come up with an example image where the difference is expressed in "posterization" that a human can perceive. However, interpreting color data in a different space than it was created can be obviously manifest, as the example image I attached in the initial post demonstrates.

...but ultimately compression takes place as a final step in image-delivery workflow and thus is in 99% of the cases bound to sRGB for the same reason you describe, any other color-space can easily ruin the image during conversion at the clients side

so I think resources are better spend on improving speed first, then improving speed and then worrying about color profiles

[Smilebags]

The issue is not about the limits of sRGB. The problem is with an incorrect mapping of colours. Colours can look way off if the colour profile is not respected. Sadly there is a lot of software which ignores colour profiles entirely.

I think we can all agree that the best output colour space is sRGB, since the primary use of this will be high quality images on the web, but being able to respect and use the input image's colour profile would be beneficial.

[jeffrey-friedl]

@Smilebags sums it up well... respecting profiles is nice if you can do it, but in the end sRGB makes the most sense for the vast majority of use cases. I'd just like to suggest that if sRGB is assumed, it be documented, or better yet, warn/die if non-sRGB is detected.

[jgrande35]

I've tried Guetzli for the first time and I'm still evaluating the difference in image quality and filesize. Not having the ability to set a profile is problematic. I've used a colorsync script to embed sRGB after the process but don't know if the script is re-compressing the file. Wish the image process would leave metadata and profile in place.

[robryk]

@jgrande35 Do I understand correctly that you are fine with the input and output being sRGB, but you want the output to contain an explicit sRGB color profile?

If so, could you say something more about the usecase? To the best of my knowledge JPEGs without an explicit color profile should always be assumed to use the sRGB color profile.

[jgrande35]

Hi Robryk, I want to keep the profile I embedded in the png prior to jpg processing. I'd rather use AdobeRGB, but sRGB is the web standard. So my workaround is to use a colorsync script to embed the profile post-jpg. Is there a way to keep Guetzli from stripping out the png's profile? Thanks.

[ghost]

so you want to keep the Adobe profile and then after compressing the file you want to convert from Adobe to sRGB?

Maybe convert first and the issue is solved (at least as a workaround)

[jeffrey-friedl]

@robryk , the bit about "assume sRGB if there's no profile" thing is a common practice borne out of practicality, but is certainly not any kind of "standard".

I don't know Google's intention in releasing this software, but it seems perfectly reasonable to say "it's a back-end tool built to demonstrate the library; the tool converts sRGB pixels", leaving any color conversion or profile handling to other parts of a pipeline a developer might set up.

That being said, it's easy enough to mark the output as sRGB (it can be marked as sRGB by reference via an Exif tag), but such a thing should never be done unless you know for certain that the input is sRGB. Incorrect data is worse than no data.