Draft: Fix #17178 JzCzhz color picker

[kofa73]

No description provided.

[jenshannoschwalm]

1. Looking at the right spot :-)
2. It would be better to have the impossible conversions reported in a readable form

// fallback, but this shouldn't happen
      dt_print(DT_DEBUG_ALWAYS,
               "[colorpicker] unknown colorspace conversion from %s to %s\n",
               dt_iop_colorspace_to_name(image_cst), dt_iop_colorspace_to_name(picker_cst));
      _color_picker_work_4ch(source, roi, box, pick, NULL, _color_picker_rgb_or_lab, 100);

you will notice while playing with the pickers in the blending gui that there are more conversions requiring support.

3. Your check (effective_cst == IOP_CS_JZCZHZ && picker_cst == IOP_CS_LAB) seems wrong to me. I think we must test for all cases effective_cst == IOP_CS_LAB and convert according to the chosen picker_cst.
   It would be correct and also might be the easiest way to convert IOP_CS_LAB data to IOP_CS_RGB exactly as we do for the pixelpipe (see pixelpipe_hb.c around line 1130) and use those converted data for processing.

[kofa73]

I can start working on it on 1 August, but just a little bit every day (I'm supposed to be on vacation then). I not done by the 7th, I won't be able to touch it for a week (will be away from my computer).

[jenshannoschwalm]

This is something new for 5.0 so no reason to make haste

[kofa73]

@jenshannoschwalm I only got some time to sit down and have another look now.

With your suggested formatted debug message, I get:
unknown colorspace conversion from IOP_CS_LAB to IOP_CS_JZCZHZ, and you are right, I mixed them up.

With that fix, I do get a usable mask:

I don't yet get how to implement your suggestion regarding RGB, but I'll check more later.

Regarding comments like

// FIXME: the mean calculation of hue isn't always right, use circular mean calc instead?

Wouldn't it be better to convert the whole selected area into linear RGB, calculate the mean there, and convert that to the picker space?

[jenshannoschwalm]

The problem here is the "range" calculation around hue zero. So if the picker finds data around red the range should be marked correctly.

You will find code in the area picker representation in color equalizer.

[jenshannoschwalm]

Are you still working on this or would you want me to take over?

[kofa73]

I have not touched it in a while. I hope to get back to it. Give me two weeks, and if still nothing, please take over.

[kofa73]

Hi @jenshannoschwalm , I need a bit of help: do you mean I should use dt_ioppr_transform_image_colorspace ? If yes, what should I submit for the module? Maybe I completely misunderstood, sorry. I hope I can spend a bit of time on this during the coming weekend.

[jenshannoschwalm]

I think i may have put you on a not-so-good track.

For the RGB it's probably fine to convert each pixel (as you did for the Jz stuff) via dt_XYZ_to_Rec709_D50() after dt_Lab_to_XYZ().

[kofa73]

Added, but source = Lab conversions seem broken. I have now set up KDevelop, and am happy to work on this.

local_contrast with scene referred blending space:

'g' channel_
This looks reasonable:

But this does not:

'B' channel (running into negative numbers?)

'Jz':

'Cz' is broken:

'hz' seems to be 'lagging'

Here is the colour wheel used for testing: