Diskussion:DIN99-Farbraum

message: 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)
thread_title: Helligkeitstransformation - Ein Fehler in der Norm

message: 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)
thread_title:  vollständige Gamut-Darstellung zur Messung des Volumens von Monitorfarbräumen etc. 

message: 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)
replies: text: Einfach demnächst ganz in Ruhe vorgehen, dann passiert so etwas nicht mehr ;) --Al'be:do 18:51, 17. Nov. 2011 (CET)
thread_title:  Sorry, polar vs kartesich 

message: 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 Xw 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  DIN99d Formeln 

message: 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)
replies: text: 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)
thread_title:  Vergleich 99d vs. 99o 

message: Die Transformation ähnelt einer Potenzfunktion mit einem Exponenten von 0,75.
Eine ganz gute Approximation für 105.51 \ln(1+0.0158 x) ist für niedrige Werte \frac53x, aber wie x^\frac34 da reinpassen soll, erschließt sich mir nicht offensichtlich. — Christoph Päper 14:54, 21. Jan. 2020 (CET)
thread_title:  Transformation