16 bit TIF?

[Crischi74]

Werbung (verschwindet nach Registrierung)

Bei mir wars der Robotron KC 85 III, dann die Wende und C64, Amiga500, 1200, 4000, erst bei 486 DX ging’s zum  PC, später ne Gamer- Periode von Quake II bis Battlefield II, dann wurde der ganze Bastelkram uninteressant. 

 nur noch was, was einfach funktioniert und dabei hübsch ausschaut, also Mac.

bearbeitet 17. Dezember 2018 von Crischi74

[tabbycat]

vor einer Stunde schrieb Christian Frank:

...und konnte mit Marko schon sehr viel!

Ja, dieser Marko, der ist schon ein Tausendsassa...

Works hatte ich auch eine Weile verwendet, diese Dateien bekommt man heute nirgendwo mehr gescheit geöffnet. 

[Winkelsucher]

Am 15.12.2018 um 07:37 schrieb larshennings.de:

Was, bitte, passiert bei einer Expansion (in C1) von 50 MB-RAF zur TIF mit 150 MB – die Datei wird grösser, aber hat das qualitativ einen Sinn? Es werden doch offenbar allerlei Pixel hinzuerfunden. Nützt das für einen Grossdruck? Ist es sinnvoll als Archiv für spätere kleinere Dateien? Dank und Gruss, lars

Im Prozess macht es m.E. nur an einer Stelle Sinn. Wenn Du Entwicklung und Bildbearbeitung in zwei verschiedenen Programmen machen willst/musst (bzw. grundsätzlich wenn während des Prozesses zwei Programme verwendet werden müssen, die keine sonstigen, kompatiblen Formate haben).

Wenn Du z.B. mit dem LR RAW Entwickler nicht zufrieden bist und z.B. den Fujifilm Raw File Converter nutzen willst. Klar, der kann auch JPEG, aber das schränkt die Möglichkeiten bei der Weiteren Bearbeitung schon recht stark ein.

Druckvorstufe ist noch mal ein ganz anderes Thema....

[Gast]

Moin, die Frage ist, macht es Sinn dafür die 16 bit zu nehmen anstelle der 8 bit, die immer noch eine grössere Datei als die RAF produziert, 77 MB? Gruss, lars

[MightyBo]

vor 11 Minuten schrieb larshennings.de:

Moin, die Frage ist, macht es Sinn dafür die 16 bit zu nehmen anstelle der 8 bit, die immer noch eine grössere Datei als die RAF produziert, 77 MB? Gruss, lars

Wenn man die Bilder noch bearbeiten will, macht 16 Bit durchaus Sinn. Bei 8 Bit hast du pro Grundfarbe nur 256 Werte zur Verfügung. Das kann dann bei der weiteren Verarbeitung zu Farbabrissen führen . Z.b. beim blauen Himmel mit Helligkeitsverlauf. 

Ich weiß jetzt nicht ob das schon erwähnt wurde. Beim erzeugen des Jpeg, dass nur 8 Bit hat, werden die 256 Farbwerte, um beim Beispiel des Himmelblau zu bleiben, genau nach den im Bild vorhanden Blauwerten, gezielt aus den möglichen Blauwerten (aus 12,14 oder 16 Bit) herausgesucht (Das ist jetzt etwas theoretisch, da der Himmel ja nicht reines blau ist). Deshalb sieht man bei jpeg trotz 8 bit und nur 256 Blautönen keinen Farbabriss. Wenn man aber nun hergeht und beim jpeg durch Bearbeitung eine Farbverschiebung beim Blau durchführt, gibt es Farbabrisse, weil die nun neuen Blautöne kaum, bzw. gar nicht im 8bit Jpeg vorhanden sind (im 16 bit Tiff schon). Deshalb wenn 8 bit erzeugt wurde, keine oder möglichst wenig Bearbeitung.

Peter

[Gast]

OK, es ist ähnlich, wie wir es bei der Dehnung zur Perspektivenkorrektur besprachen. Erst mal mehr Pixel machen, um dann zu prüfen, was damit geht. Hier erzeuge ich also aus einem Drittel "echten" Pixelwerten der RAF von 50 MB daraus 150 MB (16 bit) in besserer Weise als dies wahrscheinlich wäre, wenn ich zuerst nur 77 MB (8 bit) erzeuge, um womöglich später die genannten Einschränkungen zu haben (Abriss...). Ja, man muss sich – wohl weil RAW-Konverter, Schärfung usw. eigene Zusammenhänge in einem grossen Zusammenhang bilden – von der Pixelzählung lösen... Und offenbar ebenso von einem Bezug auf die analoge Fotografie; s. o. Gruss, lars

[MightyBo]

Werbung (verschwindet nach Registrierung)

Oder zusammengefasst: Bei der hochwertigen Bildverarbeitung sollte man mit Speicher (HDD und RAM) nicht geizen.

Peter

[Crischi74]

vor 1 Stunde schrieb MightyBo:

Oder zusammengefasst: Bei der hochwertigen Bildverarbeitung sollte man mit Speicher (HDD und RAM) nicht geizen.

Peter

Es reicht oft, einfach mal aufzuräumen.

[mjh]

vor 6 Stunden schrieb larshennings.de:

Moin, die Frage ist, macht es Sinn dafür die 16 bit zu nehmen anstelle der 8 bit, die immer noch eine grössere Datei als die RAF produziert, 77 MB? Gruss, lars

Nur weil eine Datei größer ist, muss sie ja nicht mehr echte Bildinformationen enthalten. Bei 8 Bit pro Kanal sind von den ursprünglich 14 Bit bereits 6 Bit verloren gegangen, und die zusätzlichen 16 Bit für die beiden anderen Farbkanäle sind interpoliert, enthalten also keine zusätzlichen Informationen. Das Bit ist zwar die Einheit der Information und technisch gesehen enthält jede 77-MB-Datei dieselbe Menge an Information, nämlich 77 MB, aber uns geht es ja ganz konkret um Informationen über das Bild, das der Sensor aufgefangen hat. Aus dieser Perspektive ist ein großer Teil der Bits eines JPEG oder TIFF redundant – zwar nötig, um ein ansehbares Bild zu produzieren, aber kein echter Informationsgewinn gegenüber den Rohdaten.

Der Punkt ist: Die Rohdaten enthalten die Informationen, auf die es uns ankommt, in ihrer kompaktesten Form, aber an irgendeinem Punkt müssen wir aus den Rohdaten eine RGB-Bilddatei entwickeln, die wir betrachten und/oder weiter bearbeiten können, und diese Datei wird mehr Platz benötigen. Je mehr wir dann noch eingreifen wollen, desto wichtiger wird eine große Farbtiefe, denn ein 8-Bit-RGB-Bild ist schon ziemlich auf Kante genäht und seine Bearbeitungsmöglichkeiten sind beschränkt. Zumindest sollte man es auf 16 Bit erweitern, nachdem man es in einem Bildbearbeitungsprogramm geöffnet hat, aber das ist kein Ersatz für originale 16 Bit.

[Gast]

Ja, ich danke euch, wenn ich mal TIF brauche kann´s gern 150 MB sein; eine Datei incl. RAF zu speichern macht in Aff.-Ph. 350 MB. Aber im Verständnis muss ich umdenken und weg von der oben versuchten Beziehung zum analogen Bild. Gruss, lars

[Gast]

Um es auf 2-3 einfache Formeln zu bringen:

RA(W/F)= digitalisierte Darstellung der Meßwerte zu jedem einzelnen Sensorpixel

RAW * "Bearbeitungsrezept" des Konverters * "Gewürz" (Presets und/oder benutzerseitige Einstellungen)  -> fertiges Bitmap-Bild, das dann "verlustfrei" in z.B. BMP, TIF, PSD etc. gespeichert werden kann.

Bitmap * perzeptives Datenreduktionsverfahren -> JPG etc.

Also man kann insofern nicht sagen, daß in einem TIF zwingend maximal gleich viel oder gar weniger Information vorhanden ist als in einem RAW, sindern es kann sogar mehr Information drin sein, aber diese Informationstammt dann eben nicht aus dem Bild selbst, sondern aus dem "Bearbeitungsrezept" und den Presets/Einstellungen sowie evtl. vorgenommenen Retuschen und weiteren Bearbeitungsschritten.

Insofern könnte man also (und so machen es ja beispielsweise Lightroom oder auch C1 mit ihren Katalogen). anstelle eines TIF auch äquivalent jeweils ein RAW und ein exaktes Protokoll der Bearbeitungsschritte, der Presets und zum "Entwicklungsprozeß" abspeichern,und wenn letzterer ebenfalls  exakt definiert ist, kann daraus jederzeit das TIF oder auch JPEG bei Bedarf neu erzeugt werden.

Wobei dann die Speicherung von RAW+"Protokoll" üblicherweise deutlich "kompakter" ist als die des TIF, und trotzdem in der Hinsicht flexibler, daß man ja jederzeit mit anderen Einstellungen oder beispielsweise auch einem besseren "Entwickler"-Algorithmus (sprich Update des RAW-Konverters oder auch ein ganz anderer) an dueselben unverfälschten RAW Daten drangehen kann.

 

[Crischi74]

Beim Demosaicing vom Sensor-RAW zum farbigen Bitmap werden viele Daten errechnet. Hierbei entsteht erst das eigentliche Bild und auch ein Großteil was wir in der Bildqualität sehen (Farbtreue, Kantenschärfe, Rauschunterdrückung, Pixelfehler-Korrektur, Verzeichniskorrektur, CA-Korrektur usw.)

Dennoch gibt es einen Verlust, nämlich den Verlust der Rohdaten. Das Demosaicing und die Korrekturen zum Errechnen des Farb-Bitmap-Bildes müssen schon eine Qualität besitzen. Verschiedene RAW-Konverter haben hier unterschiedliche Stärken und Schwächen, und der Mensch hinter dem Monitor hat auch noch Einfluss auf viele Parameter.

Diese Konvertierung ist in der Regel irreversibel. 

Deshalb würde ich nicht von „Verlustfrei“ sprechen, wenn man aus dem RAW ein Bitmap (TIFF, BMP, PNG) in hoher Farbtiefe erzeugt.

[Hessebubb]

Das Kompressionsverfahren kann schon wichtig sein. Es wird nach Mustern gesucht. Wenn ein Muster mehrmals vorkommt wird versucht es nur einmal zu speichern und bei den Wiederholungen wird nur noch auf das schon vorhandene Muster verwiesen. Das spart Speicherplatz.

Wenn man zu stark komprimiert werden teilweise nicht gleiche Muster als gleich behandelt. Xerox Kopierer hatten teilweise eine Komprimierung die unter Anderem 6 und 8 als gleich behandelt hat. Obama's Lebenslauf, Fälschung oder Xerox-Kopierer....

Wenn man es kann sollte man sich etwas in die Komprimierung einlesen und versuchen zu verstehen was beim Verkleinern der Information passieren kann.

[Gast]

Eine die ursprüngliche Information erhaltende, also lediglich Redundanzen verschiedener Art eliminierende Kompression (ZIP usw.) ist eine Sache, Datenreduktion bzw. „perzeptive Kompression“ die andere.

Zu starke informationserhaltende („echte“) Kompression kann es, mal die grundsätzliche Brauchbarkeit des verwendeten Kompressionsalgorithmus vorausgesetzt,  gar nicht geben. Schlimmstenfalls steigt der Rechenaufwand um gegenüber einer sowieso schon guten Kompression noch ein paar Bytes rauszukitzeln (und das Ganze dann auch wieder auszupacken) so derb überproportional zum Ergebnis an, daß er sich „nicht mehr lohnt“, aber es geht auch da nichts „kaputt“ von den ursprünglichen Daten.

Bei der perzeptiven bzw. verlustbehafteten Kompression hingegen handelt man sich zwangsläufig Verluste (Artefakte) ein, mal mehr und mal weniger sicht- bzw. anderweitig spürbar.

Dann gibt es noch Mischformen, beispielsweise hat vor einiger Zeit jemand einen Archiver verzapft, der auch JPEG und MPEG Files nochmal teils deutlich „eindampfen“ kann ohne weiteren Quaitätsverlust. Der Trick besteht darin, die bei JPEG und MPEG NACH der Datenreduktion eingesetzten „herkömmlichen“ (und bisweilen auch nicht optimal implementierten) Kopressionsalgorithmen durch effizientere zu ersetzen. Beim Auspacken wird das wieder rückgängig gemacht, wobei durchaus eine zur der Ausgangsdatei unterschiedliche Datei entstehen kann, die aber im Viewer/Player exakt dasselbe Bild erzeugt. Für Backupzwecke und signierte Dateien eher grenzwertig, weil damit natürlich auch eine evtl. zu dem File erzeugte „Prüfsumme“ (CRC etc.) nicht mehr stimmt.

Und bei jeder Komprimierung (egal ob verlustbehaftet oder reversibel) gibt‘s noch das grundsätzliche Problem, daß keine (bzw. weniger) Redundanzen zwar eine kleinere, aber eben auch „empfiindlichere“ Datei bedeuten können. Eine unkomprimierte BMP etc.,  bei der ein paar Bytes „zerschossen“ sind und das nicht gerade den Header betrifft, hat schlimmstenfalls an der von diesen Bytes betroffenen Stellen ein paar „Flecken“, mit etwas Glück sogar an Stellen wo sich das relativ spurlos retuschieren läßt. Bei einem JPG oder auch einfach einer gezippten Datei (also der Archivdatei) hingegen reicht bisweilen ein einziges gekipptes Bit an der „richtigen“ Stelle aus, um massive Bildstörungen (extreme Farbverfälschungen, Rasterüberlagerungen etc.) auszulösen oder das File komplett unbrauchbar zu machen. Gegen letzteres können manche Archiver wiederum „Reparaturdaten“ erzeugen und in die komprimierten Files  einbauen, mit denen im Fall eines solchen Übertragungsfehlers Korrekturen vorgenommen werden können. Das wiederum „kostet“ aber Speicherplatz und läuft somit dem eigentlichen Ziel der Komprimierung zuwider...

bearbeitet 27. Dezember 2018 von Gast

[mjh]

vor einer Stunde schrieb Nichtraucher:

„echte“, lediglich Redundanzen eliminierende Kompression (ZIP usw.) ist eine Sache, Datenreduktion bzw. „perzeptive Kompression“ die andere.

Zu starke „echte“ Kompression kann es, mal die grundsätzliche Brauchbarkeit des verwendeten Kompressionsalgorithmus vorausgesetzt,  gar nicht geben. Schlimmstenfalls steigt der Rechenaufwand um gegenüber einer sowieso schon guten Kompression noch ein paar Bytes rauszukitzeln (und das Ganze dann auch wieder auszupacken) so derb überproportional zum Ergebnis an, daß er sich „nicht mehr lohnt“, aber es geht auch da nichts „kaputt“ von den ursprünglichen Daten.

Ich finde es nicht glücklich, hier ungebräuchliche Begriffe wie „echte Kompression“ einzuführen; das verwirrt nur. Man spricht allgemein von einer Dateikompression, wobei diese Kompression verlustfrei oder verlustbehaftet sein kann. Aus dem Ergebnis einer verlustfreien Kompression kann man die Originaldatei Bit für Bit exakt wiederherstellen, aus dem einer verlustbehafteten Kompression nicht – aber im besten Fall ist die dekomprimierte Version für unsere Augen oder Ohren (je nachdem, was für Daten komprimiert wurden) nicht vom Original zu unterscheiden. Im zweitbesten Fall würden wir zwar im direkten Vergleich einen Unterschied erkennen, aber so lange wir das Original nicht kennen, fällt es uns nicht auf, dass etwas fehlt.

[Gast]

yep, habe es an der Stelle korrigiert.

[Dein Support für das Forum]

Hat dir das Forum geholfen? So kannst du das Forum unterstützen!

Premium Mitglied werden | Spenden | Bei Amazon* oder eBay* kaufen
Software: Topaz* | DxO Nik Collection* | Skylum Luminar* (–10€ mit Gutschein FXF) | * Affiliate Links