https://bugs.kde.org/show_bug.cgi?id=367832

Elle Stone <e...@ninedegreesbelow.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |e...@ninedegreesbelow.com

--- Comment #13 from Elle Stone <e...@ninedegreesbelow.com> ---
(In reply to Tyson Tan from comment #0)

> 9)  . . . Adobe Photoshop's sRGB
> embedded picture is not affected because Photoshop embeds the official sRGB
> profile from ICC. Krita is affected because sRGB-elle-V2-srgbtrc.icc is not
> official and Firefox consider it to be a calibrated ICC.

>From curiosity, which official sRGB profile from the color.org website
(http://www.color.org/srgbprofiles.xalter) does PhotoShop embed?  Or does
PhotoShop use some other sRGB profile, maybe a V4 matrix profile? If PhotoShop
embeds a V4 version of sRGB (matrix or LUT), then Firefox default settings  (as
of v 38) will ignore the embedded profile.

In case it might be useful, I put up a test page so people can  easily check to
see what their browser/OS/settings do with various versions of the sRGB profile
embedded in pngs (I'll try to add the same images saved as jpegs later today):
http://ninedegreesbelow.com/bug-reports/browsers-and-icc-profiles.html

> Actual Results:  
> So all and all, Firefox is doing its job according to the rules, while the
> OS is supplying it with a wrong reference, causing the color shift to
> happen. There is nothing we can do about it unless the ICC people realized
> it. Or they did this for some unknown reason. 

Firefox is doing its job according to its own rules. The real rule is that
untagged images should be treated as if they are sRGB images, not as if color
management were suddenly disabled. To get Firefox to "act by the rules" you
need to change the default settings.

> Expected Results:  
> Although it's technically not Krita's fault, we can do something to avoid
> being affected. So far Krita saving as JPG has ICC off by default, which is
> a good thing. All we need is to turn off ICC for PNG (and all other
> universal formats that has the ability to embed ICC).

Disabling embedding ICC profiles to satisfy mishandled color management in
various browsers and operating systems, and/or to accomodate user ignorance
seems to me to be a very bad idea for a color-managed editing application.

Having a special "export for the web" option that tries to accomodate browser
issues on various OS's might be a possibility.

It might work to change the default Krita sRGB profile to the V4 version with
the parametric curve. Firefox with default settings doesn't read V4 profiles.

Quoting from Comment 9 in the first post:
"9) Firefox detects the embedded ICC profile of the picture. If it's sRGB, it
will not color manage it, hence no color shift. Adobe Photoshop's sRGB embedded
picture is not affected because Photoshop embeds the official sRGB profile from
ICC. Krita is affected because sRGB-elle-V2-srgbtrc.icc is not official and
Firefox consider it to be a calibrated ICC. "

Has this "detect and don't color manag sRGB images" been implemented in
Firefox? I remember hearing some discussion on this point. If this is part of
the problem, then a bug report should be filed with Firefox to revert this
behavior. The so-called justification for this move was to keep web developers
happy, who can't be bothered to simply remove the embedded ICC profile before
uploading web design elements. The simpler course would be if Firefox made the
default setting for color management be 1 instead of 2.

My opinion counts for exactly nothing as I'm not planning on making a campaign
out of fixing browser and OS color management. But in my opinion:

     * OSX color management pipeline seems broken, and if it is, it needs to be
fixed instead of expecting developers to work around the problems:
https://bugzilla.gnome.org/show_bug.cgi?id=708579

     * Color.org needs to change their profile copyrights to be compatible with
free/libre software and also stop pretending Linux doesn't exist, and also fix
their V2 sRGB profile so the purported black point and the TRC actually agree,
and maybe even figure out how to have sRGB white R=G=B=1.0f map to LAB
(100,0,0) in relative colorimetric conversions, instead of to off-white
(99.998820, 0.018274, -0.016832).

     * Color.org needs to supply a V4 sRGB profile that is a bog-standard
matrix profile, and also supply better guidelines regarding "use this profile
for this purpose". Surely no one is embedding the V4 LUT sRGB profiles in
images uploaded to the web. But if they are, then at this point in time these
profiles are either being ignored or else sometimes very wrongly interpreted
depending on the browser and the settings and probably on the OS, or if the
browser does correctly read these profiles, the resulting colors don't match
colors from matrix sRGB profiles.

     * Libpng needs to stop playing profile police, stop checking to see if an
embedded sRGB profile is "really sRGB", and also get rid of the antiquated PNG
sRGB chunk that browsers seem to variously interpret.

     * Mozilla needs to ship Firefox with "all the way" color management
enabled by default, instead of trying to second-guess what the user wants done
with an embedded sRGB profile.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to