Several fields of "CIECAM02_Specification" and "CAM16_Specification" classes have incorrect scale.

[dfoxfranke]

CIECAM02_Specification and CAM16_Specification have incorrect scale for most of their fields, leading to senseless results when Scale-1 is set.

• Q is an absolute measure of brightness;. It should not be scale-dependent.
• M is an open-ended index of colorfulness. It should not be scale-dependent.
• C and s are open-ended ratios of incommensurate quantities. It should not be scale-dependent.
• H should have a Scale-Reference of [0,400], not [0,360]. It's arguable whether its Scale-1 should be [0,1] or [0,4].

Only J and h are correct:

• J is a ratio of commensurate quantities, so its Scale-Reference of [0,100] and Scale-1 of [0,1] are correct.
• h is in degrees, so its Scale-Reference of [0,360] and Scale-1 of [0,1] are correct.

See also #643.

[KelSolaar]

Hi @dfoxfranke,

Those are great points!

When I implemented the domain-scale range for those I debated whether I should scale those or not. I ran some numbers to see what were some extreme values on the visible spectrum and indeed as they are absolute, I could not find anything really sensible to scale them so I did not scale them. Later though, for consistency purposes, I decided to apply the scale conversion as it was making it easier to use in the API.

Retrospectively, it indeed does not make much sense. Good catch for H (even though we don't use it currently).

This, however, raises the point that we don't have a proper way to indicate absolute/immutable domain/range in the docs which as a consequence have us writing things like that:

    -   *SMPTE ST 2084:2014* is an absolute transfer function, thus the
        domain and range values for the *Reference* and *1* scales are only
        indicative that the data is not affected by scale transformations.

    +------------+-----------------------+---------------+
    | **Domain** | **Scale - Reference** | **Scale - 1** |
    +============+=======================+===============+
    | ``N``      | [0, 1]                | [0, 1]        |
    +------------+-----------------------+---------------+

    +------------+-----------------------+---------------+
    | **Range**  | **Scale - Reference** | **Scale - 1** |
    +============+=======================+===============+
    | ``C``      | [0, 1]                | [0, 1]        |
    +------------+-----------------------+---------------+

I will have to think about something, maybe we could use DN for Dimensionless and UN for Unaffected?

[KelSolaar]

So looking at it a bit more, it is actually more complicated than that, because we try to consistently scale pretty much everything. So for example, take CIE L*a*b*, everything is scaled by 100, i.e. L*, a* and b* are divided by 100. You could argue that a* and b* are dimensionless and not percentages but it makes using the Automatic Conversion Graph much harder. To use CIE L*a*b* as input to colour.convert, I only need to remember that I take the values and divide them by 100.

Dragging @MichaelMauderer if he has any thoughts on that.

[KelSolaar]

Another thing to consider (and now that I start to remember), the main reason for uniformly scaling everything was 3D rendering and volume comparisons. If you don't scale all the axis uniformly, irrespective of whether it makes sense or not, you get a non-uniform scale of two of the axis which results in volumes that are not really comparable. For example, here, imagine if two of the CAM16LCD axis were x100 larger:

[dfoxfranke]

@KelSolaar Good point! I think I buy this: M should receive the same scaling factor as J does because they're related as inputs to ΔE. As for Q, C, and s:

• I maintain that Q and C shouldn't be scaled. Their equations already have a scale factor of 100 removed from J, and no bugger factor added back in afterward, so they're already in their natural units

• s is computed as 100 * sqrt(M/Q) which I think I suggests it should be scaled by 1000: 100 to remove the artificial scale factor, and another 10 because it varies with the square root of M and M is being scaled by 100.

[MichaelMauderer]

This is probably more of a high-level comment regarding the scaling overall: I wonder if we could leverage custom nump dtypes to encode some scaling information into the data itself. That could be useful for the auto-conversion and allow us some more consistent handling of the scaling without losing the ability to convert there.

[KelSolaar]

In some way, we come back to the need to be able to store metadata in a form or another on the functions and data itself.

Custom dtypes would be problematic I reckon, not only it would be a lot of work to support but I think that Cupy would be extremely sad with that. It is possible to subclass ndarray but there is no guarantee that the metadata will be copied over by the functions copying arrays.

@dfoxfranke : I'm fine with Q and C staying absolute and unscaled, I would probably throw s in the same bucket!

[KelSolaar]

So I fixed the Hue Quadrature incorrect scaling and the associated docstrings, still have to think more about the others. Keeping this open for now :)