Jetz’ hier ma’ keine Blasphemie! Ein Jünger dreht gerade durch, nicht daß der die Spanische Inquisiton auf den Plan ruft. 
-
In eigener Sache!
Liebe Mitglieder, liebe Besucher und Gäste
ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
Bitte hier weiterlesen ... -
DSLR-Forum Fotowettbewerb neu erfunden!
Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen. -
Neuer Partner: AkkuShop.de
Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
-
Neuer Gutscheincode unseres Partners Schutzfolien24:
DSLR-Forum2024
Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
Der Code ist für alle Geräteklassen gültig. -
Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs April 2024.
Thema: "Sprichwörtlich"
Nur noch bis zum 30.04.2024 23:59!
Jeder darf abstimmen!
Zur Abstimmung und Bewertung hier lang
WERBUNG
16-Bit-TIFF deutlich weniger Dynamik als RAW?
- Themenersteller Kai der
- Erstellt am
-
- Schlagworte
- dynamikumfang raw tiff
Allmählich frag ich mich, warum mit so wenig theoretischem Wissen so viele Antworten geschrieben werden. Ein kurzer Blick auf die Quelltexte aktueller freier Demosaicing-Algorithmen wie lmmse oder amaze genügt doch: Die untersuchen zunächst mittels des Helligkeitsmusters des Raw, ob Flächen oder Details einzufärben sind. Je näher die Struktur an der Nyquist-Grenze liegt, umso weniger Pixel werden zur Ermittlung der korrekten Farbe herangezogen.
Dieser Prozess (den kommerzielle Programme wohl analog ausführen) ist komplex und vor allem in Spitzlichtern und Schatten anfällig gegen Rundungsfehler. Eine Software wie LR, die intern wohl immer noch mit 16Bit arbeitet, kann deshalb durchaus falsche Ergebnisse liefern. Mein Tipp an den TO wäre deshalb, seine Beobachtung zunächst mit einem Proigramm mit zeitgemässer Rechengenauigkeit zu verifizieren. Dann können wir weiter sehen.
Dieser Prozess (den kommerzielle Programme wohl analog ausführen) ist komplex und vor allem in Spitzlichtern und Schatten anfällig gegen Rundungsfehler. Eine Software wie LR, die intern wohl immer noch mit 16Bit arbeitet, kann deshalb durchaus falsche Ergebnisse liefern. Mein Tipp an den TO wäre deshalb, seine Beobachtung zunächst mit einem Proigramm mit zeitgemässer Rechengenauigkeit zu verifizieren. Dann können wir weiter sehen.
Die 504 bit pro Pixel im Beispiel sind natürlich nur ein rein imaginärter Wert nach 01af der
verdeutlichen soll aus wieviel Information er zusammengesetzt wurde. Im Ergebniss wird die
Bittife eines einzelnen Raws nicht überschritten. Einige Prozesse laufen laut Die Lightroom-
Meisterklasse: Mit gezielter Nachbearbeitung zu besseren Fotos auch bei 16-Bit-Bildern
intern in 32-bit ab.
Sobald Tonwertbereiche in der Bearbeitung gestreckt werden enthält das Ergebniss
sogar weiniger Tonwertstufen als das Original.
Um die 14-Bit Bittiefe zu erhöhen sind schon aus mindestens zwei Raws zusammengesetzte
(fließkommafähige) DNGs der HDRs nötig. Bei HDRs kann Lr auch 32bit.
Das es bei der Analyse der Rawinformationen günstig ist die vollständigen
Informationen eines Viererblokes zu betrachten erscheint mir einfach logisch.
Das Situationsbedingt unterschiedlich viele Pixel herangezogen werden löst das
ganze. Danke für die Info.
Zuletzt bearbeitet:
Re: 16-bit-TIFF deutlich weniger Dynamik als Rohdaten?
Und auch wenn der Löwenanteil dieses Datenzuwachses für die Datei als ganzem aus Redundanzen besteht (weil, wie oben bereits lang und breit ausgeführt, benachbarte RGB-Pixel nicht gänzlich unabhängig voneinander sind), so ist es dennoch nicht richtig, daß der Gesamt-Informationsgehalt der ursprünglichen Rohdatei nicht überschritten werden könne. Denn der Akt der Bearbeitung fügt den Rohdaten eine Menge Informationen hinzu, die vorher nicht da waren. Wäre es anders, so bräuchten Rohdatenkonverter keine Regler
Was bitte soll daran "imaginär" sein?
Eben.
Selbstverständlich ist die Bittiefe eines einzelnen, per Bayer-Interpolation erzeugten RGB-Pixels weit höher als die eines Rohpixels. Deswegen belegt eine (unkomprimierte) 16-bit-TIFF-Datei wesentlich mehr Speicherplatz als die dazugehörige Rohdatei.
Und auch wenn der Löwenanteil dieses Datenzuwachses für die Datei als ganzem aus Redundanzen besteht (weil, wie oben bereits lang und breit ausgeführt, benachbarte RGB-Pixel nicht gänzlich unabhängig voneinander sind), so ist es dennoch nicht richtig, daß der Gesamt-Informationsgehalt der ursprünglichen Rohdatei nicht überschritten werden könne. Denn der Akt der Bearbeitung fügt den Rohdaten eine Menge Informationen hinzu, die vorher nicht da waren. Wäre es anders, so bräuchten Rohdatenkonverter keine Regler
Ist es aber nicht. Ebenso gut – nein, noch viel besser – kann man 25er-Blöcke betrachten ... oder 49er-Blöcke ... oder 121er-Blöcke ... oder adaptive, vom Bildinhalt abhängige Blockgrößen ... welche Blockgröße der Programmierer des jeweiligen Interpolations-Algorithmus' auch immer für sinnvoll hält.
It depends. Die "einfach auf 16bit aufgeblasene RAW Datei" ist exakt die Definition des so benannten "linearen TIFF". Da sind die RAW Daten auf 16bit umgerechnet und normalisiert.
Ist nur die Frage, welche Programme ein lineares TIFF unterstützen.
Du musst dem linearem Tiff nur das icc-Profil der betreffenden Kamera zuweisen und kannst es dann in jede Bildverarbeitung laden. Das Verfahren ist sehr aktuell, weil du solche Tiffs bei den Pixelshiftfähigen Pentax-Cams ohne Demosaicing direkt aus den vier gegeneinander verschobenen Raws erzeugen kannst. Schau dir die Ergebnisse aus der K1 an und du bist mit Bayer-Sensoren durch.
Und das bedeutet, dass es entwickelt wurde inkl. Demosaicing, Weißabgleich, Farbraumzuweisung usw.. Bloß die Tonwertkurve wäre dann eben linear, was aber eher ein Sonderfall ist.
Auch die Raw-Dateien selber sind solche TIFF-Container.
Eben und deshalb kann ein 16-Bit-Tiff auch genausogut die Informationsdichte eines
14-bit Bildes enthalten obwohl es als 16-bit deklariert ist. Selbst bei einem 16-bit Tiff
welches aus einem Jpeg in Tiff gewandelt wurde stehen 16 bit dran obwohl es nur 8 bit sind.
Um den Gesamt-Informationsgehalt eines Raws zu erhöhen muss nicht die Bitzahl
erhöht werden. Bei 14bit dürften die 4398046511104 mögliche Farben ausreichen
um Änderungen an den Reglern darzustellen. Immerhin bräuchte man ein 2x2 Mio
großes Bild um diese Farben alle darstellen zu können. Das Lr dabei intern schon
mit 16 bit und bei manchen Prozessen sogar mit 32 bit rechnet (auch bei 14 bit Raws)
um die möglichen 16384 Stufen pro Farbe eines Raws neu zu definieren hat nichts
mit der letztendlichen Bittiefe des exportierten Ergebnisses zu tun.
erhöht werden. Bei 14bit dürften die 4398046511104 mögliche Farben ausreichen
um Änderungen an den Reglern darzustellen. Immerhin bräuchte man ein 2x2 Mio
großes Bild um diese Farben alle darstellen zu können. Das Lr dabei intern schon
mit 16 bit und bei manchen Prozessen sogar mit 32 bit rechnet (auch bei 14 bit Raws)
um die möglichen 16384 Stufen pro Farbe eines Raws neu zu definieren hat nichts
mit der letztendlichen Bittiefe des exportierten Ergebnisses zu tun.
Zuletzt bearbeitet:
Wie bitte? Es ging hier ursprünglich mal um Dynamik. Egal, was an den Reglern gespielt wird, es kann die Dynamik in der TIFF-Datei nicht erhöhen (und das meine ich in diesem Zusammenhang mit "Informationsgehalt"), wohl aber verringern. Dass die Art der Bearbeitung ein paar Byte zusätzliche Information erzeugt, ist eine ganz andere Geschichte, hat aber mit der Dynamik und dem Informationsgehalt in Lichtern und Schatten gar nichts zu tun.
Das mit Dynamik nicht wirklich Dynamik gemeint war hatten wir doch schon.
Geschriebenes bezog sich auf 01afs Theorien. Hab vergessen zu zietieren.
Ansonsten widerspreche ich dir ja gar nicht.
"Im übrigen kann die Information und damit auch die effektive Bittiefe pro Pixel auch mit noch so
viel Rechnerei nicht größer werden als die ursprünglich erfasste Bittiefe von 14 pro Sensel."
Dem schließe ich mich damit nur an. Werte werden einfach nur ersetzt.
Zuletzt bearbeitet:
WERBUNG