color calibration CAT16 blackened areas about darktable HOT 8 CLOSED

I'm getting a black image for a certain range of hue inn CC module. No swapping of channels or anything odd.

from darktable.

Using the same colour wheel, if I force the input profile to Rec 2020, even XYZ adaptation results in black areas:

from darktable.

The B<->G swap creates harsh transitions for all adaptation spaces:
Exposure raised, without filmic:

With filmic, linear Bradford:

CAT16:

non-linear Bradford:

XYZ:

Are those harsh transitions expected?

With R<->G, the transitions are less sharp. R<->B is also sharp.

from darktable.

maybe ask this the initial implementor ;)

from darktable.

I am not a colormath guy so i can't comment in a qualified way, it 'think' this is correct. @flannelhead might be able to enlighten us ???

from darktable.

With a few printf, I found that for the sRGB input (0, 26, 255), I get:

      case DT_ADAPTATION_CAT16:
      {
        printf("In RGB: %f, %f, %f\n", temp_two[0], temp_two[1], temp_two[2]);
        // Convert from RGB to XYZ
        dt_apply_transposed_color_matrix(temp_two, RGB_to_LMS_trans, temp_one);
        printf("In LMS: %f, %f, %f\n", temp_one[0], temp_one[1], temp_one[2]);

        // Do white balance
        // force full-adaptation
        CAT16_adapt_D50(temp_one, illuminant, 1.0f, TRUE, temp_two);
        printf("In LMS D50: %f, %f, %f\n", temp_two[0], temp_two[1], temp_two[2]);
        break;
      }

In RGB: 0.046706, 0.020863, 0.896514
In LMS: 0.066428, 0.077905, 0.684437
In LMS D50: 0.066422, 0.077910, 0.684091

    // Compute the 3D mix - this is a rotation + homothety of the vector base
    dt_apply_transposed_color_matrix(temp_two, MIX_to_XYZ_trans, temp_one);

    printf("Mixed XYZ: %f, %f, %f\n", temp_one[0], temp_one[1], temp_one[2]);


    /* FROM HERE WE ARE MANDATORILY IN XYZ - DATA IS IN temp_one */

    // Gamut mapping happens in XYZ space no matter what
    _gamut_mapping(temp_one, gamut, clip, temp_two);

    printf("Gamut mapped XYZ: %f, %f, %f\n", temp_two[0], temp_two[1], temp_two[2]);

Mixed XYZ: -0.556486, 0.450167, 0.057407
Gamut mapped XYZ: 0.000000, 0.000000, 0.000000

After that, all is black, of course.

In _gamut_mapping, there is a check on the sum of the XYZ components, which fails:

static inline void _gamut_mapping(const dt_aligned_pixel_t input,
                                  const float compression,
                                  const int clip,
                                  dt_aligned_pixel_t output)
{
  // Get the sum XYZ
  const float sum = input[0] + input[1] + input[2];
  const float Y = input[1];

  if(sum > 0.f && Y > 0.f)
  {
    // we don't get here, sum is < 0
  }
  else
  {
    // sum of channels == 0, and/or Y == 0 so we have black
    for(size_t c = 0; c < 3; c++) output[c] = 0.f;
  }

The matrices are:
RGB_to_LMS:

0.451781, 0.504033, 0.038830
0.167443, 0.773309, 0.060179
0.010417, 0.061291, 0.761473

MIX_to_XYZ:

1.862068, 0.149187, -1.011255
0.387520, -0.008974, 0.621447
-0.015841, 1.049964, -0.034123

Simply replacing sum > 0 with sum != 0 in if(sum > 0.f && Y > 0.f) (since that is what the else branch seemingly wants to cover:
//sum of channels == 0), while there is no div-by-zero, the output is obviously wrong, the black is simply replaced by magenta.
I assume that's because of negative values in dt_aligned_pixel_t xyY = { input[0] / sum, input[1] / sum , Y, 0.0f };

I'll leave this to the big boys now.

from darktable.

@kofa73 you were on the right track :-)

from darktable.

Confirmed, thanks!
Without clipping:

With clipping:

Previously, clipping slightly darkened the areas next to the corrupted region, but did not avoid the corruption:

from darktable.