Hallo!

Dass bei einer normalen ICC-Farbraumtransformation das Quell- und Zielprofil zu einer neuen, latenten Tabelle verrechnet werden und somit quasi ein temporäres DeviceLink-Profil ergeben, wurde ja hier im Forum schon mehrmals besprochen. Meist heißt es in diesem Zusammenhang auch, dass dies unter anderem deshalb gemacht wird, um die Genauigkeit der Transformation zu erhöhen. Da ja dann bei der tatsächlichen Transformation nur noch ein Schritt notwendig ist: vom Quell- ins Zielprofil, ohne den Zwischenschritt PCS.

Hier liegt allerdings mein Verständnisproblem. Warum genau wird denn die Rechengenauigkeit höher bzw. warum werden so Rundungsfehler umgangen?
Es muss doch egal sein, ob ich die Transformation quasi "am Bild" durchführe (also Quelle > PCS > Ziel) oder ob ich vorher alle Stützpunkte der beiden Profile miteinander verknüpfe und dann nur noch die entsprechende Werte aus der Tabelle suche? Somit verschiebe ich den Vorgang doch nur in eine vorangehenden Prozess ...

Was entgeht mir hier? Ich bin für jeden Hinweis dankbar.

LG fprince

Hallo,

man hat ja pro Kanal nur 256 Abstufungen (bei 8 Bit). Wenn es blöd läuft, wird aber bei zweimaliger Transformation 2x hintereinander knapp abgerundet, macht man das ganze aber mit einer Transformation, wird nur 1x abgerundet. Ist aber in der Praxis bei nur 2 Transformationen wohl eher akademischer Natur.
Man könnte sicher auch erst auf 16 Bit gehen, dann die Transformationen durchführen und am Ende wieder auf 8 Bit zurückgehen. Dann wären Rundungsfehler auch kein Problem.

Antwort auf [ fprince ]

Warum genau wird denn die Rechengenauigkeit höher bzw. warum werden so Rundungsfehler umgangen?

Das direkte Verlinken einer CMYK->Lab und einer Lab->CMYK Tabelle geschieht 12 oder noch mehr bittig, sprich es wird nicht von 8bittiggem CMYK auf 8bittiges Lab(oder noch niedriger, da der Lab Farbraum ja nur zu einem recht kleinen Teil mit realen Farben gefüllt ist) gerechnet, sondern es werden 12bittige CMYK Werte über 12 bittige LAB-Werte mit anderen 12bittigen CMYKwerten verknüpft. Bei der eigentlichen Transformation wird dann mit der gelieferten Bittiefe des Quellmaterials einfach in die gleiche Bittiefe des Endfarbraums gerechnet. Das ist bei binärer Verarbeitung ja einfach, indem ein beliebig bittiger Wert einfach nur bis zur gebrauchten Bitzahl gelesen wird, der Rest fällt einfach hinten runter:

Werte bei 10 bit:
511 --> 0111111111 wird 8bittig zu 01111111| 11 =127
512 --> 1000000000 wird 8bittig zu 10000000| 00 =128
513 --> 1000000001 wird 8bittig zu 10000000| 01 =128
514 --> 1000000010 wird 8bittig zu 10000000| 10 =128
514 --> 1000000011 wird 8bittig zu 10000000| 11 =128
515 --> 1000000100 wird 8bittig zu 10000001| 00 =129

Bedeutet das mit einer höherbittigen CMYK-CMYK Tabelle nahezu beliebig genaues Datenmaterial transformiert werden kann, ohne das ganze bei den üblichen 8bit zu verlangsamen.

Hoffe, das ist halbwegs verständlich. Ansonsten mal die Suche bemühen, ich hab das, glaube ich, hier schon mal irgendwann zu erklären versucht.

Vielen Dank euch beiden.

Leider sind mir allerdings noch ein paar Sachen unklar:

Zitat

Das direkte Verlinken einer CMYK->Lab und einer Lab->CMYK Tabelle geschieht 12 oder noch mehr bittig

Ist das tatsächlich nur bei CMYK zu CMYK oder auch RGB zu CMYK? Und warum gerade 12 bit, ist das eine Eigenheit des ICC-Profils oder der CMM?

Zitat

sprich es wird nicht von 8bittiggem CMYK auf 8bittiges Lab gerechnet

D.h. diese direkte Verknüpfungstabelle bietet nur einen Mehrwert bei 8-Bit Bildern?

Wie sich das ganze in der Praxis auswirkt, habe ich allerdings noch immer nicht verstanden ...

Angenommen ich habe ein RGB 128/128/128 (bei 8 Bit) und konvertiere das. Dann wird es zunächst auf 12 bit skaliert, also wird aus 128 > 2048. Und die Tabelle sagt nun 2048 wird zu 2064. 2064 wird wieder zurückskaliert und ergibt somit 129. Wo spare ich hier Rundungsfehler ein?
Denn wie können 8 bit Daten genauer werden, wenn ich sie mit 16 bit umrechne, wo es doch keine Kommazahlen gibt? Sorry, aber ich stehe echt auf der Leitung.

Zitat

Ansonsten mal die Suche bemühen, ich hab das, glaube ich, hier schon mal irgendwann zu erklären versucht.

Das konnte ich leider nicht finden.

Vielen Dank!

LG fprince

128/128/128 als RGB IST EIN super Beispiel. Überleg mal auf welchen Wert das im Lab gerechnet wird und wo es eigentlich landen müsste.

Zitat

128/128/128 als RGB IST EIN super Beispiel. Überleg mal auf welchen Wert das im Lab gerechnet wird und wo es eigentlich landen müsste.

Angenommen wir gehen von einem L-Star Gamma aus, dann müsste es auf etwa 50,19 landen. Es wird aber natürlich zu 50. D.h. diese 0,19 sind die Ungenauigkeit, die ich mit mehr Bit verhindern kann, oder?

LG fprince

Die 0,19 sind es nicht wirklich, die den Kohl fett machen. Das Problem: Bei 256 Stufen von 0-255 gibt es keine Mitte. Dem Lab fehlt 8-bittig die Mitte, sprich es gibt kein neutrales Grau. Und bei den neutralen Tonwertstufen wird es sicherlich nicht immer in die gleiche Richtung springen, du bekommst also von weiß nach Schwarz einen hübschen Regenbogen.

Das Problem bei 8 bittiger Berechnung des Lab ist, dass du etwa 2 Bit verlierst, weil Lab per Definition nicht komplett gefüllt ist, wie es bei RGB und bei CMY(K) der Fall ist.
Aus dem Grunde werden die beiden Transformationen von und zu Lab mit höherer Bittiefe zu einer direkten Quell->Ziel Verrechnung.
10 und 12 Bit ist ein häufig anzutreffender Wert in den LUTs, da es ein sinnvoller Kompromiss aus zusätzlicher Genauigkeit, bei nicht unnötigem Overhead mangels ausreichender Messgenauigkeit( bzw. probenbedingte Schwankungen bei der Messwerterfassung) der zugrunde liegenden Charakterisierungsdaten darstellt.

Ich finde deine Antworten immer wahnsinnig interessant und danke dir dafür, allerdings werfen sie in diesem Fall noch mehr Fragen auf :)

Zitat

Dem Lab fehlt 8-bittig die Mitte, sprich es gibt kein neutrales Grau.

Neutrales oder mittleres? Neutral heißt doch in diesem Zusammenhang nur kein a oder b.

Zitat

Dem Lab fehlt 8-bittig die Mitte

Wie handelt Photoshop das eigentlich im L-Kanal? Wird da bei 8-bit von dem Definitionsbereich 0...100 auf 0...255 aufskaliert?

Zitat

Das Problem bei 8 bittiger Berechnung des Lab ist, dass du etwa 2 Bit verlierst, weil Lab per Definition nicht komplett gefüllt ist

Das LAB nicht komplett gefüllt ist, ist mir klar. Aber bedeutet das dann, dass nur etwa 262.000 Farben zur Berechnung zur Verfügung stehen?

Zitat

10 und 12 Bit ist ein häufig anzutreffender Wert in den LUTs

Hmm? Ich habe gerade einige Profile im ColorSync-Dienstprogramm studiert, und dabei fiel mir auf, dass im Beschreibungsreiter der A2B und B2A Tabellen immer 16-Bit steht. Ist das nun dasselbe von dem du sprichst nur mit einer anderen Bittiefe oder lese ich hier am falschen Ort?



Vielen Dank und LG
fprince

Antwort auf [ fprince ]

Zitat

Dem Lab fehlt 8-bittig die Mitte, sprich es gibt kein neutrales Grau.

Neutrales oder mittleres? Neutral heißt doch in diesem Zusammenhang nur kein a oder b.

Sowohl als auch. Auch eine mittlere Garaustufe gibt es nicht. 128 ist in der hellen hälfte. 127 in der dunklen, die Mitte wäre 127.5, aber die gibts bei 8 bit eben nicht.

Antwort auf [ fprince ]

Zitat

Dem Lab fehlt 8-bittig die Mitte

Wie handelt Photoshop das eigentlich im L-Kanal? Wird da bei 8-bit von dem Definitionsbereich 0...100 auf 0...255 aufskaliert?

Wie beim CMYK auch werden beim Lab bei 8bittigen Daten intern mit Werten von 0-255 gerechnet.

Antwort auf [ fprince ]

Das LAB nicht komplett gefüllt ist, ist mir klar. Aber bedeutet das dann, dass nur etwa 262.000 Farben zur Berechnung zur Verfügung stehen?

Nein, das war übern Daumen gepeilt, hängt ja auch davon ab wie groß der jeweilige Gamut tatsächlich ist.

Das Programm Colorthink rechnet irgendwie die Volumen der Gamuts aus:
ECI RGB: 1.330.440
sRGB: 832.478
ISOcoatedV2:504.279

Antwort auf [ fprince ]

Zitat

10 und 12 Bit ist ein häufig anzutreffender Wert in den LUTs

Hmm? Ich habe gerade einige Profile im ColorSync-Dienstprogramm studiert, und dabei fiel mir auf, dass im Beschreibungsreiter der A2B und B2A Tabellen immer 16-Bit steht. Ist das nun dasselbe von dem du sprichst nur mit einer anderen Bittiefe oder lese ich hier am falschen Ort?

Das ist die Genauigkeit mit der die vorhandenen Daten zur Berechnung herangezogen werden.

Das bedeutet nicht, dass da in der Tabelle auch die werte bis auf die letzte Stelle genau drinstehen.

Bei binären Daten ist das ja simpel, da wird einfach nach der entsprechenden Stelle gekappt oder hinten mit Nullen aufgefüllt:
8bittiges 127: 01111111
das gleiche (also 8bit genau unterhalb der Mitte in 16bittig: 0111111100000000
umgekehrt, ein 16-bittiger Wert: 0111111111111111 -> 01111111|11111111 -> 01111111

Vielen Dank Thomas für die Antwort.

D.h. letzlich kann man den Vorteil so zusammenfassen:

Das Problem an 8 Bit ist, dass es keine Mitte gibt. Diese bekommt man zwar rechnerisch mit 12 oder noch mehr Bit auch nicht, man nähert sich ihr aber (aufgrund der im Verhältnis kleineren Sprünge) immer mehr an und erzielt dadurch genauere Ergebnisse. Wie eben bei dem 128/128/128er Beispiel.

Nur eins noch:

Gibts eigentlich eine Möglichkeit die Werte die in den LUTs stehen auszulesen. Im ColorSync-Dienstprogramm habe ich zumindest keine Möglichkeit gefunden.

Danke
LG fprince

Antwort auf [ fprince ]

Das Problem an 8 Bit ist, dass es keine Mitte gibt. Diese bekommt man zwar rechnerisch mit 12 oder noch mehr Bit auch nicht, man nähert sich ihr aber (aufgrund der im Verhältnis kleineren Sprünge) immer mehr an und erzielt dadurch genauere Ergebnisse. Wie eben bei dem 128/128/128er Beispiel.

Wenn man mit 13 Bit Werten rechnet, kann man das letzte Bit als Offset verwenden, sprich die 12 bit Werte um eins versetzen, dann hat man auch ne definierte Mitte. Photoshop macht das bei seinem 16bit Modus auch so, das sind faktisch 15 bit plus vorzeichen, mit einer definierten Mitte.

Antwort auf [ fprince ]

Gibts eigentlich eine Möglichkeit die Werte die in den LUTs stehen auszulesen. Im ColorSync-Dienstprogramm habe ich zumindest keine Möglichkeit gefunden.

In der Form, in der es in den Profilen drinstehet, nicht. Das ist geschwindigkeitoptimierter Maschinencode, aber es könnte durchaus tools geben, die das wieder in was menschenlesbares konvertieren. Mir ist nichts bekannt, ich würde bei Bruce Lindbloom anfangen zu suchen.

Hallo,

Zitat

Gibts eigentlich eine Möglichkeit die Werte die in den LUTs stehen auszulesen.

Probier das mal

Zitat

Wenn man mit 13 Bit Werten rechnet, kann man das letzte Bit als Offset verwenden, sprich die 12 bit Werte um eins versetzen, dann hat man auch ne definierte Mitte. Photoshop macht das bei seinem 16bit Modus auch so, das sind faktisch 15 bit plus vorzeichen, mit einer definierten Mitte.

das finde ich äußerst interessant, aber wird das von der cmm/profilen auch gemacht oder ist das nur Theorie?

lg fprince

Zitat

Probier das mal

vielen dank für den tipp. sieht vielversprechend aus.

lg fprince