Bug 287797

Summary:	Krita corrupts the color space for images
Product:	[Applications] krita	Reporter:	Joshua Barney <siskmarek>
Component:	General	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED FIXED
Severity:	critical	CC:	halla, ku.b
Priority:	NOR
Version:	2.4-snapshots
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Joshua Barney 2011-11-29 00:57:21 UTC

Version: 2.4-snapshots (using KDE 4.7.3)
OS: Linux

I use Krita with a wide gamut monitor, so color accuracy is crucial to my work.

Right before the problem occurred I noticed a painting I was working on had been switched to a mysterious color profile simply called "s". I believe the color profile had originally been sRGB built-in. I didn't notice any colors being off, and just chalked it up to a cosmetic bug.

There were some issues with brushes, so I decided to reset Krita's config. I saved my work, closed the program, removed all Krita-related configs in .kde4/, started it back up and reopened my painting. The colors were now totally off, much brighter, almost pastel-like, even after assigning my appropriate monitor profile. The painting's color profile was now labeled as scRGB. I did not change this before the save.

I tried changing the color profile back to sRGB built-in, but this only exacerbated the problem. I decided I had to manually tweak the layers back to the way they were using the HSV Adjustment tool starting from the sRGB built-in conversion. I matched the colors as closely as possible using an old progress shot I had exported, then saved the file and closed it.

I opened the file again, and the colors had reverted to the messed-up pale pastel colors.

I joined the #krita channel on Freenode and discussed my issues. I sent the offending file to a user on the channel, and he confirmed the color space was corrupt, and wasn't even showing up on his end as sRGB built-in. Instead it was some random string of characters.

Reproducible: Always

Steps to Reproduce:
Download the file. Change the colors on different layers using the HSV adjustment tool. Save. Close the file. Reopen the file.

Actual Results:
Colors have reverted to the way they were before the HSV adjustment

Expected Results:
The colors are retained from before the save.

Comment 1 Joshua Barney 2011-11-29 01:08:01 UTC

You can download the offending file at http://spiraldust.com/temp/screwedColors.tar.lzma

The progress shot mentioned in the bug description is at http://spiraldust.com/temp/what_colors_should_look_like.jpg

This is what the color space description looked like when someone else tried to open my file: http://i.imgur.com/rPA6g.png

Comment 2 Joshua Barney 2011-11-29 01:10:08 UTC

Oh, and although it probably won't be of much help, my monitor profile can be found at http://spiraldust.com/temp/U2410_2011-11-25.icc

Comment 3 Halla Rempt 2011-11-29 07:22:03 UTC

Hi Joshua,

Thanks for your report! I will try to look into it as soon as possible -- probably tomorrow night (CET).

Comment 4 Halla Rempt 2011-11-29 10:38:11 UTC

Do you still have the version that loaded with scRGB? I.e., before you started changing the colors again?

Comment 5 Kai-Uwe Behrmann 2011-11-29 10:58:47 UTC

Which version of lcms is used by Krita?
Does the bug exist with lcms2?

Comment 6 Joshua Barney 2011-11-30 04:28:42 UTC

(In reply to comment #4)
> Do you still have the version that loaded with scRGB? I.e., before you started
> changing the colors again?

I do, actually! You can download it at: http://spiraldust.com/temp/scRGB_version.tar.lzma

Comment 7 Joshua Barney 2011-11-30 04:33:01 UTC

(In reply to comment #5)
> Which version of lcms is used by Krita?
> Does the bug exist with lcms2?

It appears I have both 1.19 and 2.2 of lcms installed on my system. I'm not sure which one Krita links to. Using 'ldd' on the Krita binary doesn't show anything. using the 'equery depends' command suggests calligra depends on version 2 of lcms, but who knows for sure?

Comment 8 Halla Rempt 2011-11-30 09:37:50 UTC

With a self-compiled Krita that means that lcms2 should be used. the krita executable is just a wrapper that finds the krita plugin (which loads all the other plugins...) To check, find the kolcmsengine.so file and ldd that.

Comment 9 Joshua Barney 2011-12-05 02:50:41 UTC

(In reply to comment #8)
> With a self-compiled Krita that means that lcms2 should be used. the krita
> executable is just a wrapper that finds the krita plugin (which loads all the
> other plugins...) To check, find the kolcmsengine.so file and ldd that.

I see:

liblcms2.so.2 => /usr/lib64/liblcms2.so.2

So it indeed is using lcms2. If there's any other information I can provide, don't hesitate to ask. :)

Comment 10 Halla Rempt 2011-12-26 12:23:35 UTC

I have to admit that I'm completely puzzled. I cannot figure out a way to reproduce... I can use the hsv filter to make a nice autumn forest, but not to make the colors pastel-like. Can you maybe check how many copies of kolcmsengine.so you have on your system?

Comment 11 Halla Rempt 2011-12-26 15:54:19 UTC

Ha! I found a bug in the load code that assigned profiles. I'm confident that this bug is fixed now.

Comment 12 Joshua Barney 2012-01-01 20:31:46 UTC

(In reply to comment #11)
> Ha! I found a bug in the load code that assigned profiles. I'm confident that
> this bug is fixed now.

Thanks so much! I've pulled latest snapshot and have confirmed that not only does this solve the color space corruption bug, but also fixes a related problem of converting one color profile to another completely mangling the colors (a bug I probably should have reported a long time ago). I can trust Krita again!