Hi,
I’ve been searching the forum and reading the docs but still don’t fully understand what’s causing these behaviors I’m seeing.
Here’s a side-by-side comparison of the same numerical RGB value in Photoshop and Krita. Both programs are in RGB 8-bit color mode.
I switch to the CMYK slider values, then back to the RGB sliders, with different results in each program.
Photoshop:
Gives a true neutral gray value on the CMYK slider (100 100 100 20)%
Retains original RGB numerical values when switching back to RGB slider
Krita:
Gives a muddy, colored value on the CMYK slider (17 13 20 87)%
Alters the original RGB numerical values when switching back to RGB slider
There are two issues I’m trying to understand:
Why are Photoshop’s CMYK numerical values so much different than Krita’s?
Why does switching back and forth result in changed RGB values in Krita but not PS?
I first noticed the issue after importing a Photoshop .aco color pallet and saw that even though the CMYK numerical values were identical between PS and Krita the colors were nothing alike.
I found this in the docs regarding Krita’s muddy CMYK values.
Why do identical CMYK values yield completely different results?
Is there any way to get value parity between programs?
As it stands I will need to rebuild the entire color pallet manually in Krita (375 colors! ) because the imported .aco colors are so off that the pallet is unusable.
The second question is, why do the RGB values change when switching back and forth between sliders? If you switch back and forth over and over again you’ll get different values every time.
The video shows that the displayed values don’t actually represent the current color.
Paint a 48 45 48 circle
Switch slider to CMYK and back to RGB
Krita says the current value is now 50 47 50
Painting a new circle appears to be identical color as 48 45 48 circle
Manually ‘update’ RGB slider and paint a new circle
Now new circle’s color really is 50 47 50
Eyedropper shows that Specific Color Selector was actually not displaying the current color’s true values after switching back from CMYK slider.
This second issue seems like it might be a bug but I thought I’d ask first to see if anyone could clarify what’s causing either of these two cases.
This is because CMYK is always tied to a color profile, and Photoshop uses a different color profile than Krita does by default. We cannot ship Photoshop’s color profile and there’s no data to recreate it.
The problem you’re seeing in the numbered list is what we call a ‘rountrip error’, which means that the maths to convert from sRGB to the cmyk profile (or back) can not be done without making compromises, so it cannot result in the same color when going back and forth. For this reason we try to convert the color at the last possible moment (which is necessary so we can do proper maths with it).
This makes sense, too, but I wonder how Photoshop is managing to do it without the error?
It’s like they’re invisibly “clicking” on the color swatch with the eyedropper to update the values instead of doing a mathematical conversion each time. Out of curiosity, would something like that work? Or would that be a bad way to do it? I’m just really curious how they’re getting around it.
Anyway, thanks for the answer. I understand what’s happening a lot better now.
Digging in to this some more, it looks like individual users, at least, can download the Adobe ICC Profiles here and drop them in to the Krita(x64)\share\color\icc\krita folder with the other .icc files.
So in this case I found Photoshop was using CMYK U.S. Web Coated (SWOP) v2. I was able to load this profile in to Krita and now the CMYK colors and numerical values both exactly match what I was getting in Photoshop.
I think this might have something to do with how Photoshop is able to retain accurate color values when switching between different color space sliders. It looks like it has multiple working color spaces “loaded” at once maybe?
Look how switching between an RGB and CMYK document actually updates/changes visually the pallet and the RGB values. Pretty neat.
Yep, I understand. But individuals can install these profiles and get matching colors between programs, which is what I didn’t know and wanted to find out.
So hopefully that helps someone else down the line running in to the same problem. This is all new to me, haha.
@pacermike
Well I must admit I am curious on the topic of conversions and the round trip error. If you try the pigment.o plugin (colour picker) does this disparity maintains itself? My curiosity steams from the fact I did try my best to minimize that issue which make it the way it is but I was never checked by a third party.
) because the imported .aco colors are so off that the pallet is unusable.
