Forum Übersicht - RE: ACR und Kameraprofil Dynax 7D - 9

ZITAt (Dennis @ 11. 7. 2006 - 18.34 h) Die RGB-Daten entstehen durch die Farbinterpolation (Demosaicing) und haben mit einer Farbraumkonvertierung nichts zu tun.[/quote]
Herrschaftszeiten, wie bringt man das nur hinein in deinen Schädel!? Es gibt keine Punkte im Raum ohne Raum! Ist denn das so schwierig zu verstehen?


ZITAt (Dennis @ 11. 7. 2006 - 18.34 h) ZITATTatsächlich ist es aber nicht "der Kamerafarbraum" (so etwas gibt's gar nicht), sondern ein Farbraum, der sich aus den technischen Eigenschaften der Kamera plus dem gewählten Farbinterpolationsverfahren ergibt.[/quote]Natürlich gibt es einen Kamerafarbraum. Wie jedes Eingabegerät, hat auch ein Sensor einen geräteabhängigen Farbraum. Wie kommst Du auf die Idee, dass ausgerechnet eine Kamera keinen Farbraum hat?[/quote]
Endlich beginnst du, ansatzweise zu begreifen. Es ist schön, daß du endlich anerkennst, daß auch ohne explizites Herumrechnen mit ICC-Profilen Farbräume im Spiele sind. Dann sollte dir nun der Schritt nicht mehr schwerfallen zu verstehen, daß sich auch schon durch die Bayer-Farbinterpolation naturgemäß eine implizite Farbraum-Konvertierung ergibt. Oder na ja, vielleicht ist "Konvertierung" an dieser Stelle nicht ganz das richtige Wort ... man sollte vielleicht besser "Instantiierung" oder "Etablierung" sagen.

Und mit meiner Aussage, einen Kamerafarbraum gäbe es nicht, meinte ich natürlich, daß dieser nur in abstrakter Weise existiert. Es ist kein konkret faßbarer Farbraum, da die Rohdaten strenggenommen keine Farben sind. Man kann ihn nicht direkt fassen oder mit ICC-Profilen in den Griff bekommen. Erst wenn eine konkrete Rohdatenkonversion stattfindet, die den Rohdaten-Zahlenhaufen in ein RGB-Bild verwandelt, entfaltet sich auch der betreffende "Kamerafarbraum". Der aber ist nicht unabhängig vom eingesetzten Farbinterpolationsverfahren, sondern naturgemäß auf's innigste mit diesem verwoben -- daher bezeichnete ich den "eigentlichen" oder "reinen" Kamerafarbraum als nichtexistent.


ZITAt (Dennis @ 11. 7. 2006 - 18.34 h) Wie sollte man überhaupt ein Profil erstellen, wenn die Kamera keinen Farbraum hat?[/quote]
Gar nicht.

Man erstellt Kameraprofile nicht für Kameras, sondern immer nur für das Paar Kamera + Rohdatenkonverter.


ZITAt (Dennis @ 11. 7. 2006 - 18.34 h) Was soll den ein Pixel noch so alles an "Sachen" speichern? Das ist lustig, das musst du mal erklären.[/quote]
Weil weder die Farbfilter noch die Antiinterferenzfilter noch die Sensorelektronik perfekt sind, enthält ein Rohpixel Farbinformation für die eigene Farbe, Farbinformation für die anderen Farben, Luminanzinformation für die eigene Farbe, Luminanzinformation für die anderen Farben, systematische Fehler, stochastische Fehler ... und vermutlich noch ein paar andere Sachen, die mir grad nicht geläufig sind.


ZITAt (Dennis @ 11. 7. 2006 - 18.34 h) Nichts wird verschoben, es wird gespreizt Du beherrschst doch wohl die Multiplikation, oder?[/quote]
Ich schon ...


ZITAt (Dennis @ 11. 7. 2006 - 18.34 h) Aber doch nicht für die Werte, die schon da sind![/quote]
Na gut, vielleicht nicht bei den schlichteren Farbinterpolationsverfahren. Aber es gibt weit mehr Interpolationsalgorithmen als Konverter! Was glaubst du wohl, wo die unterschiedlichen Charakteristika der verschiedenen Rohdatenkonverter eigentlich herkommen!?


ZITAt (Dennis @ 11. 7. 2006 - 18.34 h) Was nutzen Dir ein 24bittiger R- und B-Wert, die auch noch abgeschätzt wurden, wenn der als Rechengrundlage dienende "echte" (ausgelesene) Wert nur in 12 bittiger Genauigkeit vorliegt?[/quote]
Der interpolierte Wert geht ja nicht aus einem 12-bit-Wert hervor. Und auch nicht aus zwei oder drei. Sondern aus Dutzenden, wenn nicht Hunderten von 12-bit-Werten -- also mehreren hundert Bit. Deshalb hat der interpolierte Wert mehr als 12 Bit (wieviele genau, das hängt vom Interpolationsalgorithmus ab). Allein der Durchschnitt zweier 12-bit-Werte hat ja bereits 13 bit -- und sogar noch mehr, wenn die zwei Werte unterschiedlich gewichtet in die Durchschnittsbildung eingehen.

Wieviele Bit davon signifikant sind, ist natürlich eine andere Frage. Aber es wäre dämlich, die mit großem Aufwand ermittelten Werte auf 12 Bit abzuschneiden, wenn ein 16-bit-Datenformat zur Verfügung steht.


ZITAt (Dennis @ 11. 7. 2006 - 18.35 h) Willst Du es nicht verstehen?[/quote]
Der einzige, der nicht verstehen will, bist offensichtlich du. Ich komme mir allmählich vor, wie wenn ich mit jemandem über höhere Algebra diskutierte, der nicht einmal einsehen will, daß zwei mal zwei vier ergibt.

-- Olaf

ZITAt (Dennis @ 11.07.2006 - 18:34) Nichts wir verschoben, es wird gespreizt Du beherrschst doch wohl die Multiplikation, oder? Ein 12bittiger Wert von 0 wird auf einen 16bittigen von 0 skaliert, und der 12 bittige Wert von 4.095 auf den 16bittigen Wert von 65.535. Dazwischen werden die anderen Werte verteilt. Das nennt sich Spreizung.[/quote]
Öhm, *hüstel*. Wenn Du zwei Intervalle (egal ob reell oder diskret) aufeinander abbilden willst, reicht eine Multiplikation nicht aus. Wenn ein 12Bit-Wort mit 16 multipliziert wird, dann geschieht in der Tat das, was Olaf beschrieben hat: Man erhält ein 16Bit-Wort, dessen vier niederwertigste Bit Null sind. Soll eine echte Skalierung erreichen werden, muss zuerst durch die Länge des Ausgangsintervalls dividiert werden, in diesem Fall 4095 (2^12-1). Edit: Länge des Intervalls korrigiert.

Lieber Olaf, lieber Dennis,
ist euch eigentlich klar, dass ihr inzwischen nahezu jedes interessante Thema mit eurer ewigen Nachtreterei kaputt macht?

@Dennis
du hast hier schon mal in einfachen, verständlichen Worten erklärt was Sache ist. Das hab sogar ich verstanden - wenigstens teilweise, Danke dafür. Was ich dagegen überhaupt nicht verstehe: warum läßt du dich immer wieder auf diese z. T. lächerlichen und korinthenkackerischen Verbalkriege ein?

Richtig, ich beginne ansatzweise zu begreifen, was Du meinst.

Da hast Du natürlich Recht: Die Rohdaten liegen nicht in einem ICC-konformen Farbraum vor. Das habe ich ja auch nie behauptet. Trotzdem wird von dem Sensor durch seinen Mosaikfilter ein Farbraum aufgespannt. Die Eckpunkte sind die Primärfarben des Sensors, und die Charakteristik ergibt sich durch die Eigenschaften des Sensors. Außerdem ist auch gar keine Interpolation zur Bestimmung eines "echten" Farbraumes mit RGB-Werten notwendig, da man bei einfarbigen Flächen in den Targets direkt die Werte der Einzelsensoren auslesen und kombinieren kann.

ZITATUnd mit meiner Aussage, einen Kamerafarbraum gäbe es nicht, meinte ich natürlich, daß dieser nur in abstrakter Weise existiert.[/quote]Ah, okay.

ZITATErst wenn eine konkrete Rohdatenkonversion stattfindet, die den Rohdaten-Zahlenhaufen in ein RGB-Bild verwandelt, entfaltet sich auch der betreffende "Kamerafarbraum". Der aber ist nicht unabhängig vom eingesetzten Farbinterpolationsverfahren, sondern naturgemäß auf's innigste mit diesem verwoben[/quote]Ja, das kann sein, insbesondere bei den üblichen Konvertern im grafischen Bereich. Es existieren aber auch Tools, wie dcraw oder ImagesPlus oder andere eher für astronomische Zwecke gedachte Programme, die die Sensordaten direkt ausgeben können - ohne Farbinterpolation etc.

ZITATMan erstellt Kameraprofile nicht für Kameras, sondern immer nur für das Paar Kamera + Rohdatenkonverter.[/quote]Damit hast Du Recht.

ZITATWeil weder die Farbfilter noch die Antiinterferenzfilter noch die Sensorelektronik perfekt sind, enthält ein Rohpixel Farbinformation für die eigene Farbe, Farbinformation für die anderen Farben, Luminanzinformation für die eigene Farbe, Luminanzinformation für die anderen Farben, systematische Fehler, stochastische Fehler ... und vermutlich noch ein paar andere Sachen, die mir grad nicht geläufig sind.[/quote]Da hast Du aber eine sehr eigenartige Definition von Pixel im Auge. Ich habe ausdrücklich von dem Wert gesprochen, den der A/D-Wandler ausgibt. Also ein quantisierter Wert zwischen 0 und 4.095. Und dort steckt keine weitere Information drin, sondern eben nur dieser Zahlenwert. Die von mir und Dir erwähnten "Sachen" stecken nicht im Pixel, sondern in der "Intelligenz" der Konvertersoftware. Sie stecken gewissermaßen im endgültigen RGB-Pixel des fertigen Bildes - aber davon sprach ich ja überhaupt nicht.

ZITATIch schon ...[/quote]Gut, dann sollte ja auch klar sein, dass 0 * 16 = 0 ist und 4.095 * 16 = 65.520 ist, und somit die 12bit-Werte durch Multiplikation mit 16 auf 16bit-Werte gespreizt werden.

ZITATNa gut, vielleicht nicht bei den schlichteren Farbinterpolationsverfahren.[/quote]Noch mal im Klartext: Du hast einen gegebenen Wert an einer Stelle, und willst zwei andere durch ein beliebiges Verfahren unter Einbeziehung beliebig vieler Nachbarwerte ermitteln. Warum in aller Welt solltest Du den einen gegebenen Wert auch nochmal verändern wollen? Das ist völlig absurd! Ich kenne bestimmt auch nicht alle Interpolationsverfahren, aber einige kann man sich ja auf diversen Seiten von Forschungseinrichtungen anschauen. Ich habe bisher nur unterschiedliche Ansätze gesehen - und zwar auch sehr "unschlichte" -, die der Ermittlung der fehlenden Farbinformationen dienen. Vielleicht kannst Du ja mal einen solchen Algorithmus nennen, der auch vorhandene Farbwerte verändert.

ZITATDeshalb hat der interpolierte Wert mehr als 12 Bit (wieviele genau, das hängt vom Interpolationsalgorithmus ab). Allein der Durchschnitt zweier 12-bit-Werte hat ja bereits 13 bit -- und sogar noch mehr, wenn die zwei Werte unterschiedlich gewichtet in die Durchschnittsbildung eingehen.[/quote]Ja, das habe ich ja nie bestritten. Nur ist dieser interpolierte Wert eine Schätzung. Warum sollte man von einem Schätzwert - in übertragenem Sinne - 24 Kommastellen verlangen, wenn die Stützwerte nur 12 Kommastellen haben? Oder andersrum: Es ist doch absurd von Qualitätsverlust zu sprechen, nur weil man geschätzte 24-stellige Werte, die auf gegebenen 12-stelligen beruhen, ebenfalls auf 12 Stellen kürzt.

ZITATWieviele Bit davon signifikant sind, ist natürlich eine andere Frage.[/quote]Eben. Und mehr, als man reinsteckt, kann man wohl nicht rausholen. Schließlich ist 5 ÷ 2 = 3 und nicht 2,5.

ZITATAber es wäre dämlich, die mit großem Aufwand ermittelten Werte auf 12 Bit abzuschneiden, wenn ein 16-bit-Datenformat zur Verfügung steht.[/quote]Es wäre nicht dämlich, aber man muss es natürlich ja auch nicht machen. Bloß ist das Deiner Aussage nach ja immer noch zu ungenau, wenn dan 24bittige oder noch längere Werte herauskommen.

ZITATIch komme mir allmählich vor, wie wenn ich mit jemandem über höhere Algebra diskutierte, der nicht einmal einsehen will, daß zwei mal zwei vier ergibt.[/quote]Ob zwei mal zwei vier ergibt, hängt definitv von der Algebra ab, und derer gibt es viele - auch welche, wo das nicht gilt. /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />

ZITAt (klick @ 13.07.2006 - 16:04) Was ich dagegen überhaupt nicht verstehe: warum läßt du dich immer wieder auf diese z. T. lächerlichen und korinthenkackerischen Verbalkriege ein?[/quote]Mit Olaf alleine würde ich das ja auch nicht machen, von mir aus kann er ja glauben, was er will. Nur hat es mich sehr gestört, dass er den guten Günter, der eigentlich vieles richtig verstanden hatte, so dermaßen runtergeputzt hat, als wäre er vollkommen dämlich und hätte überhaupt nichts verstanden. Immerhin hat Olaf seine Position ja später auch selber etwas zurückgenommen, aber auch einiges, was er vom Stapel ließ, war schlichtweg falsch (und fiel dann später gnädig still und leise unter den Tisch) oder fußte auf einer realitätsfremden Haarspalterei.

Aber Du hast natürlich Recht, drum beende ich das auch hier. Es sei denn Du oder jemand anderes (außer Olaf) hätten noch Fragen, aber dafür schlage ich einen neuen Thread vor.

ZITAt (Dennis @ 13.07.2006 - 16:30) Gut, dann sollte ja auch klar sein, dass 0 * 16 = 0 ist und 4.095 * 16 = 65.520 ist, und somit die 12bit-Werte durch Multiplikation mit 16 auf 16bit-Werte gespreizt werden.[/quote]
Wenn man mit (kleinen) Fehlern leben kann, kommt das in etwa hin. Aber der grösste Wert sollte dann ja 65535 sein.

ZITATOb zwei mal zwei vier ergibt, hängt definitv von der Algebra ab, und derer gibt es viele - auch welche, wo das nicht gilt. /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />[/quote]
Die Restklassenkörper hatten wir ja schon mal... ;-)

ZITAt (Dennis @ 13. 7. 2006 - 16.30 h) Da hast Du aber eine sehr eigenartige Definition von Pixel im Auge.[/quote]
Grad dieselbe wie du.


ZITAt (Dennis @ 13. 7. 2006 - 16.30 h) Ich habe ausdrücklich von dem Wert gesprochen, den der A/D-Wandler ausgibt. Also ein quantisierter Wert zwischen 0 und 4.095.[/quote]
Genau von diesem Wert spreche ich, wenn ich "Rohpixel" sage.


ZITAt (Dennis @ 13. 7. 2006 - 16.30 h) Und dort steckt keine weitere Information drin, sondern eben nur dieser Zahlenwert. Die von mir und Dir erwähnten "Sachen" stecken nicht im Pixel, sondern in der "Intelligenz" der Konvertersoftware.[/quote]
Das ist so verdreht, was du da redest ... dieser eine diskrete Skalar kommt als eine Überlagerung all jener Faktoren zustande, die ich oben nannte. Und die Intelligenz des Konverters bemüht sich, all diese Faktoren, die in einer einzigen Zahl zusammengemantscht wurden, hinterher wieder auseinanderzudröseln.


ZITAt (Dennis @ 13. 7. 2006 - 16.30 h) Sie stecken gewissermaßen im endgültigen RGB-Pixel des fertigen Bildes ...[/quote]
In diesem sind dann -- hoffentlich -- die Farben wieder sauber auseinanderdividiert und die Fehler so gut wie möglich eliminiert oder zumindest reduziert.


ZITAt (Dennis @ 13. 7. 2006 - 16.30 h) Gut, dann sollte ja auch klar sein, dass 0 * 16 = 0 ist und 4.095 * 16 = 65.520 ist, und somit die 12-bit-Werte durch Multiplikation mit 16 auf 16-bit-Werte gespreizt werden.[/quote]
Nochmal: das ist überhaupt nicht klar. Elementare Arithmetik ist offensichtlich nicht gerade deine starke Seite. Durch diese scheinbare "Spreizung" bleiben die 12-bit-Werte immer noch 12-bit-Werte. Auch wenn sie oberflächlich betrachtet wie 16-bit-Werte aussehen. Eine Spreizung durch Multiplikation ist in einer Ganzzahl- bzw. Festkomma-Arithmetik gar nicht möglich, so etwas gibt's nur für echt reelle Intervalle.

Übrigens, "thobos" Bemerkung zu diesem Punkt ist leider auch nicht richtig. Ob ich erst durch die Länge des Ausgangsintervalles dividiere und dann mit der Länge des Zielintervalles multipliziere, oder gleich mit dem Quotienten der beiden Intervallängen multipliziere, ist Jacke wie Hose.


ZITAt (Dennis @ 13. 7. 2006 - 16.30 h) Warum in aller Welt solltest Du den einen gegebenen Wert auch nochmal verändern wollen?[/quote]
Ich hatte es GERADE EBEN erklärt. Warum in aller Welt sollte ich annehmen, daß du es besser begreifst, wenn ich es noch einmal hinschreibe? Lies einfach noch einmal selber nach!


ZITAt (Dennis @ 13. 7. 2006 - 16.30 h) Nur ist dieser interpolierte Wert eine Schätzung. Warum sollte man von einem Schätzwert -- in übertragenem Sinne -- 24 Kommastellen verlangen, wenn die Stützwerte nur 12 Kommastellen haben?[/quote]
Die interpolierten sind zwar "Schätzungen" -- aber nicht so, wie du glaubst. Es geht weit mehr Information hinein als nur 12 bit ... wie ich bereits sagte. Daß eine Stützstelle "nur" 12 Bit hat, bedeutet noch lange nicht, daß in den interpolierten Werten alle Bits über das zwölfte hinaus insignifikant wären. Denn es gehen viele Stützstellen in die Berechnung eines interpolierten Wertes ein. Und selbst der Informationsgehalt des jeweils vorhandenen Farbwertes läßt sich erhöhen, so daß auch dieser im fertigen Bild mehr als 12 Bit haben kann.


ZITAt (Dennis @ 13. 7. 2006 - 16.30 h) Schließlich ist 5 ÷ 2 = 3 und nicht 2,5.[/quote]
Ja, klar ... /biggrin.gif" style="vertical-align:middle" emoid="" border="0" alt="biggrin.gif" />


ZITAt (Dennis @ 13. 7. 2006 - 16.43 h) Nur hat es mich sehr gestört, dass er den guten Günter, der eigentlich vieles richtig verstanden hatte, so dermaßen runtergeputzt hat, als wäre er vollkommen dämlich und hätte überhaupt nichts verstanden.[/quote]
Ooooo, der gute arme Günter ... hat der ein Glück, daß du dich mit deiner breiten Brust vor die Schwachen, Geknechteten und am Boden liegenden stellst! Gut, wir haben gelacht, jetzt komm wieder runter.

Günter ist weder dämlich noch hat er gar nichts verstanden. Und das weiß er selber am allerbesten. Er hat einiges verstanden, und einiges nicht. Und für ihn (und evtl. auch für andere, die mitlesen) ist es wenig hilfreich, wenn du falsche Dinge als richtig bestätigst, nur um nett zu sein. Und dann auch noch selber einen Haufen wirres Zeug hinzufügst.

-- Olaf

ZITAt (01af @ 13.07.2006 - 22:26) Übrigens, "thobos" Bemerkung zu diesem Punkt ist leider auch nicht richtig. Ob ich erst durch die Länge des Ausgangsintervalles dividiere und dann mit der Länge des Zielintervalles multipliziere, oder gleich mit dem Quotienten der beiden Intervallängen multipliziere, ist Jacke wie Hose.[/quote]
Nun, auf den ersten Blick ist (2^16)/(2^12)=2^(16-12)=2^4=16. Das ist aber nur die halbe Wahrheit... Dividiere mal mit 4095 und multipliziere mit 65535. Na?

ZITAt ("thobo @ 13. 7. 2006 - 23.26 h) Das ist aber nur die halbe Wahrheit ... Dividiere mal mit 4095 und multipliziere mit 65535. Na?[/quote]
Na und? Warum sollte ich durch 4.095 teilen, wenn das Ausgangsintervall eine Länge von 4.096 hat? Das wäre doch albern. Und warum sollte ich mit 65.535 multiplizieren, wenn das Zielintervall eine Länge von 65.536 hat? Das mußt du mir jetzt einmal erklären! /wacko.gif" style="vertical-align:middle" emoid="" border="0" alt="wacko.gif" />

-- Olaf

ZITAt (01af @ 14.07.2006 - 14:04) Na und? Warum sollte ich durch 4.095 teilen, wenn das Ausgangsintervall eine Länge von 4.096 hat? Das wäre doch albern. Und warum sollte ich mit 65.535 multiplizieren, wenn das Zielintervall eine Länge von 65.536 hat? Das mußt du mir jetzt einmal erklären![/quote]
Das Intervall hat eine Länge von 2^n-1.

ZITAT/wacko.gif" style="vertical-align:middle" emoid="" border="0" alt="wacko.gif" />[/quote]
Alles wird gut. ;-) Genau so wird's gemacht... Darum habe ich geschrieben, dass man mit der Methode von Dennis einen (kleinen) Fehler in Kauf nimmt.

ZITAt ("thobo @ 14. 7. 2006 - 14.16 h) Das Intervall hat eine Länge von (2^n)-1.[/quote]
(Ich habe oben einmal sicherheitshalber Klammern hinzugefügt in der Annahme, daß du es so gemeint hattest.)

Du meine Güte. Daß Leute nicht richtig lesen können, ist ja schon seit geraumer Zeit immer wieder ein Problem. Aber jetzt sind sie nicht einmal mehr fähig zu zählen ... /wacko.gif" style="vertical-align:middle" emoid="" border="0" alt="wacko.gif" />

Kleine Übungsaufgabe: Setze n = 3. Zähle, wieviele Elemente das Intervall [1 .. (2^n)-1] enthält. Dann zähle, wieviele Elemente das Intervall [0 .. (2^n)-1] enthält. Anschließend setze n = 12 und laß dabei dein Hirn eingeschaltet ... falls der Schritt von n = 3 auf n = 12 für dich zu viel auf einmal ist, dann versuch's von mir aus auch noch mit n = 4 und n = 5 ...

-- Olaf

ZITAt (01af @ 14.07.2006 - 14:28) (Ich habe oben einmal sicherheitshalber Klammern hinzugefügt in der Annahme, daß du es so gemeint hattest.)[/quote]
Es ist so gemeint. Nötig ist eine Klammersetzung trotzdem nicht - für Personen, die damit arbeiten.

ZITATDu meine Güte. Daß Leute nicht richtig lesen können, ist ja schon seit geraumer Zeit immer wieder ein Problem. Aber jetzt sind sie nicht einmal mehr fähig zu zählen ... /wacko.gif" style="vertical-align:middle" emoid="" border="0" alt="wacko.gif" />[/quote]
...

ZITATKleine Übungsaufgabe: Setze n = 3. Zähle, wieviele Elemente das Intervall [1 .. (2^n)-1] enthält. Dann zähle, wieviele Elemente das Intervall [0 .. (2^n)-1] enthält. Anschließend setze n = 12 und laß dabei dein Hirn eingeschaltet ... falls der Schritt von n = 3 auf n = 12 für dich zu viel auf einmal ist, dann versuch's von mir aus auch noch mit n = 4 und n = 5 ...[/quote]
Gähn. Wie wär's, wenn Du Dein Gehirn einschaltest? Natürlich hat das (diskrete) Intervall 2^n Elemente. Aber Dein Gehirn ist offensichtlich nicht in der Lage zu erfassen, weshalb die Länge des Intervalls hier 2^n-1 ist. Weisst Du, das ist wie mit dem Zaun und den Pfosten.

Abgesehen davon: Du sagst zu Dennis "Nein, so geht es nicht." Aber wie es geht, sagst Du nicht.

Edit: Tippfehler korrigiert.

ZITAt ("thobo @ 14. 7. 2006 - 14.47 h) Nötig ist eine Klammersetzung trotzdem nicht -- für Personen, die damit arbeiten.[/quote]
Natürlich nicht. Aber daß du eine Person seist, die "damit arbeitet", darauf wäre ich im Leben nicht gekommen.


ZITAt ("thobo @ 14. 7. 2006 - 14.47 h) Natürlich hat das (diskrete) Intervall 2^n Elemente.[/quote]
Na also. Dann rechne doch bitte nicht so einen Blödsinn zurecht.


ZITAt ("thobo @ 14. 7. 2006 - 14.47 h) Aber Dein Gehirn ist offensichtlich nicht in der Lage zu erfassen, weshalb die Länge des Intervalls hier 2^n-1 ist. Weisst Du, das ist wie mit dem Zaun und den Pfosten.[/quote]
Nein, dazu ist mein Hirn offenbar wirklich nicht in der Lage. Meinst du, du willst im Abbild mit Gewalt einen zusätzlichen (überflüssigen und störenden) Pfosten einschlagen, wo im Urbild schon keiner war? Und nimmst dafür eine Verzerrung der Abbildung des einen Intervalles auf das andere in Kauf, für die die verwendete Festkommaarithmetik gar nicht geeignet ist? Wozu um alles in der Welt!? Warum willst du falsch rechnen, wenn die korrekte Rechnung so viel einfacher ist?


ZITAt ("thobo @ 14. 7. 2006 - 14.47 h) Abgesehen davon: Du sagst zu Dennis "Nein, so geht es nicht." Aber wie es geht, sagst Du nicht.[/quote]
Wenn du jetzt noch verrätst, worauf genau sich jetzt diese Bemerkung bezieht, könnte ich evtl. dazu Stellung nehmen.

-- Olaf

ZITAt (01af @ 14.07.2006 - 15:26) Natürlich nicht. Aber daß du eine Person seist, die "damit arbeitet", darauf wäre ich im Leben nicht gekommen.[/quote]
S...r

ZITATNa also. Dann rechne doch bitte nicht so einen Blödsinn zurecht.[/quote]
Schwätzer.

ZITATNein, dazu ist mein Hirn offenbar wirklich nicht in der Lage. Meinst du, du willst im Abbild mit Gewalt einen zusätzlichen (überflüssigen und störenden) Pfosten einschlagen, wo im Urbild schon keiner war? Und nimmst dafür eine Verzerrung der Abbildung des einen Intervalles auf das andere in Kauf, für die die verwendete Festkommaarithmetik gar nicht geeignet ist? Wozu um alles in der Welt!?[/quote]
Du bist hochgradig verwirrt - es wird überhaupt nichts "verzerrt". Es geht ganz einfach um den Wertebereich.

ZITATWarum willst du falsch rechnen, wenn die korrekte Rechnung so viel einfacher ist?[/quote]
Dann sag' uns doch endlich, wie man das "richtig" rechnet.

ZITATWenn du jetzt noch verrätst, worauf genau sich jetzt diese Bemerkung bezieht, könnte ich evtl. dazu Stellung nehmen.[/quote]
Du sagst sinngemäss "mit 16 multiplizieren ist nicht". Das ist richtig. Wenn man's genau nimmt, muss man mit 4369/273 multiplizieren.

Hallo Leute,

also nachdem sich die anfänglichen Nebel gelichtet haben hat sich sozusagen ein hartnäckiger Bodennebel gebildet, den es noch aufzulösen gilt.

Irgendwie ist das Thema aber auch spannend geworden, passieren da doch eigentlich ständig Dinge, mit denen man sich normalerweise nie befasst.

Ich hab auch ein Buch zum Thema, (Tim Grey, Frabmanagement für Fotografen), den Tipp von Dennis mit den Gummibären gab's leider nicht mehr bei Ammazon.

Gleich in den Grundlagen wurde da (theoretisch) dargestellt, wie die Farben des Bildes in einem Gerätefarbraum erzeugt werden.

Ich weiss nicht sicher ob ichs richtig verstanden habe und würde mir gerne hier eine Korrektur oder Bestätigung holen.

Also etwas "hemdsärmlig", was hier nicht gerade angesagt ist:-) formuliert stelle ich mir den Vorgang, beispielsweise das Drucken eine Bildes, so vor.

Ich habe eine Bilddatei in (irgendeinem, für Haushaltsdrucker idealerweise sRGB) Arbeitsfrabraum vorliegen.

Lassen wir es theoretisch einen einfachen roten Punkt mit einem bestimmten Farbwert sein.

Wenn ich den zum Drucker sende sollte er idealerweise die Farbe so darstellen, wie ich sie am Bildschrim sehe.
Weil unterschiedliche Drucker aber mit ganz unterschiedlichen Farben arbeiten was die Anzahl der Farben und die Zusammensetzung der Tinte betrifft kann sich sicher jeder vorstellen, dass der Drucker mit dem übermittelten Farbwert des roten Punktes nichts anfangen kann.

Deshalb muss in dem Fall druckerseitig der Farbwert erst in einen allgemein gültigen Wert umgerechnet werden der sich am Lab Modell orientiert.
Auf das Lab Modell hat man sich als Standardmodell geeinigt, weil das dem menschlichen Farbwahrnehmungsempfinden am nächsten kommt.

Der Farbwert wird in einer Lab Tabelle beschrieben.

Erst danach kann der Drucker den Farbwert anhand der Lab Tabelle so in einen Wert umrechnen, den er dann nach seinen technischen Möglichkeiten, (Mischung seiner Primärfarben) darzustellen versuchen wird.

Wenn der Drucker dann auch noch weiss, auf welchem Papier er drucken soll, (Saugfähigkeit) ist man zumindest sehr gut darauf vorbereitet, dass der Drucker sein Best möglichstes tun wird, diesen Farbwert "richtig" darzustellen.
(Hoffentlich ist das nicht gerade ein Farbwert, den der Drucker nicht darstellen kann)

In solchen Fällen, (wenn das Profil des Ausgabegerätes bekannt ist) könnte man sich in PS mit der Farbwarnung vor dem Druck helfen, hier wird auf das Ausgabeprofil abgestimmt gewarnt, wenn Farben nicht darstellbar sind.

Der Vorgang, in ein Geräteunabhängigen Farbraum umzurechnen, (Lab) und dann auf das spezifische Geräteprofil zurück findet immer statt, wenn ein Gerät versucht, einen Farbwert darzustellen.

Soweit mein Verständnis bsiher,

(im zweiten Teil hab ich noch eine blöde Frage, die mich seit Gestern plagt)

Grüsse


Günter