colorcalibration also for manual wb

[kofa73]

Addresses #19873

• added a new checkbox, prepare data for color calibration to white balance temperature.c to explicitly control the late_correction flag in 'user' / 'manual' modes
  • the checkbox is only visible in such modes (late_correction is always off in 'camera reference' mode, always on in 'as-shot to reference')
  • if switching from 'camera reference' or 'as-shot to reference' to a 'user' mode, the checkbox is automatically ticked if color calibration is enabled
• replaced reference chr->as_shot with chr->wb_coeffs in highlights.c, colorin.c, opposed.c and segbased.c
• illuminants.h:
  • added a new illuminant, DT_ILLUMINANT_FROM_WB, plus handling in conditionals, similar to DT_ILLUMINANT_CAMERA, but relying on dev->chroma->wb_coeffs
  • find_temperature_from_raw_coeffs:
    • renamed to find_temperature_from_as_shot_coeffs
    • extracted the logic to find_temperature_from_wb_coeffs, to allow directly using coefficients from temperature.c, instead of always going through ratios relative to the D65 values
    • added param wb_coeffs to illuminant_to_xy for absolute coefficients from temperature.c; renamed param custom_wb to correction_ratios to express what it represents; passed to find_temperature_from_wb_coeffs in DT_ILLUMINANT_FROM_WB mode
• channelmixerrgb.c:
  • _dev_is_D65_chroma no longer needs as_shot multipliers in late_correction mode
  • renamed _get_white_balance_coeff to _get_d65_correction_ratios
  • wired up the calls to find_temperature_from_wb_coeffs to handle DT_ILLUMINANT_FROM_WB

Draft for now, to allow discussion (and I haven't tested much, but wanted to make the changes visible to others; plus, I need to clean up some temp files)

[ralfbrown]

Did you intend to include cmixer_orig.c.txt in the PR?
And are the two .md files in the right place?

[kofa73]

Did you intend to include cmixer_orig.c.txt in the PR? And are the two .md files in the right place?

See the end of the description:

Draft for now, to allow discussion (and I haven't tested much, but wanted to make the changes visible to others; plus, I need to clean up some temp files)

[kofa73]

@ralfbrown : extra files removed, thank for your patience

[jenshannoschwalm]

A first complete code reading and remembering your comments before; generally i think this is a minor but very good improvement and will certainly help with some issues. Also it make the intention more clear and fixes some common misunderstandings.

I spotted some places like this:

dt_aligned_pixel_t correction;
  for_four_channels(k)
  {
    if(late && chr->wb_coeffs[k] > 1e-6f)
      correction[k] = chr->D65coeffs[k] / chr->wb_coeffs[k];
    else
      correction[k] = 1.0f;
  }

Could you explain if/why this is nevessary or is it just code-style?

[kofa73]

The key is the line:

correction[k] = chr->D65coeffs[k] / chr->wb_coeffs[k];

This used to be something like (below is one concrete example):

chr->D65coeffs[0] / chr->as_shot[0]

The new denominator comes from chr->wb_coeffs[k] (value set in temperature.c), which means it may be set using one of the sliders. The sliders may have a value of 0, so we must protect the division:

typedef struct dt_iop_temperature_params_t
{
  float red;     // $MIN: 0.0 $MAX: 8.0
  float green;   // $MIN: 0.0 $MAX: 8.0
  float blue;    // $MIN: 0.0 $MAX: 8.0
  float various; // $MIN: 0.0 $MAX: 8.0
  int preset;
} dt_iop_temperature_params_t;

One option would be to restrict the values to MIN: 0.1 or so, then we can avoid adding the protection everywhere.

If I misunderstood the question, please let me know.

[kofa73]

Any updates? There have been no new commits for a while, just resolving conflicts.

[TurboGit]

@kofa73 : This gets under the radar and I had many things to do for the AI integration. The discussion on pixl.us was difficult and my motivation was quite down for some time... I'm still a simple human :) I'll get back to this for 5.6.

[kofa73]

That's OK. I only asked to know if there's interest in this, so if another conflict comes, should I update it or just drop it. I know it's really not important, I'm not sure it actually brings any benefit. It was just always weird to me what was so special about one specific set of multipliers, read from the EXIF.

Plus, we'd have two equivalent settings (as shot + the new checkbox = as shot to reference), so a UI design change may be needed. I'm not sure it's for 5.6.

[TurboGit]

We will revisit this for 5.8 at this stage.