https://bugs.kde.org/show_bug.cgi?id=367832
Bug ID: 367832
Summary: Do not export PNG with Embed sRGB profile checked by
default because Firefox color shift and more.
Product: krita
Version: unspecified
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: File formats
Assignee: krita-bugs-n...@kde.org
Reporter: tyson...@mail.com
Krita has the ability to embed the current sRGB profile during exporting to PNG
and JPG. By default, the checkbox for this function is ON for PNG, OFF for JPG.
However, saving with Krita's embedded sRGB profile (I assume it’s
sRGB-elle-V2-srgbtrc.icc) leads to undesired color shift when the picture is
being viewed with a Color Management enabled viewer (notably Firefox) under
certain widely happening OS environment.
This is not a Krita bug, nor a Firefox bug. It’s caused by a problematic way
our industry has been handling the default ICC profile for displays. Here I
will discuss what triggers it and suggest how Krita can work around this by
changing a single default saving value.
Reproducible: Always
Steps to Reproduce:
1) Krita exported PNG with the Embedded sRGB profile checkbox checked; or Save
ICC profile checked for JPG. I assume it embeds sRGB-elle-V2-srgbtrc.icc. This
is not the official sRGB profile from ICC.
2) OS has its Color Management Enabled. I can confirm that Windows 10 and Gnome
3 has Color Management ON by default. Most most modern OS should have this ON
by now.
3) OS recognized the current display and automatically installed drivers
accordingly. On Windows the driver is just a place holder for PNP device. It
comes with a default ICC profile. On Gnome 3, gnome-color-manager automatically
generates a similar ICC profile and assign it to the display.
4) This mystical ICC profile, which I often regard as “the fake ICC Profile”,
no matter on Windows or Gnome, has a increased RED responsive curve. If an
image viewer respect this ICC profile, the picture becomes slightly brighter,
pinkish, and has less contrast. Blue color takes the heaviest impact.
5) Users do not manually assign a correctly calibrated ICC profile to the
display, nor do they remove the "fake ICC" or turn the Color Management of the
OS off. If they do any of these, the color shift will not happen. But I think
99% people will never do.
6) Most image viewers do not do color management by default. So there is no
color shift when using them.
7) But Firefox, one of the most popular web browser, has its Color Management
ON by default. So if 1) ~ 5) is happening (which is 99% the case) and they are
using Firefox, the color shift will happen. Which means a lot of people are
affected.
8) Firefox use “gfx.color_management.mode” to control it Color management
behavior in “about:config” page. The default value is 2, meaning Firefox only
does Color Management if the picture has an non sRGB Embeded ICC profile. If we
set this value to 1, then all pictures, regardless of having an embedded ICC or
not, will be color managed. You may find more information here:
http://kb.mozillazine.org/Gfx.color_management.enabled
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.
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.
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).
The other way is of course to embed the non-free sRGB profile from ICC. Which I
don't think being possible.
--
You are receiving this mail because:
You are watching all bug changes.
