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.
Created attachment 100768 [details] Comparison of a sensitive picture with or without embeded sRGB profile This is a comparison of a sensitive picture with or without embeded sRGB profile. The left one has embedded sRGB profile, the right one has not.
Created attachment 100769 [details] Kiki picture exported with embedded sRGB profile
Created attachment 100770 [details] Kiki picture exported without embedded sRGB profile
Created attachment 100771 [details] Response curve of system default ICC profile
Created attachment 100772 [details] Gnome 3 System default ICC profile of NEC PA242W
Created attachment 100773 [details] Gnome 3 System default ICC profile of Wacom Cintiq 13HD
Created attachment 100774 [details] Windows 10 system default ICC profile of NEC PA242W
Created attachment 100775 [details] Properly calibrated ICC profile of NEC PA242W
Created attachment 100776 [details] Properly calibrated ICC profile of Wacom Cintiq 13HD
You can get ICC official sRGB profiles from its website: http://www.color.org/srgbprofiles.xalter I hope we can find some differences regarding to the sRGB ICC color management problem that has been confusing us for so long.
Hi Tyson, we actually knew about this to some extent, so you didn't need to do this much research :p (We used to save the sRGB chunk originally when we saved to png when the user didn't say to use the profile, but that resulted in the same problem, so I removed that for 3.0) But yes, it is kind of horrifying that the OS gives a wrong generated profile :/ Anyway, confirmed.
Hi wolthera, this problem has been bugging me for a very long time. I know you probably already knew it, but there was no public article to explain it. I reported it with detail anyway so other less experienced users might learn something as well. One of these days other people will bump into this issue and this bug report can be used to explain stuff. Anyway if we can just turn OFF Embed sRGB option for Saving PNG, there will be much less user got their pictures messed up in Firefox. What's more, I highly suspect this ICC issue is going to impact Krita's pre-printing oriented users as well -- the whole printing process is completely color-managed! I noticed many of my pictures made with Krita, when being printed by the factories, had similar color shift. The blacks were never as black as what's in Krita. I thought it was normal to have such RGB-CMYK color loss and I just need to be more experienced to do better color planning. But recently one of my pictures got manipulated to add text before getting printed, and it didn't have the same color shift. They used proprietary software for that task. I guess it reveals how scary this issue can be for the professionals.
(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.
Hi Elle, MS and Adobe both supplies a sRGB V2 profile with their software. Adobe also provides a color profile download that includes sRGB and AdobeRGB profiles. Last time I checked, the said sRGB profiles was produced by ICC in the meta information. Ubuntu also has a similar sRGB profile to generate default ICC for everything. If you cannot find them, I can extract them later for you. I agree with your idea to make a new option that reads like “Workaround broken color management of some OS”, which is checked by default, does whatever necessary to make sure the exported picture shows correct color everywhere. As for the technical stuff... look at all those parties you’ve mentioned. Because of the horrible foundation they laid, everybody now has developed their own ways to coupe with the problem. You change one thing upstream, you break everybody downstream. I bet they’d rather remain the current state. Although I can understand everything in this conversation so far, I’m just a desperate artist who was forced to learn stuff that’s not in my legit territory. I’ll do whatever I can to help the research, but our research will take time. I understand the ideal solution indeed SHOULD be done by the upstreams, but in reality it probably won’t be there in a few years. Meanwhile, the artists use Krita probably have deadlines to beat and cannot wait that long. The cheapest workaround is simple: change the default value of “Embed sRGB profile” to UNCHECKED, and ideally add some explanation text below so people don’t try to be smart by checking it. We are already doing that for JPG, why not PNG too? I understand that as a developer, you want things to work according to the standard with a correct process. But in reality, people just want to see right color. It’s so frustrating seeing my own pictures displayed and printed with wrong color, probably losing potential clients as well. Although I know how to avoid it now, it still breaks my heart seeing fellow Krita artists unknowingly suffering the same. Please help them! Hi Elle, MS and Adobe both supplies a sRGB V2 profile with their software. Adobe also provides a color profile download that includes sRGB and AdobeRGB profiles. Last time I checked, the said sRGB profiles was produced by ICC in the meta information. Ubuntu also has a similar sRGB profile to generate default ICC for everything. If you cannot find them, I can extract them later for you. I agree with your idea to make a new option that reads like “Workaround broken color management of some OS”, which is checked by default, does whatever necessary to make sure the exported picture shows correct color everywhere. As for the technical stuff... look at all those parties you’ve mentioned. Because of the horrible foundation they laid, everybody now has developed their own ways to coupe with the problem. You change one thing upstream, you break everybody downstream. I bet they’d rather remain the current state. Although I can understand everything in this conversation so far, I’m just a desperate artist who was forced to learn stuff that’s not in my territory. I’ll do whatever I can to help the research, but our research will take time. I understand the ideal solution indeed SHOULD be done by the upstreams, but in reality it probably won’t be there in years. Meanwhile, the artists use Krita probably have deadlines to beat and cannot wait that long. It’s frustrating seeing my own pictures displayed and printed with wrong color, probably losing potential clients as a result as well. Now I know how to avoid it myself, it still breaks my heart seeing fellow Krita artists unknowingly suffering the same. The cheapest workaround is simple: change the default value of “Embed sRGB profile” to UNCHECKED, and ideally add some explanation text below so people don’t try to be smart by checking it. We are already doing that when exporting JPG, why not PNG too? I understand that as a developer, you want things to work according to the standard with a correct process. But people just want to see nice result.
Oops, Comment 14 got double pasted. Here is the correct version. Hi Elle, MS and Adobe both supplies a sRGB V2 profile with their software. Adobe also provides a color profile download that includes sRGB and AdobeRGB profiles. Last time I checked, the said sRGB profiles was produced by ICC in the meta information. Ubuntu also has a similar sRGB profile to generate default ICC for everything. If you cannot find them, I can extract them later for you. I agree with your idea to make a new option that reads like “Workaround broken color management of some OS”, which is checked by default, does whatever necessary to make sure the exported picture shows correct color everywhere. As for the technical stuff... look at all those parties you’ve mentioned. Because of the horrible foundation they laid, everybody now has developed their own ways to coupe with the problem. You change one thing upstream, you break everybody downstream. I bet they’d rather remain the current state. Although I can understand everything in this conversation so far, I’m just a desperate artist who was forced to learn stuff that’s not in my territory. I’ll do whatever I can to help the research, but our research will take time. I understand the ideal solution indeed SHOULD be done by the upstreams, but in reality it probably won’t be there in years. Meanwhile, the artists use Krita probably have deadlines to beat and cannot wait that long. It’s frustrating seeing my own pictures displayed and printed with wrong color, probably losing potential clients as a result as well. Now I know how to avoid it myself, it still breaks my heart seeing fellow Krita artists unknowingly suffering the same. The cheapest workaround is simple: change the default value of “Embed sRGB profile” to UNCHECKED, and ideally add some explanation text below so people don’t try to be smart by checking it. We are already doing that when exporting JPG, why not PNG too? I understand that as a developer, you want things to work according to the standard with a correct process. But people just want to see correct result.
(In reply to Tyson Tan from comment #15) > MS and Adobe both supplies a sRGB V2 profile with their software. Adobe also > provides a color profile download that includes sRGB and AdobeRGB profiles. Do you have a link? I checked the Adobe website about a month ago, and there were no sRGB profiles in the download pack, and haven't been for quite awhile. > Last time I checked, the said sRGB profiles was produced by ICC in the meta > information. Ubuntu also has a similar sRGB profile to generate default ICC > for everything. If you cannot find them, I can extract them later for you. I'm not sure what you mean by "Last time I checked, the said sRGB profiles was produced by ICC in the meta information." A kind person sent me two files exported from CS5 and CS6 with embedded sRGB profiles, and the copyright was by Hewlett-Packard. The sRGB profiles downloadable from color.org are copyrighted by the ICC. These are the only sRGB profiles I've ever seen that are copyrighted by the ICC. Your offer to send extracted profiles is very kind, but there's no need. I have an extensive collection of sRGB profiles from a previous investigation of "the" sRGB profile. And I'm pretty sure that if you extracted a profile from an image and sent the profile to me, and the profile wasn't copyrighted as CC0, public domain, etc, then you'd be violating the profile copyright. Fortunately you can easily eximine embedded profiles by using exiftool: exiftool filename.png As an aside, the sRGB profile embedded by CS5/CS6 (one on Windows, one on Mac) in the two images that were sent to me is a profile that libpng marks as "known incorrect sRGB profile". The CMM tag says "Lino" and the copyright tag says Hewlett-Packard. I could be wrong, but I think this profile might be distributed by the OS, not by PhotoShop. Of course this doesn't preclude the possibility that there really is an ICC-copyrighted sRGB profile distributed along with some versions of PhotoShop. If Firefox with default settings on OSX treats the old "Lino" profile as sRGB, how does it treat Graham Gill's sRGB.icm profile? If you wouldn't mind checking, I included a png with Graham Gill's profile embedded in my post to my website (http://ninedegreesbelow.com/bug-reports/browsers-and-icc-profiles.html). > The cheapest workaround is simple: change the default value of “Embed sRGB > profile” to UNCHECKED, and ideally add some explanation text below so people > don’t try to be smart by checking it. We are already doing that when > exporting JPG, why not PNG too? I understand that as a developer, you want > things to work according to the standard with a correct process. But people > just want to see correct result. As long as the user has a chance to check the box to embed the profile, and keep that box checked, instead of having to check it every time, your solution sounds reasonable. But it results in what the esteemed Bruce Fraser called "mystery meat" images. In an ICC profile color managed workflow, images need embedded ICC profiles. I understand that there are exceptions. And it's a shame that Firefox has created such a disaster for color managing images posted to the web. But it would be best if Krita users have the option to made a choice to embed (or not embed) a profile and have that choice "stick" until they deliberately make the opposite choice. Best, Elle
Hi Tyson, First, about embedded profiles, png images and firefox: on OSX, all images in Elle's test page are rendered the same way by Firefox. It really seems to be a problem on systems where colord is running with a generated profile (Wolthera sees the difference on Unity I don't on OSX or Kubuntu). For printing: that's an entirely different thing, unrelated to the png problem. Adding text might have added a rich black plate. Deevad says he would like to look at one of the files you had problems with. Was that originally done in CMYK by you, or did you let the printer convert sRGB to CMYK for printing?
We also just checked windows 10 and there the problem doesn't show up either: it is really colord that's the problem. I'll do some testing on gnome....
Hi Elle, I couldn't find any sRGB profile download on Adobe's website, either. And yes the sRGB profile we have been using is indeed from HP. Must be me remembering things wrong or they have changed (my last research on sRGB under Windows was around 2012). Either way, I'm sorry about the misinformation. I DIDN'T request to keep the box UNCHECKED EVERY TIME. My intention was to uncheck it THE FIRST TIME when we use that dialogue on a FRESHLY installed Krita. Krita remembers that option so they can keep it checked if they like. My opinion is: just don't guide unknowing people into the trap. Artists are not part of the problem. Most non-tech artists will never change default settings. They are unlikely to notice the color shift problem. Even if they do noticed, they are unlikely to link the problem with that checkbox. They will only blame Krita because "it is the only app that make wrong colored picture".
Hi Boud, I'm pretty sure it happens on Windows 10 + Firefox. I actually noticed this problem first time on Windows 10, then I went to test it on Gnome. All of them have this problem. I'll answer other questions later.
We aren't against toggling the default, but we are looking into what the exact bugs and end-user problems are to smoothen the cm workflow out further beyond the new default. * We have seen the firefox difference on a Ubuntu device. * We have NOT seen the firefox difference on either of 2 windows 10 devices and one osx device. * We have seen that Deevad on Linux Mint can get an exact match between firefox when he manages to stick his display profile(generated for his laptop) into the Krita RGB monitor list and selects that profile. * We have in the past seen that if we store the sRGB chunk into a png it will give EXACTLY the same result as a sRGB profile embedded into Firefox. * Boudewijn and Dmitry are currently busy profiling boud's widegamut device to compare Krita and Darktable, because the latter also uses LCMS instead of Firefox's QMS. * You say that images you for print make look washed out until someone changes the image with a non-krita application. As far as I can tell this is a completely different issue, with different things to diagnose. (Who did the conversion to cmyk, what program did the other program use, what was the original rgb profile, what was the final cmyk profile, what type of printer was the print printed on, do you use blackpoint compensation, I might be forgetting a few)
Git commit 853e42fdd75eee1387c0fd933b86a2ae6291b5dc by Wolthera van Hovell tot Westerflier. Committed on 01/09/2016 at 11:19. Pushed by woltherav into branch 'master'. Uncheck 'embed profile' by default. It seems we cannot rely on Firefox and ColorD to manage sRGB images as sRGB images with a regular bog-standard sRGB profile. This is shown previously by an experiment with a PNG that has an sRGB chunk, and a png that has a sRGB profile looking exactly as distorted in Firefox. It is a pity that we have to encourage our users not to embed sRGB profile, but as long as something as simple as showing an sRGB image as an sRGB image(which yes, dear commit message reader, is the same as doing exactly nothing with it) is too complicated for other programs, it cannot be helped. M +5 -1 plugins/impex/png/kis_png_export.cc http://commits.kde.org/krita/853e42fdd75eee1387c0fd933b86a2ae6291b5dc
Created attachment 100880 [details] Kiki picture exported with sRGB chunk. Okay, so I’ve compiled Krita to save the SRGB chunk. The sRGB chunk is a switch, like a lightswitch, to tell applications the png file is absolutely 100% certainly a sRGB image. There’s NO profile information involved. I have saved the Kiki image with this sRGB chunk, and double-checked with pngcheck whether it had only the chunk saved. If you open this file, you will notice it looks EXACTLY the same as the sRGB embedded profile file. I do not think Firefox makes any exceptions for any sRGB profile, as that would mean it would treat the sRGB chunk differently from this supossed canonical sRGB profile. As this would be incredibly stupid, and I do somewhat respect the Firefox programmers, I do not think they treat the sRGB chunk any different from any generic sRGB profile, and would in fact dare to say there’s no difference between files with an sRGB profile and an sRGB chunk for Firefox. In short, all files marked with colormanagement meta-data will get the ugly distortion given by firefox due to the ColorD default profile. What I suspect might be happening on Windows is that both the ‘use monitor profile’ needs to be ticked, as well as the monitor profile loaded into Krita and selected from the list. If you had Windows’ colormanagement use your display profile, then Firefox probably grabbed it, while, without those options, Krita would still use the default sRGB profile to manage it’s canvas. If setting Krita to explicitely use the right profile fixes the issue, then we have a usability issue on our hands that indeed needs to be fixed as well. (Also I just discovered I accidentally disabled the wole option instead of unchecking by default... whoops, gonna fix that now)
Git commit 9deeaf809e61785fb074068c4c6ea6240157b674 by Wolthera van Hovell tot Westerflier. Committed on 01/09/2016 at 12:12. Pushed by woltherav into branch 'master'. Uncheck by default, not disable. We don't want to remove the whole ability to embed profiles. Whoops :) M +3 -3 plugins/impex/png/kis_png_export.cc http://commits.kde.org/krita/9deeaf809e61785fb074068c4c6ea6240157b674
Created attachment 100881 [details] Windows driver with embeded ICM profile Some additional information: On Windows, I highly suspect we need to install a proper driver for the monitor in order to reproduce color difference. In this screenshot, the "Generic PNP Monitor" is actually a Cintiq 13HD. There is no ICM profile associated with this Windows default driver. If this is what your monitor looks like in Windows Device Manager, color management is most likely being turned off. That’s probably why you don't observe color difference in Firefox. Since Windows XP, Windows began to automatically pull drivers from Windows Update. Windows 10 has a very large online driver library that it can solve most driver problem by itself. That service brought about new problems -- I didn’t install NEC PA242W’s driver in that screenshot. Windows 10 did it. PA242W’s driver has an ICM profile. So far as I know, every specific monitor driver provided by the manufacturers has an ICM profile. All these ICM profiles share a similar characteristic: that funny blue response curve in TRC view that greatly deviates from the center. If you are running Thinkpad X/T/W/P laptops, Lenovo provides laptop screen drivers on their website (some only shown when you select Windows 7). When I was using Thinkpad X201T/X230T, I once installed the monitor driver and the color shift happened right after that. Same thing happened for all my DELL monitors and even a cheap crap like Philips 190EL...yeah they even bothered to provide a driver. Probably an industrial standard or something. I never encountered this problem soon after I migrated to Linux and started color managing my monitors. That’s why I have completely forgotten this problem until it surfaced again when I was using my totally unmaintained Windows 10 to test Krita there. My suggestion on environment to reproduce this problem: On GNU/Linux: Ubuntu Original / Ubuntu Gnome. Do not associate calibrated profile. Use Firefox. The key here is probably a DE with Color management capability which is being turned ON, with no calibrated profile loaded for the monitor. Gnome and Unity are very typical for this (Unity uses Gnome control schemes). They all have CMS capability, they all turn CMS on by default, they all auto-generate ICC profiles and associate them with the monitors, triggering Firefox to do color management (in a wrong way). On Windows: Install a driver from your monitor’s manufacturer, do not associate calibrated profile. Use Firefox.
Created attachment 100882 [details] Philips 190EL's ICM from its driver Maybe we can compare this with PA242's and Ubuntu auto-generated ones.
Created attachment 100883 [details] Kiki with sRGB chunk, Ubuntu default settings (CMS ON, auto profile), Firefox default settings
Created attachment 100884 [details] Kiki with sRGB chunk, Ubuntu with calibrated profile, Firefox default settings
Created attachment 100885 [details] Kiki with sRGB chunk, Ubuntu CMS OFF, Firefox default settings
Thank you for the patch, wolthera!
Git commit 165135179ad2f29c5b9f3f94f56a4dd5cd78f941 by Boudewijn Rempt. Committed on 24/10/2016 at 13:10. Pushed by rempt into branch 'rempt/impex-refactoring'. Set some common properties of the image on the export configuration This can be used to correctly configure the dialogs, which don't have access to the document or the image. This also means the save profile option works again in the png export dialog. M +27 -1 libs/ui/KisImportExportManager.cpp M +1 -22 plugins/impex/png/kis_png_export.cc http://commits.kde.org/krita/165135179ad2f29c5b9f3f94f56a4dd5cd78f941
There has been a new development to this old bug. When I was testing Bug 412943, I noticed that Firefox 69 now only does color management properly with PNG pictures with this option CHECKED. It actually makes sense now that Firefox is treating the option identically in both JPG and PNG pictures produced by Krita. It could also be my previous observation being flawed because of the faulty color management mentioned in Bug 412943. With my current display setup it's much easier to spot a wrong result. Maybe we can now turn the "Embed sRGB profile" option in Save to PNG dialogue back on.
Test condition: Default Windows 10/KDE/Gnome/Firefox, no calibration, no profile, no configuration -- to emulate a layman user who uses a wide-gamut display but never installed any display driver or performed any profiling. ######### Images that failed the Firefox color management test: https://www.dropbox.com/s/pf0wl0sx0m5ajnc/kigori_skye_JPG_no_save_icc_profile_FFX.jpg?dl=0 JPG [_] Save ICC profile https://www.dropbox.com/s/z4p61en3b84zeum/kigori_skye_PNG_default_force_sRGB_with_alpha_FFX.png?dl=0 PNG [_] Embed sRGB profile ######### Images that passed the Firefox color management test: https://www.dropbox.com/s/i5rg2q7r642g33b/kigori_skye_JPG_save_icc_profile_FFO.jpg?dl=0 JPG [+] Save ICC Profile https://www.dropbox.com/s/ouahrqjtvlsx8as/kigori_skye_PNG_embed_sRGB_force_sRGB_with_alpha_FFO.png?dl=0 PNG [+] Embed sRGB profile [+] Force convert to sRGB [+] Store alpha channel https://www.dropbox.com/s/caql2fjdbwavit4/kigori_skye_PNG_embed_sRGB_no_alpha_FFO.png?dl=0 PNG [+] Embed sRGB profile [_] Force convert to sRGB [_] Store alpha channel https://www.dropbox.com/s/tmhuvpj86wmp1l5/kigori_skye_PNG_embed_sRGB_with_alpha_FFO.png?dl=0 PNG [+] Embed sRGB profile [_] Force convert to sRGB [+] Store alpha channel ######### Conclusion: JPG and PNG images saved by Krita must save with embedded sRGB profile to display properly in not-color-managed Firefox and some other apps. It's advisable to make enable these options by default. ######### BTW, Images that failed the Gwenview color management test https://www.dropbox.com/s/ouahrqjtvlsx8as/kigori_skye_PNG_embed_sRGB_force_sRGB_with_alpha_FFO.png?dl=0 PNG [+] Embed sRGB profile [+] Force convert to sRGB [+] Store alpha channel https://www.dropbox.com/s/tmhuvpj86wmp1l5/kigori_skye_PNG_embed_sRGB_with_alpha_FFO.png?dl=0 PNG [+] Embed sRGB profile [_] Force convert to sRGB [+] Store alpha channel (Apparently Gwenview doesn't color manage images with alpha channel. I reported a bug about it) ######### Windows 10 1903 Photo UWP App It doesn't do color management at all. -_-
Just a side note: if we set srgb png tag (without embedding the profile), Firefox still renders incorrectly (at least it used to have, because saving this tag is commented out in the code).
(In reply to Dmitry Kazakov from comment #34) > Just a side note: if we set srgb png tag (without embedding the profile), > Firefox still renders incorrectly (at least it used to have, because saving > this tag is commented out in the code). After some further research, this problem appears to be so much more complicated...so instead of advising a change, it's wiser for me to just share what I've found, and discuss about them. ### How Firefox does color management now When I tested it in Firefox 70.0.1 (Win10/Linux), it would not do color management unless the picture has a color space assigned to it, being sRGB or not. This is the default behavior. By setting about:config -> gfx.color_management.mode to 1, you can force Firefox to color manage all untagged picture as if they are in sRGB. But not all picture uses sRGB, so this can introduce issues. To be honest, I don't think Firefox had "changed" its behavior. Most applications behave the same way, and many of them do not color manage PNGs with Alpha channel. It was more likely to be me who got it wrong in the past. Now I can test with a wide-gamut display and a sRGB display side-by-side, and I've also studied proper color management workflow, it's most likely that I was finally doing it correctly in Comment #32 and Comment #33. ### When non-sRGB color spaces are taken into context When talking about Krita's default PNG exporting settings -- since we check "Force convert to sRGB" by default, it makes sense to also check "Embed sRGB profile" and uncheck "Store Alpha channel" -- this way we can ensure 100% compatiblity with sRGB. In case of a wide-gamut display, the picture will be rendered correctly without tweaking Firefox (or other applications). In case of sRGB displays, it doesn't make any difference. However, the problem is obvious -- "Embed sRGB profile" makes no sense if we are saving a non-sRGB PNG. And it immediately brings up some more questions: 1) Does PNG force us to use sRGB color space? 2) Can Krita embed the working file's profile in the future? 3) When rec. 2020 color space became widely adopted, do we add new settings accordingly? So long as most people are using sRGB displays, this is not yet a big issue. But the industry is now moving towards a wider color space, the majority of mid-high tier users are going to experience over-saturated color if we do nothing. Maybe it's time to discuss whether we sacrifice a larger color space for safe color rendering, or something else we can do as a workaround.
This has been reworked completely since then. It's still possible (and quite common) for people to mess things up, but there really isn't anything else we can do. Every option in the png export dialog does the right thing. We no longer use the technically correct png_set_sRGB_gAMA_and_cHRM call because that's what messes up firefox.