Diskussion:DIN99-Farbraum

neue Erkenntnisse

Hallo Al'be:do ein sauberes Stück Fleißarbeit, so schnell hätte ich das nicht geschafft. Es erspart einiges zu den Farbdifferenzen, vielleicht ist dennoch ein Artikel dazu nötig, eventuell nur hinweisend. --Paule Boonekamp - eine Silbersonne 16:02, 2. Feb. 2008 (CET)

Ach und: ich habe mal den Kopf mit einem Titel vom Erläuterungssatz getrennt, bin aber nicht ganz glücklich über das Wort: Es drückt zuwenig aus das der DINraum etwas neues ist. --Paule Boonekamp - eine Silbersonne 16:07, 2. Feb. 2008 (CET)

Ja so ist es besser. --Paule Boonekamp - eine Silbersonne 16:13, 2. Feb. 2008 (CET)

Danke, Paule! Hat auch ein paar Stunden gedauert, bis ich den Artikel in akzeptable Form gebracht hatte ;) Ich werde auch noch Artikel zu CIE94, CIEDE2000 und $\Delta E$ CMC(l:c) verfassen. Wenn ich Daten zur Weiterentwicklung von DIN99 finde, werde ich sie auch noch einfügen. Kann noch ein wenig dauern, kommt aber bestimmt.

--Al'be:do 16:23, 2. Feb. 2008 (CET)

Ich glaube ich muss mal wieder zum Beuth-Verlag stiefeln. --Paule Boonekamp - eine Silbersonne 16:31, 2. Feb. 2008 (CET)

Hehe, ich könnte mal in der DIN-Bibliothek der Uni nachschauen.

Titel der Norm: "Farbmetrische Bestimmung von Farbabständen bei Körperfarben nach der DIN99-Formel", DIN 6176:2001-03

Kostenpunkt: € 32,40, Der Download ist sogar teurer als die Versandvariante.

--Al'be:do 16:54, 2. Feb. 2008 (CET)

Helligkeitstransformation - Ein Fehler in der Norm

Da ich gerade die Optimalfarbkörper für diverse Farbräume berechne, ist mir folgendes aufgefallen:

Die Standardformel für $L_{99}$ ist fehlerhaft. Für L*=100 ergibt sich $L_{99}=100,0012595$. Der Fehler ist klein aber nicht unbedingt vernachlässigbar. Bei 8 Bit linear fällt der Wert überhaupt nicht auf, da der Fehler der Formel unter der Auflösung von 0,39/2 liegt. Bei 16 Bit linear liegt der Quantisierungsfehler bei 0,0015/2. In diesem Fall würde es also eine Differenz geben. Vielleicht ist der Fehler deshalb ignoriert worden, weil die Formel für 8 bit konzipiert ist. Das ist nur meine Vermutung. Ich weiß nicht, ob die aktuelle Version der DIN 6716 den Fehler behebt, aber wer einwandfreie Werte haben möchte, sollte vielleicht eine der folgenden Formeln verwenden. Ich habe die Originalgleichung umgeformt und Lösungen für beide Dezimalbrüche berechnet:

$L_{99}={\frac {100}{\ln \left({\frac {129}{50}}\right)}}\ln(1+0{,}0158\;L^{*})$

oder

$L_{99}=105{,}51\ln \left[1+\left(\exp \left({\frac {10000}{10551}}\right)-1\right)L^{*}\right]$

Dann kommt exakt 100 heraus.

Zur relativen Abweichung von der Norm muss ich noch mal mein Matheprogramm laufen lassen. Absolut dürfte es sich um eine Abweichung um ca. 0,001 handeln. Relativ gesehen sieht es natürlich anders aus.

Ideal wären natürlich echte Brüche für beide Werte, da es sich hier aber nicht um eine Unstetigkeitsstelle handelt, kann ich auch keine Kurvensteigung als Anhaltspunkt nehmen, wie es Bruce Lindbloom in seiner Korrektur von L* getan hat.

Ich könnte natürlich die Formeln in den Artikel einfügen, halte das aber nicht für eine gute Idee, da es halt keine offizielle Lösung ist, sondern nur auf meinem Mist gewachsen. Vielleicht reicht ja ein kleiner Hinweis auf den minimalen Fehler. --Al'be:do 10:19, 20. Feb. 2008 (CET)

Fehler bei den Inversionsformeln!

Ich implementiere in JavaScript gerade eine Farb-"Klasse" und beim Testen von Extremwerten ist mir das Problem, welches Albedo erwähnt hatte ebenfalls aufgefallen.

Ein weiteres Problem, das ich als kritischer erachte ist, dass die Inversionsformeln nicht zu den Vorwärtsumformungen "passen". Am Beispiel von $L^{*}$ bzw. $L_{99}$ ist das ganz klar zu sehen.
Könnte das jemand bestätigen? Hat jemand Zugang zum Standard selbst und kann die Formeln korrigieren?

--80.218.115.161 03:04, 19. Jun. 2008 (CEST)

Könnten Umformungsfehler meinerseits sein. Ich werde die Formeln noch einmal überprüfen und mich gegebenenfalls melden bzw. die Fehler korrigieren.

So, habe jetzt mal meine Implementation mit den Testwerten der DIN geprüft. Alles funktioniert einwandfrei. Die hin- und Rücktransformation laufen ohne Fehler.

Die Testwerte sind hier zu finden: http://www.engl.dfwg.de/doc/dfwg%20homepage%20engl-499.htm

Ich habe den Fehler gefunden. In der TeX-Schreibweise ist mir die -1 in die Klammer hineingerutscht. Jetzt steht sie außerhalb, so wie es sein sollte. Ich hoffe, dass damit alles in Ordung ist.

hier ist meine meine korrekt funktionierende MuPad-Implementation der Konvertierung, falls doch noch Probleme auftauchen sollten:

Arctan2 := proc(x,y)
begin
winkel:=0.0:
if x > 0 then winkel := arctan(y/x):
elif (x < 0 and y >= 0) then winkel := arctan(y/x)+PI:
elif (x < 0 and y < 0) then winkel := arctan(y/x)-PI:
elif (x = 0 and y > 0) then winkel := PI/2.0:
elif (x = 0 and y < 0) then winkel := -PI/2.0:
else winkel := 0.0:
end_if:
radiant:=float(winkel):
return(radiant)
end:

LAB2DIN99:=proc(Lstar,aStar,bStar)
begin
angle:=float(PI*4/45): //16°
L99Factor:=100.0/ln(129/50.0):
//L99Factor:=105.51: unkorrigierter L99-Wert
L99:=L99Factor*ln(1.0+0.0158*Lstar):
if (aStar=0 and bStar=0) then a99:=0.0: b99:=0.0:
else
   e:=aStar*cos(angle)+bStar*sin(angle):
   f:=0.7*(bStar*cos(angle)-aStar*sin(angle)):
   G:=(e^2+f^2)^0.5
   g:=0.045*G:
   k:=(ln(1+g))/g:
   a99:=k*e:
   b99:=k*f: 
end_if:
return(L99,a99,b99)
end:

DIN992LAB :=proc(L99,a99,b99)
begin
epsilon:=216/24389:
kappa:=24389/27:
L99Factor:=100.0/ln(129/50.0):
angle:=float(PI*4/45):
kE:=1.0:
kCH:=1.0:
h99ef:= Arctan2(a99,b99):
C99 := (a99^2+b99^2)^0.5:
G:= (exp(0.045 * kE * kCH * C99)-1.0)/0.045:
e:= G*cos(h99ef):
f:= G*sin(h99ef):
aStar:= float(e * cos(angle) - (f/0.7) * sin(angle)):
bStar:= float(e * sin(angle) + (f/0.7) * cos(angle)):
Lstar:= (exp(L99*kE/L99Factor)-1.0)/0.0158:
return(Lstar,aStar,bStar)
end:

--Al'be:do 15:16, 30. Okt. 2008 (CET)

Die Maskierung der Inversen ist doppeldeutig. Bei der Berechnung von $\mathrm {h_{99,ef}}$ wird

$h_{99,ef}=\arctan \left({\frac {b_{99}}{a_{99}}}\right)$ , für $a_{99}>0$ und $b_{99}$ ≥ 0

und später

$h_{99,ef}=2\,\pi +\arctan \left({\frac {b_{99}}{a_{99}}}\right)$ , für $a_{99}>0$ und $b_{99}$ ≤ 0

angeben. Für den Fall $a_{99}>0$ und $b_{99}=0$ ergibt sich damit der doppeldeutige Fall $\mathrm {h_{99,ef}} =0$ bzw. $\mathrm {h_{99,ef}} =2\pi$. In Winkeln ausgedrückt stimmt das Ergebnis natürlich überein, allerdings ist die Maskierung hier nicht eindeutig.

--185.17.205.185 23:33, 3. Apr. 2016 (CEST)

vollständige Gamut-Darstellung zur Messung des Volumens von Monitorfarbräumen etc.

Ich erstelle im Moment weitere Diagramme zur Erläuterung der Transformationen in den DIN99-Farbraum, die ich bald hinzufügen werde. Ich habe auch vor, farbige Versionen der 3D-Schnittdarstellungen zu programmieren. Ein weiteres Bild, das ich momentan erstelle, ist ein 100-Schnittebenen-Bild analog zu Gernot Hoffmanns "Hungams"-Bild (Measuring Gamut Volumes by Hundred Slices). Ein PDF hierzu gibt es unter http://www.fho-emden.de/~hoffmann/hungams17042004.pdf.

Hier ist eine Vorschau der DIN99-Version (vorerst nur der Lab-kodierte Bereich, transformiert in DIN99-Koordinaten, vorläufige Version). Gezeigt wird der Farbraum des Wide-Gamut-Monitors HP LP 2480zx. Das bauchige gedrehte "Rechteck" ist die Transformation des in Photoshop kodierbaren Lab-Farbraums (L=0..100, a=-128..127, b=-128..127) in den DIN99-Farbraum. 1 Pixel entspricht 1 $\Delta E_{99}$. Quantisierungsfehler liegen bei etwa 0.5 $\Delta E$. Wegen dieses Quantisierungsfehlers sind die Schnitte durch sehr dunkle Ebenen (siehe oben links) nicht korrekt, da die Lab-Quantisierung zu Grob ist, um die niedrigen L_99-Werte korrekt darzustellen. Ähnliche Quantisierungsfehler treten an ein paar anderen Schnittebenen ebenfalls auf. Ich versuche einen Weg zu finden, diese Einschränkung zu umgehen. 16-bit-Lab könnte eine Lösung sein, doch leider können nur 8-Bit-Werte in Photoshop eingegeben werden. Eventuell funktioniert RGB besser. Mit den imaginären Primärfarben des CIE1931Yxy-Farbraumes als Gerätefarbraum sollte es möglich sein. Das Photoshop-Farbmanagement kann das auf jeden Fall verarbeiten. Später werden noch die entsprechenden MacAdam-Limits hinzugefügt, um eine tatsächliche Gamut-Beurteilung zu ermöglichen. CIELab beinhaltet eine Menge unphysikalischer Körperfarben und beschneidet wiederum den Optimalfarbkörper an anderen Stellen. Dieses Schaubild wird sozusagen eine Fortgeschrittene Version von Gernot Hoffmanns Gamut-Darstellung.

--Al'be:do 13:25, 30. Okt. 2008 (CET)

Sorry, polar vs kartesich

Hallo Al'be:do Sorry hab mich da wohl vertan und schwups war die Diskussion weg  :( und ich hab keine Ahnung wie man das wieder rückgängig macht. Gruss --Tambores 17:47, 13. Nov. 2011 (CET)

Einfach demnächst ganz in Ruhe vorgehen, dann passiert so etwas nicht mehr ;) --Al'be:do 18:51, 17. Nov. 2011 (CET)

Polare Variante mit k_e und k_ch vs. kartesische Variante ohne k_e und k_ch - Fehler in der Formel?

Hab die Formeln nur schnell überflogen, aber folgendes geht für mich nicht auf. Vielleicht hat jemand ja eine Erklärung dazu.

A.) Per Definition sind:

a99= f(a*, b*) // Weder ke noch kch darin

b99= f(a*, b*) // Weder ke noch kch darin

B.) Per Definition sind:

C99= f(a*, b*, kch,ke)

h99= f(a*, b*)

C.) Dann kommt Abschnitt: Bunttonwerte (alternativ)

a99= f(C99) // Also hier kommt via C99 auf einmal kch und ke zum tragen?

--> Geht doch irgendwie nicht auf! Und darum vielleicht die Empfehlung von DIN kch= ke = 1 zu belassen, damit kartesische und polare Koordinaten konsistent bleiben?

Ansonsten muss man doch a99 und b99 _immer_ per Alternative berechnen oder es muss gelten ke*kch == 1!

Fehler in der Formel L99? vgl. ASTM Norm

L99= ke * 105.509 * ln(1.0 + 0.0158 * L*) und nicht L99= (1/ke) * ....

Gruss Tambores (nicht signierter Beitrag von 188.61.188.29 (Diskussion) 17:58, 14. Okt. 2011 (CEST))

Hey, Tambores! Danke für die Hinweise. Ich habe eventuell den Reziprokwert aus der ΔE-Formel übernommen, statt, wie du korrekterweise schreibst, den richtigen Vorfaktor zu verwenden. Das Dumme war, dass ich zu der Zeit über die Faktoren k_E (Helligkeitsfaktor) und k_CH (Chroma/Hue-faktor) nichts näheres finden konnte, nur im Zusammenhang mit der Alternativformel. Ich musste da leider ein wenig selbst herum basteln.

Ich werde den Artikel eh anpassen müssen, da die derzeitige Norm schon bei Variante DIN99o angekommen ist. Dazu habe ich auch eine Vollständige Implementation inklusive k_E und k_CH. Hier ist meine kommentierte Matlab-Implementation:

Konversion von DIN99o zu CIELAB

% Conversion from CIELAB color space to DIN99 coordinates
% input: [L,a,b]
% --------------------------------------------------------------

L99o = Lab99o(1);
a99o = Lab99o(2);
b99o = Lab99o(3);
kE = 1.0; %brightness factor, 1.0 for CIE reference conditions
kCH = 1.0; %chroma and hue factor, 1.0 for CIE reference conditions

ang = 2*pi/360*26; %26 degrees in radians
L99f = 100/log(139/100.); %corrected L99 factor
%L99f = 303.67; %original L99 factor
L = (exp(L99o*kE/L99f)-1.0)/0.0039;

h99ef = atan2(b99o,a99o); %arctan in four quadrants

heofo = h99ef-ang; %backwards hue rotation

C99 = sqrt(a99o^2+b99o^2);     %DIN99 chroma
G = (exp(0.0435 * kE * kCH * C99)-1.0)/0.075; %factor for chroma decompression and viewing conditions
e = G*cos(heofo);
f = G*sin(heofo);

a = (e * cos(ang) - (f/0.83) * sin(ang)); %rotation by 26 degrees
b = (e * sin(ang) + (f/0.83) * cos(ang)); %rotation by 26 degrees

Lab = [L a b];

 result = Lab;

Hier die Konversion von CIELAB zu DIN99o

% Conversion from CIELAB color space to DIN99 coordinates
% input: [L,a,b]
% --------------------------------------------------------------

L = Lab(1);
a = Lab(2);
b = Lab(3);
kE = 1.0; %brightness factor, 1.0 for CIE reference conditions
kCH = 1.0; %chroma and hue factor, 1.0 for CIE reference conditions

ang = 2*pi/360*26; %26 degree angle in radians
L99f = 100/log(139/100.); %L99 scaling factor - method 1
%L99f = 303.67; %original L99 factor
L99o = L99f/kE*log(1+.0039*L); %Lightness correction kE

if a==0.0 && b==0.0, a99o = 0.0; b99o = 0.0;
else eo = a*cos(ang) + b*sin(ang);       %a rotation
     fo = 0.83*(b*cos(ang) - a*sin(ang)); %b rotation/stretching
     Go = sqrt(eo^2 + fo^2);         %chroma
     C99o = log(1.0 + 0.075 * Go) / (0.0435 * kCH*kE);  %factor for chroma compression and viewing conditions
    heofo = atan2(fo,eo); %arctan in four quadrants
     h99o = heofo+ang;  %hue rotation
    a99o = C99o * cos (h99o);
    b99o = C99o * sin (h99o);
   
end;
DIN99o = [L99o,a99o,b99o];

 result = DIN99o;

Die Faktoren hatte ich nach langer Suche im Buch Klein, G.A.: „Industrial Color Physics“ (2010) gefunden, die englische und überarbeitete Fassung von Klein, G.A.: „Farbenphysik für industrielle Anwendungen“, Springer, Berlin, Heidelberg(2004)

Im Prinzip müssten die k-Faktoren bei DIN99 analog zu DIN99o gesetzt sein.

--Al'be:do 15:00, 24. Okt. 2011 (CEST)

Ich habe jetzt noch einmal in besagtem Buch nachgesehen. Für DIN99o gilt dort auf jeden Fall

$\mathrm {L_{99o}} ={\frac {303,\!67}{k_{E}}}\cdot \ln \left(1,\!0+0,\!0039\cdot \mathrm {L^{\ast }} \right)$

Hier ist die entsprechende Seite bei Google Books: [zu der Formel im oben genannten Buch]

Da DIN99o und DIN99 strukturell gleich sind, bin ich ehrlich überrascht, dass k_E nicht im Nenner stehen soll. Da gibt es natürlich zwei Möglichkeiten: Entweder ist die Formel in meinem Buch falsch oder die ASTM geht von einem Faktor k_E=1 aus, denn dann wäre 1/k_E = k_E.

Beides würde mich nicht überraschen. Ich habe in Farbmetrikbüchern und papers schon derartige Fehler gesehen bzw. viele Autoren vernachlässigen einfach diese Faktoren, weil sie halt bei Standardbedingungen keine Rolle spielen. Gibt es in der ASTM-Norm vielleicht eine hilfreiche Fußnote oder eine Erläuterung dazu?

--Al'be:do 22:11, 24. Okt. 2011 (CEST)

Für DIN99d habe ich die entsprechende Formel ebenfalls mit k_E im Nenner gefunden. --Al'be:do 18:21, 25. Okt. 2011 (CEST)

ASTM Erläuterung

Hallo Al'be:do, Danke für deine ausführliche Antwort und dafür, dass Du dich so intensiv für dieses Thema engagierst. Ich versuch mein Bestes, dich dabei zu unterstützen, damit ein wenig Licht in diesen Dschungel kommt. Leider ist Herr Gall ja verstorben, er hätte sicher noch einzelne spitze Bemerkungen zu den aktuellen Flickwerken der Normenbüro's auf Lager gehabt (vgl. seine Anmerkung zur 2K Formel auf seiner hp).

****Eine wirklich schlüssige Bemerkung zu den Faktoren habe ich bei ASTM nicht gefunden, nur das hier:

Default parameters are: kE = kCH = 1, kE (1 : kCH). ..............// Wie kE (1 : kCH) zu interpretieren ist mir auch nicht wirklich klar

For textiles the following equivalence relations holds: To

obtain an equivalent computed difference to a CMC (l = 2,

c = 1) difference, use the parameters: 2 (1 : 0.5), which indicate

that kE = 2 and, kCH = 0.5.

Man beachte: In beiden Fällen ist dabei kE * kCH = 1, aber ob das sein muss oder soll ist mir nicht klar.

****Und ja wie du zu recht sagst, z.T. ist auch die Literatur falsch, so auch schon ASTM und DIN Entwürfe. Sind halt auch alles nur Menschen am werkeln. Ich bestell mir mal die aktuellsten DIN Normen dazu. Vielleicht klärt sich dies und das (obwohl die Chancen eher klein sind).

****Das ganz grosse Dilemma aus meiner Sicht ist, dass der DIN99 Farbraum eigentlich ein klein wenig besser ist als CIELAB, aber die ganze Industrie ist dermassen auf CIELAB eingeschossen, dass allenfalls die dE99 benutzt wird wenn überhaupt. Wie lange gibt es schon dE2k, dEcie94 etc. aber das höchste was in der Praxis benutzt wird ist immer noch dEcmc. Schlimmer noch die Automobilbranche lässt zum grossen Teil nur dE* zu und dies mit völlig praxis-fremden Toleranzen wie dE* < 0.25 :(

****Aus meiner Sicht würde es Sinn machen, Testvektoren basierend auf ?Spektren/XYZ/Lab*? für die Berechnung reinzustellen. Bin gerne bereit gegenzurechnen, will ja auch meine Implementation verifiziert haben :)

Sorry für die Formatierungen meiner Texte, bin ein Wiki Noob.

Gruss --Tambores 23:04, 11. Nov. 2011 (CET)

Im Bereich kleiner bis mittlerer Farbabstände ist DIN99d/o nicht nur ein klein wenig besser als CIELAB, wenigstens nach den Analysen zu urteilen, die ich kenne. Bei kleinen Farbdifferenzen ist nur DE 2000 SCD knapper Sieger, CIELAB ist so ziemlich am schlechtesten. Bei großen Farbdifferenzen sieht CIELAB nicht mehr ganz so schlecht aus, aber dort ist der Gebrauch von DIN99 gar nicht vorgesehen. Und DE 2000 LCD ist wiederum in dem Bereich am besten. Das Problem ist natürlich, dass derartige Qualitätsbeurteilungen sehr von den verwendeten Farbdatensätzen abhängen, da alle modernen Formeln und Farbräume auf unterschiedliche Datensätze hin optimiert sind. Außerdem kommt noch hinzu, dass die Betrachtungsbedingungen nicht immer gleich sind, was meiner Ansicht nach sowieso auch getestet werden sollte, da Formeln, die universell oder wenigstens in größeren Bereichen anwendbar sind, zweckmäßiger sind und Daten auch besser vergleichbar machen könnten. Auch scheinen viele Leute sich wenig darüber im Klaren zu sein, was die Werte bzw. Ergebnisse der Qualitätsberechnungen mathematisch eigentlich zu bedeuten haben und wie sie zu interpretieren sind.

Ich sehe die ganze Sache nicht ganz so verbittert, denn die Farbmetrik deckt einen riesigen Fächerbereich ab, vom Farbmischen bis zur Neurologie und Wahrnehmungspsychologie. Es ist kein Wunder, dass es noch viele Bereiche gibt, in denen sich noch viel bewegt und bestimmt noch einige neue Erkenntnisse gewonnen werden. Ich bin zum Beispiel ehrlich überrascht, dass das Problem der Euklidisierung der Farbräume so wenig von der Mathematischen Seite her beleuchtet wird, zumindest fehlt das Bewusstsein dafür in der „Öffentlichkeit“. Es ist prinzipiell unmöglich, einen Farbraum, der gleichzeitig sowohl „positiv gekrümmte“ als auch „negativ gekrümmte“ Metrik besitzt, „flach“ zu drücken. Schon in MacAdams Buch wird darauf eingegangen, man erinnere sich an das bekannte gewölbte Papiermodell des gleichabständigen Hufeisendiagramms. Auf YouTube gibt es einen interessanten Vortrag zum Umgang mit diesem Problem, wie man z.B. die Krümmung des Raumes wenigstens lokal behandeln kann.

So kleine Farbtoleranzen, wie z.B. für Autolacke können manchmal sinnvoll sein, wenn es sich etwa um nahezu neutrale Farben handelt. Da macht ΔE>1 schon mal den Unterschied zwischen rotstichig und grünstichig aus. Ich übertreibe natürlich, aber das Prinzip stimmt schon. --Al'be:do 19:18, 17. Nov. 2011 (CET)

Danke für die Wiederherstellung. Bin echt noch _der_ Wiki Noob!

Deiner Beurteilung dass solche kleinen Farbtoleranzen (dE* < 0.25) gerechtfertigt sind (ich gehe davon aus, dass Du mit neutralen Farben „unbunt“ meinst) möchte ich aus Sicht eines Praktikers widersprechen, da nur schon die Messtechnik / Umgebungsbedingungen eine ebensolche Streuung "locker" hergeben. Will heissen, diese Genauigkeit kann man allenfalls unter Laborbedingungen erreichen, aber ich treffe solche Forderungen für die Produktion an.

Was Du sonst noch geschrieben hast, muss ich zuerst verarbeiten :)

Und zum Schluss: Ich bin nicht am resignieren oder verbittert, nur „einfach“ nach der Suche nach praktikablen Lösungen.

Gruss --Tambores 20:29, 18. Nov. 2011 (CET)

Richtig, unbunt. Ich stecke manchmal zu sehr im englischen Sprachgebrauch fest, da die meisten Quellen, die ich lese englisch sind. ;) Nun, die Beurteilung von Farbabständen ist natürlich so eine Sache und u.a. sehr abhängig von der Art der Farbproben. Sind die Farben matt oder glänzend? Darum gibt es z.B. die Munsell-Datensätze für glänzende und matte Farben. Wie ist die Oberfläche strukturiert? Wie verhalten sich die Farben unter anderen Lichtquellen? Spielt Metamerie eine Rolle? Ich habe zumindest im Zusammenhang mit der DIN99-Entwicklung gelesen, dass eben die höhere Empfindlichkeit in sehr schwach gesättigten nahezu unbunten Farbbereichen die tatsächliche Unterscheidungsfähigkeit je nach Umständen unter 0,5 ΔE betragen kann. Aus diesem Grund wird ja der Bereich nahe der Unbuntachse in den DIN99-Farbräumen durch die radiale „Chroma“-Kompression stärker gewertet als im CIELAB-Farbraum.

Was die Suche nach praktikablen Lösungen angeht - das ist durchaus legitim, aber in Wikipedia-Artikeln kaum zu befriedigen. Es geht hier ja nicht um Anleitungen für Autolack-Herstellung oder um die Mischung von Druckertinte. Es geht um die Farbmetrik und den Farbraum im Allgemeinen. Ein Wikipedianer, ebenfalls ein Praktiker, meinte etwa, er müsse den Farbraum-Artikel in eine für Druckereigewerbler passende Anleitung für die korrekte Anwendung von Colorimetern und Scannern umschreiben (ich übertreibe hier ein wenig). Das funktioniert aber nicht gut, denn, wie gesagt, gibt es ja nicht nur Druckereifachleute, sondern auch Wahrnehmungspsychologen, Physiker, Biologen, Ophtalmologen usw. Wikipedia ist ja kein Branchenspezifisches Handbuch zur Anwendung bestimmter Geräte ;)

Ich glaube eher, dass das Problem, das du beschreibst, mit einer grundsätzlich mangelhaften fachspezifischen Ausbildung der Entscheider über solche Farbtoleranzen zu tun hat. Produktionsbedingungen sind eben keine Laborbedingungen. Trotzdem sind die Laborbedingungen notwendig um verläßliche Daten zu sammeln und um eine gute Basis für den theoretischen Unterbau der Farbmetrik zu schaffen. Wenn bestimmte Personen nicht in der Lage sind, Toleranzen in der Beleuchtung und den Umgebungsbedingungen für die Farbbeurteilung (z.B. ausreichende Zeit zur Adaptation an die Umgebungsbedingungen), Beleuchtungs- und Beobachtermetamerie, prinzipielle Produktionsschwankungen usw. zu berücksichtigen, spricht das zwar gegen die Kompetenz dieser Personen, aber nicht gegen die prinzipiellen Erkenntnisse der Farbmetrik, die sich ja um die Grundlagen kümmert - ohne etwa an einen Produktionszweck gebunden zu sein.

Es ist aber durchaus in Ordnung, z.B. auf branchenspezifische Besonderheiten oder praktische Probleme hinzuweisen, die ja auch in der Farbmetrik nicht geleugnet werden.

Ich bin kein Praktiker im produzierenden Gewerbe und beschäftige mich eher mit den theoretischen Grundlagen aus reiner Neugier und langjährigem Interesse, z.B. um Progrämmchen zur Spektralanalyse, Metamerie/Paramerie, IAMs usw. zu schreiben. Einfach nur, weil’s riesigen Spaß macht und weil man dabei auch noch eine Menge lernt. --Al'be:do 12:49, 21. Nov. 2011 (CET)

DIN99d Formeln

Die Formeln zu DIN99d habe ich in diesen beiden Arbeiten gefunden : Yang Xue (2008) und Shizhe Shen (2009). Was aus beiden nicht klar wird: Muss man die Modifikation an X auch für den Weißpunktwert X_w vornehmen (was ich vermuten würde, d.h. den ganzen XYZ-Farbraum in X transformieren), oder nur an X selbst? Denn im LAB-Farbraum müssen neben den XYZ-Werten der Zielfarbe auch die XYZ-Werte des Weißpunkts angegeben werden. Wenn das geklärt ist, könnte man die Formeln für DIN99d dann auch hier einbauen.--SiriusB (Diskussion) 21:59, 11. Jul. 2012 (CEST)

Nachtrag: Es kann nur so gemeint sein, dass auch der Weißpunkt transformiert wird, denn sonst wäre die Buntheit C am Weißpunkt nicht null.--SiriusB (Diskussion) 14:11, 13. Jul. 2012 (CEST)

Soweit ich weiß, wurde der Weißpunkt für CIELAB auf D65 geändert. Wenn man sich die Adobe-Profile im Detail ansieht, wirt immer D65 als Weißpunkt angegeben; vorher lag er bei D50. C als Weißpunkt kommt mir ziemlich veraltet vor. --Al'be:do 15:25, 25. Nov. 2012 (CET)

Abgesehen davon wird ja schon im CIELAB eine Weißpunktadaptation vorgenommen. Der Nullpunkt verschiebt sich bei der Transformation von CIELAB zu Din99o nicht. --Al'be:do 12:13, 27. Nov. 2012 (CET)

Vergleich 99d vs. 99o

Da es hier Pläne gibt, die Formeln für die aktuelle DIN99o einzubauen, während im Text DIN99d als derzeit bester DIN-Farbraum genannt wird, wäre es ein Performance-Vergleich der beiden Versionen hilfreich. Ist 99o gegenüber 99d eine Verbesserung hinsichtlich der Farbabstände, oder ist die Vereinfachung der Umrechnung (keine XYZ-Modifikation nötig) der Vater des Gedankens? Da 99o die aktuelle Version ist, sollte diese Information, samt Quellen, unbedingt im Artikel gebracht werden.

Man könnte darüber hinaus auch überlegen, die Formeln für 99d und 99o (samt Programmcode; vorzugsweise C oder Java, zumindest eine verbreitere Programmiersprache) in ein Wikibook zu bringen, und hier im Artikel nur die aktuelle 99o (die sich aus den vorhandenen Formeln leicht durch Ersetzen der Koeffizienten ergibt).--SiriusB (Diskussion) 13:59, 13. Jul. 2012 (CEST)

Ich habe im Moment viel zu tun, werde mich aber darum kümmern. Ich habe in der Literatur nur die üblichen Hinweise auf die verwendeten Datensätze (Witt/Rit-DuPont/Luo/Cui etc.) finden können, mit den entsprechenden Qualitätsbewertungen. Direkte Vergleiche zwischen unterschiedlichen DIN99-Versionen und konkrete Daten habe ich nicht finden können; wohl aber die Erwähnung der Rückkehr zu einer einfacheren Berechnung im Falle der DIN99o und einer besseren Bewertung von Farbabständen als Resultat. --Al'be:do 15:37, 25. Nov. 2012 (CET)

Transformation

Die Transformation ähnelt einer Potenzfunktion mit einem Exponenten von 0,75.

Eine ganz gute Approximation für $105.51\ln(1+0.0158x)$ ist für niedrige Werte ${\frac {5}{3}}x$, aber wie $x^{\frac {3}{4}}$ da reinpassen soll, erschließt sich mir nicht offensichtlich. — Christoph Päper 14:54, 21. Jan. 2020 (CET)

Din99o Beispielberechnungen

@Crissov:, kann es sein, dass die Werte für a99o und b99o in der Beispieltabelle nicht stimmen? Ich komme mit [50,50,50] auf [54.09765212 40.38288205 11.54110136] TiHa (Diskussion) 11:03, 16. Jul. 2021 (CEST)

Die Formel im Artikel stimmt wohl nicht, mit der MatLab-Variante oben komme ich auf die Werte... TiHa (Diskussion) 12:46, 16. Jul. 2021 (CEST)

Ich habe die Beispielwerte gerade nochmal überprüft: sie entsprechen der Tabelle in der Norm. Ich habe auch keine Fehler in den Formeln entdeckt, kann aber durchaus etwas übersehen haben. — Christoph Päper 17:56, 18. Jul. 2021 (CEST)

Das hier scheint nicht zu stimmen:

Bundtonwerte

$a_{99}=k\cdot {\frac {e}{G}}$

$b_{99}=k\cdot {\frac {f}{G}}$

So hab ich die Herleitung im Artikel interpretiert:

       e = a*cos26 + b*sin26
       f = 0.83*(-a*sin26 + b*cos26)
       G = (e**2+f**2)**.5
       k = log(1+0.075*G)/0.0435
       a99 = k*e/G
       b99 = k*f/G

TiHa (Diskussion) 09:00, 19. Jul. 2021 (CEST)