https://bugs.kde.org/show_bug.cgi?id=367832
--- Comment #23 from wolthera <griffinval...@gmail.com> --- Created attachment 100880 --> https://bugs.kde.org/attachment.cgi?id=100880&action=edit 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) -- You are receiving this mail because: You are watching all bug changes.
