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)

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)