Re: [Gimp-developer] Color space conversions seems to change PCS as well

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/24/20 5:43 AM, marcodv seznam cz wrote:

> Now, you are right that there's one inconsistency, gimp color picker's xyY is not the same as to what is 
> being pushed to the operation. I've got the same color picker result as you have.

Well, actually everything I said was right :) . Which means the 
discrepancies between GIMP's xyY values for sRGB reddest red and what 
you got at the command line still needs to be accounted for.

> I also reached out on the get issues for gimp and it might have been a known issue: 
> https://gitlab.gnome.org/GNOME/gimp/-/issues/5805

Checking the referenced issue, exactly as I said, there's an assign 
where there should be a convert.

To repeat, the discrepancies between GIMP's xyY values for sRGB reddest 
red and what you got at the command line still needs to be accounted 
for. This is a separate error from the "assign" instead of "convert" issue.

Pippin - do you have any idea what caused the discrepancies in the 
reported xyY values for sRGB reddest red? Is it a problem in babl or GEGL?

> > So if changing the rendering intent does make even a small difference
>
> I tested that again and there's no difference at all between perceptual and relative colorimetric. 

That's good!

> But I tried converting with saturation and absolute colorimetric and gimp stdouts that those conversions seem 
> to be not implemented.

babl hasn't implemented code for working with LUT profiles. Also matrix 
profiles don't have saturation intent tables, just as they don't have 
perceptual intent tables. And V4 profile processing always uses relative 
colorimetric for conversions between RGB matrix profiles regardless of 
any specified intent. Which is why any differences in results (other 
than "not supported" messages) from specifying different intents would 
have indicated a problem "somewhere".

Elle