distance_lab2000 appears to calculate T starting from radians instead of degrees

[angerson]

In https://github.com/robertkist/libdither/blame/7bf49c5324b8b8d5ce321d549f89fb6c75a9d859/src/libdither/color_models.c#L198, hp_ave is defined in radians, but T is then calculated as if hp_ave is in degrees.

if (C1p * C2p == 0) {
    hp_ave = h1p + h2p;
} else {
    double deltah = fabs(h1p - h2p);
    if (deltah <= M_PI) {
        hp_ave = (h1p + h2p) / 2.0;
    } else {
        if (h1p + h2p < 2.0 * M_PI) {
            hp_ave = (h1p + h2p + 2.0 * M_PI) / 2.0;
        } else {
            hp_ave = (h1p + h2p - 2.0 * M_PI) / 2.0;
        }
    }
}
// calculate T
double hp_ave_deg = (hp_ave);
double T = 1.0
           - 0.17 * cos(DEG2RAD(hp_ave_deg - 30.0))
           + 0.24 * cos(DEG2RAD(2.0 * hp_ave_deg))
           + 0.32 * cos(DEG2RAD(3.0 * hp_ave_deg + 6.0))
           - 0.20 * cos(DEG2RAD(4.0 * hp_ave_deg - 63.0));

Claude found this while I was working on a project and insists hg_ave_deg should be = hp_ave * 180.0 / M_PI;. I'm not wanting to file an AI-discovered issue I don't understand, and I wish I understood the effects more deeply -- but it does look like the T calculation is starting from a value that is in radians.

I'm a bit confused because LAB2000 color mapping already looked fine to me.

[robertkist]

Thanks! I'll have to check but it might be possible that it's wrong.

Last Dec I refactored a lot of color dithering code because it's primarily done in sRGB space (unlike the mono dither) and moved it to linear color space. And I remember also finding some LAB related issues. Basically, the current color dither is not really correct, but looks good (and correct-ish) 😆

Although I'm inbetween jobs now, so I'm not sure when I'll be able to push the updates live. But I'll make sure to take another look before I make a release.

Thanks!