Zitat: hcceds 28.09.15, 01:45Zum zitierten BeitragZitat: Hermann Klecker 27.09.15, 00:23Zum zitierten Beitrag
Das ist richtig und falsch. Dynamik und Farbtiefe haben zwar nichts miteinander zu tun, aber ein RAW mit Bittiefe 14 kann pro Pixel nur 2**14 unterschiedlich Farben auflösen. Ohne zusätzliche Information wird auch die Interpolation über das Bayer Pattern die Farbtiefe nicht über 14 Bit erhöhen. Es stehen also 2**(3*14) Farben zur Verfügung. Möglicherweise nutzt die Interpolation 16 Bit, aber das spiegelt Information vor, die im RAW nicht vorhanden ist.
Die 16 Bit waren ein Tipfehler von mir. Hätte 14 heißen müssen. Ist aber auch nicht sooo wichtig. Wichtig war mir die klare Trennung zwischen FarbTiefe und Dynamikumfang.
Das ist richtig und falsch. Dynamik und Farbtiefe haben zwar nichts miteinander zu tun, aber ein RAW mit Bittiefe 14 kann pro Pixel nur 2**14 unterschiedlich Farben auflösen. Ohne zusätzliche Information wird auch die Interpolation über das Bayer Pattern die Farbtiefe nicht über 14 Bit erhöhen. Es stehen also 2**(3*14) Farben zur Verfügung. Möglicherweise nutzt die Interpolation 16 Bit, aber das spiegelt Information vor, die im RAW nicht vorhanden ist.
Die 16 Bit waren ein Tipfehler von mir. Hätte 14 heißen müssen. Ist aber auch nicht sooo wichtig. Wichtig war mir die klare Trennung zwischen FarbTiefe und Dynamikumfang.
werden denn die einzelnen pixel im bild mit einem datenwort für farbtiefe und einem datenwort für helligkeit und einem datenwort für farbton gespeichert?
gibts da nicht bloss - vom dateiformat abhängig "r von 0 - 2^16" und "g von 0 - 2^16" und "b von 0 - 2^16"
oder graukanal von 0 - 2^16, "m von 0 - 2^16", "c von 0-16° etc?
wie wird helligkeit und wie wird farbton und wie wird farbtiefe in den gängigen, standardisierten dateien codiert, wenn man zwischen dynamik und farbtiefe denn unterscheiden kann???
kann schon sein, daß zwischen datei und ausgabegerät dann umcodiert wird, damit die fähigkeiten des ausgabegerätes optimal genutzt werden. der sechspatronen farbprinter wird den farbton aus dem rgb anders zusammenwursteln als der laserdrucker. und er wird zb. durch beigabe von schwarz farben abdunkeln. aber das ist ein komplett anderes bier als das, was in cams und raw-konvertern passiert.
gibts da nicht bloss - vom dateiformat abhängig "r von 0 - 2^16" und "g von 0 - 2^16" und "b von 0 - 2^16"
oder graukanal von 0 - 2^16, "m von 0 - 2^16", "c von 0-16° etc?
wie wird helligkeit und wie wird farbton und wie wird farbtiefe in den gängigen, standardisierten dateien codiert, wenn man zwischen dynamik und farbtiefe denn unterscheiden kann???
kann schon sein, daß zwischen datei und ausgabegerät dann umcodiert wird, damit die fähigkeiten des ausgabegerätes optimal genutzt werden. der sechspatronen farbprinter wird den farbton aus dem rgb anders zusammenwursteln als der laserdrucker. und er wird zb. durch beigabe von schwarz farben abdunkeln. aber das ist ein komplett anderes bier als das, was in cams und raw-konvertern passiert.
28.09.15, 14:55
Beitrag 108 von 122
Danke Nesco !
Du sprichst mir aus der Seele.
Ich kann dir voll und ganz folgen ;)
Du sprichst mir aus der Seele.
Ich kann dir voll und ganz folgen ;)
Zitat: N. Nescio 28.09.15, 12:41Zum zitierten Beitrag
Wenn ich das richtig sehe, dann hat das RAW pro Pixel nur Helligkeitsinformation (wie viel Licht ist auf das Pixel gefallen). Zusätzlich kennt die RAW Konvertierung (nicht der ADC) noch die Farbe des Bayernfilters der über dem Pixel lag (R,G oder B). Die Farbe wird erst bei der Konvertierung in ein "ausgabefähiges" Format (jpeg, TIF(F), ..), in-camera oder in-SW, aus dem Pixeln und seinen Nachbarn interpoliert. Erst hier wird auch der eingestellte Farbraum berücksichtigt.
Wenn ich das richtig sehe, dann hat das RAW pro Pixel nur Helligkeitsinformation (wie viel Licht ist auf das Pixel gefallen). Zusätzlich kennt die RAW Konvertierung (nicht der ADC) noch die Farbe des Bayernfilters der über dem Pixel lag (R,G oder B). Die Farbe wird erst bei der Konvertierung in ein "ausgabefähiges" Format (jpeg, TIF(F), ..), in-camera oder in-SW, aus dem Pixeln und seinen Nachbarn interpoliert. Erst hier wird auch der eingestellte Farbraum berücksichtigt.
Zitat: Hermann Klecker 28.09.15, 12:03Zum zitierten Beitrag Da hab ich wohl was richtig gestellt, was quasi schon richtig war:). Beim Pseudo-HDR bin ich übrigens nicht so puristisch wie mancher hier. Für mich ist das eine einfache Möglichkeit, den vollen Dynamikumfang des RAW in das Ausgabeformat zu "pressen". Hier wurden andere Möglichkeiten aufgezeigt, aber die kann ich nicht beurteilen.
Zitat: hcceds 28.09.15, 19:43Zum zitierten Beitrag
Ich hab auch nichts gegen Pseudo-HDR, nur nenne ich sie nicht HDR.
Und wenn das Bild dann sch.... ausschaut, dann kann man das auch irgendwie sagen, egal ob es ein HDR oder ein Pseudo-HDR ist.
Ich hab auch nichts gegen Pseudo-HDR, nur nenne ich sie nicht HDR.
Und wenn das Bild dann sch.... ausschaut, dann kann man das auch irgendwie sagen, egal ob es ein HDR oder ein Pseudo-HDR ist.
Zitat: N. Nescio 28.09.15, 12:41Zum zitierten Beitrag
In RAWs ist das, soweit ich sie kenne, nicht so.
In Lab werden die Daten so gespeichert.
In RAWs ist das, soweit ich sie kenne, nicht so.
In Lab werden die Daten so gespeichert.
Zitat: hcceds 28.09.15, 19:35Zum zitierten BeitragZitat: N. Nescio 28.09.15, 12:41Zum zitierten Beitrag
Wenn ich das richtig sehe, dann hat das RAW pro Pixel nur Helligkeitsinformation (wie viel Licht ist auf das Pixel gefallen). Zusätzlich kennt die RAW Konvertierung (nicht der ADC) noch die Farbe des Bayernfilters der über dem Pixel lag (R,G oder B). Die Farbe wird erst bei der Konvertierung in ein "ausgabefähiges" Format (jpeg, TIF(F), ..), in-camera oder in-SW, aus dem Pixeln und seinen Nachbarn interpoliert. Erst hier wird auch der eingestellte Farbraum berücksichtigt.
sehe ich exakt so.
lg gusti
Wenn ich das richtig sehe, dann hat das RAW pro Pixel nur Helligkeitsinformation (wie viel Licht ist auf das Pixel gefallen). Zusätzlich kennt die RAW Konvertierung (nicht der ADC) noch die Farbe des Bayernfilters der über dem Pixel lag (R,G oder B). Die Farbe wird erst bei der Konvertierung in ein "ausgabefähiges" Format (jpeg, TIF(F), ..), in-camera oder in-SW, aus dem Pixeln und seinen Nachbarn interpoliert. Erst hier wird auch der eingestellte Farbraum berücksichtigt.
sehe ich exakt so.
lg gusti
Zitat: hcceds 28.09.15, 19:43Zum zitierten Beitrag
genau darum ging es bei der wette um das abendessen.
genau darum ging es bei der wette um das abendessen.
Zitat: Hermann Klecker 28.09.15, 20:42Zum zitierten BeitragKeine Frage, das falsche Bit Mapping und das Bild ist ***eiße. Aber das sieht man hoffentlich:). Wie wär's mit "wir verrechnen wie bei HDR aber nennen es nicht ***" statt Pseudo-HDR:)
Zitat: hcceds 28.09.15, 22:26Zum zitierten BeitragZitat: Hermann Klecker 28.09.15, 20:42Zum zitierten BeitragKeine Frage, das falsche Bit Mapping und das Bild ist ***eiße. Aber das sieht man hoffentlich:). ...
Klar sieht man das. Aber die Opfer wollen es meist nciht glauben. Jedenfalls eine Foto-Saison lang nicht. :-)
Klar sieht man das. Aber die Opfer wollen es meist nciht glauben. Jedenfalls eine Foto-Saison lang nicht. :-)
30.09.15, 10:48
Beitrag 117 von 122
diese info möchte ich für alle, die es interessiert, dennoch nachliefern.
rawtherapee arbeitet bei der entwicklung mit floating point.
http://50.87.144.65/~rt/w/index.php?tit ... l_Features
rawtherapee arbeitet bei der entwicklung mit floating point.
http://50.87.144.65/~rt/w/index.php?tit ... l_Features
Zitat: Pandard 30.09.15, 10:48Zum zitierten Beitrag
Einen Link ohne ordentliche und vertrauenswürdige Domain werde ich jetzt nicht anklicken. Aber die Information überrascht mich nicht. Viele Grafik-Frameworks arbeiten mit Gleitkommazahlen. Warum auch nicht?
Grad bei der RAW-Entwicklung, bei der jeweils benachbarte Pixel mit gewissen Gewichtungen in die Interpolation des Endergebnisses mit einfließen müssen, ist float nicht direkt uncool.
Selbst meine kleine App macht da viel mit float und double.
Einen Link ohne ordentliche und vertrauenswürdige Domain werde ich jetzt nicht anklicken. Aber die Information überrascht mich nicht. Viele Grafik-Frameworks arbeiten mit Gleitkommazahlen. Warum auch nicht?
Grad bei der RAW-Entwicklung, bei der jeweils benachbarte Pixel mit gewissen Gewichtungen in die Interpolation des Endergebnisses mit einfließen müssen, ist float nicht direkt uncool.
Selbst meine kleine App macht da viel mit float und double.
30.09.15, 21:05
Beitrag 119 von 122
das überrascht mich nun auch nicht mehr.
(siehe beitrag nr. 99)
(siehe beitrag nr. 99)
Du warst doch ausgestieten?
Es ist übrigens ein deutlicher Unterschied, ob in einem Dateiformat wie RAW mit Fließkommazahlen gearbeitet wird, was meines Wissens nicht der Fall ist (Ich kann mich täuschen und lerne wirklich gern dazu) oder ob man in der Verarbeitung von Daten transient Gleitkommazahlen verwendet.
Nehmen wir wieder meine niedliche keine App als Beispiel, die Kleckrica 44 (bisher nur für Android). Die bekommt aus dem Fotoalbum oder der Kamera ganzzahlige Formate und sie speichert ganzzahlige Formate. Aber sie verwendet für Transformationen durchaus float und double.
Wenn Du damit ein Problem hast, dann laß es bitte nicht an mir aus.
Es ist übrigens ein deutlicher Unterschied, ob in einem Dateiformat wie RAW mit Fließkommazahlen gearbeitet wird, was meines Wissens nicht der Fall ist (Ich kann mich täuschen und lerne wirklich gern dazu) oder ob man in der Verarbeitung von Daten transient Gleitkommazahlen verwendet.
Nehmen wir wieder meine niedliche keine App als Beispiel, die Kleckrica 44 (bisher nur für Android). Die bekommt aus dem Fotoalbum oder der Kamera ganzzahlige Formate und sie speichert ganzzahlige Formate. Aber sie verwendet für Transformationen durchaus float und double.
Wenn Du damit ein Problem hast, dann laß es bitte nicht an mir aus.