-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add DIN99c/d color space #229
Comments
Hi @rumpelrausch, the latest version of the DIN 6176 standard from 2018 is called Colorimetric determination of colour differences of object colours according to the DIN99o formula. I was under the impression that DIN99o (the version we implement under the |
That german PDF shows formula for all DIN99 variants, but does not mention the formula for DIN99o / DIN 6176. Coming from the wikipedia description and those from the german PDF the DIN99c/d are the formula we're looking for, regardless whether DIN99o actually contains them. The major trick is the the calculation of a different Lab with modified X value. That's not what culori does. The easiest way to find out whether it's the "blue adapted" versions is looking at the "L" or "f" calculation. Culori definitely does DIN99b and features no "intermediate adapted Lab". Still trying to get my hands on the DIN PDF, though... Ah, according to https://de.wikipedia.org/wiki/DIN99-Farbraum DIN99o implements the DIN99b formula. |
Here's another doc that might shed some light:
These factors,
So, DIN99o lacks the bluish adaptions from DIN99d. Sadly DIN99c/d never got much public attention, even though in most of the papers it's said to provide the best performance, closest to CIEDE2000. A chance to be ahead of things... ;-) I forked culori and started experimenting with two additional color spaces, d99c and d99d. It works but leaves some questions and todos. If it's OK I'll create a draft pull request. |
Thank you for the pointers! For a web library such as Culori, the main reticence to adding color spaces is the increase in bundle size. Although in our case the tree-shakeable entry point can alleviate the issue, most people will use the default entry point, so it’s worth weighing how exotic a color space is vs. the cost it incurs to figure out if it belongs in the core library. It appears it’s mostly DIN99d that gets mentioned in several papers:
…so I suggest for now we limit ourselves to the Cartesian and polar versions of this color space and defer for now the DIN99c-based ones. When I added DIN99o, I used If you’re okay with the plan, I’ll provide further feedback on the PR you opened. |
About deprecating The math to get from XYZ to din99c/d is not too hard, it just wasn't easy to find any proper documentation. However, I'm unable to create the reverse math, so (from the culori point of view) any implementation would stay incomplete unless someone else came up with the correct formula. If it was OK for you I'd just leave this draft PR as it is. If anyone needed din99c/d output they may use it as a base. |
Sorry for the late response. I’ll try to provide the reverse transforms. |
DIN99c and DIN99d are the latest iterations over the "official" DIN99b color space.
It promises best accuracy for simple euclidian color distance calculation.
Goals:
Unfortunatly you can't just convert CIELab to DIN99c/d because it needs a different CIELab calculation first: For better accuracy in the blue regions they modify X from XYZ. The chain would be:
Anything -> XYZ -> modify X to X' -> CIELab' -> DIN99c/d.
The best formula source I could find so far is in German language, alas:
https://tuprints.ulb.tu-darmstadt.de/5870/13/D17%20Einfluss%20der%20Normspektralwertfunktionen%20_final_digital.pdf,
pages 29ff.
I could help translating it, if needed.
The text was updated successfully, but these errors were encountered: