Gelöschtes Mitglied 6223
Guest
... in der internen Datenaufbereitung. Wo liegen die Vor- oder auch Nachteile?
WERBUNG
RAW-Konverter: 16 Bit Integer oder 32 Bit Floating-Point
Keine Ahnung, was du mit Aufbereitung meinst.
Für die reine Speicherung machen 32bit Fließkomma wenig Sinn. Bei den Berechnungen sind die 32bit von Vorteil, weil es genauer ist. Je nach Hardware und Software dauert die Berechnung aber deutlich länger. Fällt besonders bei GPU beschleunigten Systemen ins Gewicht. Abgesehen davon, dass die bildverarbeitenden Bibliotheken dafür ausgelegt sein müssen.
Für die reine Speicherung machen 32bit Fließkomma wenig Sinn. Bei den Berechnungen sind die 32bit von Vorteil, weil es genauer ist. Je nach Hardware und Software dauert die Berechnung aber deutlich länger. Fällt besonders bei GPU beschleunigten Systemen ins Gewicht. Abgesehen davon, dass die bildverarbeitenden Bibliotheken dafür ausgelegt sein müssen.
Gast_380655
Guest
Sorry, was willst du? Ich nix verstehen! 
Gelöschtes Mitglied 6223
Guest
What's new in Raw Therapee 4
Wobei IMO RT inzwischen nicht mehr der einzige Konverter mit 32 Bit FP-Basis zu sein scheint. Die Frage ist halt, wo nun die Vor- oder auch Nachteile liegen?
- Floating point engine - RT is probably the only real time RAW converter doing image processing with high precision 32bit floating point (in contrast to 16bit integer like 3.0 and other)
Wobei IMO RT inzwischen nicht mehr der einzige Konverter mit 32 Bit FP-Basis zu sein scheint. Die Frage ist halt, wo nun die Vor- oder auch Nachteile liegen?
Gast_319607
Guest
Während Integer als Ganzzahlen ganz einfach definiert werden können (nämlich 0....2^Bit-1; bzw mit Vorzeichen dann halt von -2^(Bit-1) bis +2^(Bit-1)-1 - ist das ganze bei Fließkomma komplizierter - bzw es gibt da viele verschiedene mögliche Unterteilungen von 32 Bits in Basis und Mantisse. Wo auch immer du dann den Rundungsfehler machst... irgendwo ist er immer.
Ich kann aber mir irgendwie aber keinen Unterschied vorstellen, denn wenn man 14 native Bits (wie sie vom Sensor kommen), die dann in der Urform auf 32 Bit angepasst werden - dann gibt es nach Umwandlung viel mehr Zwischenwerte/Rundungsmöglichkeiten für Nachbearbeitung, das ist korrekt so. Warum da nun Fließkomma einen Vorteil bringen soll, erschließt sich mir nicht, aber vielleicht kann es mir ja auch jemand erklären...
Ich kann aber mir irgendwie aber keinen Unterschied vorstellen, denn wenn man 14 native Bits (wie sie vom Sensor kommen), die dann in der Urform auf 32 Bit angepasst werden - dann gibt es nach Umwandlung viel mehr Zwischenwerte/Rundungsmöglichkeiten für Nachbearbeitung, das ist korrekt so. Warum da nun Fließkomma einen Vorteil bringen soll, erschließt sich mir nicht, aber vielleicht kann es mir ja auch jemand erklären...
Gelöschtes Mitglied 6223
Guest
Thx, der Unterschied zwischen 16 Bit Integer und 32 Bit Floating-Point (also single precision) ist fraglos klar.
Spannend wird es halt, dass FP nun auch bei diversen RAW-Konvertern Einzug zu halten scheint. Bei HDR-Programmen schon lange nichts mehr neues.
Spannend wird es halt, dass FP nun auch bei diversen RAW-Konvertern Einzug zu halten scheint. Bei HDR-Programmen schon lange nichts mehr neues.
Die Seiten und Artikel von Elle Stone kennst Du wahrscheinlich schon ...
Gelöschtes Mitglied 6223
Guest
Thx für den Link. Den werde ich mir noch in aller Ruhe zu Gemüte führen. Aber an meiner ersten inneren Vermutung, dass via FP Spitzlichter besser händeln kann, scheint was dran zu sein. Mal schaun, was die Cracks dazu sagen ...
Darktable hat übrigens m.E. auch eine 32Bit-Engine. HDR-Formate haben 32 Bit. Wenn ein Konverter damit umgehen will, muss er dies Format verlustfrei bearbeiten. Da RT 32Bit(logluv)-Tiffs laden kann, war zu diesem Zweck ein entsprechendes Design der Engine nötig.
Elle Stone behauptet, Fliesskomma-Genauigkeit bringe weniger Artefakte bei der Bayer-Interpolation. Er beweist das anhand von AHD - einem Verfahren, dass ohnehin für seine Artefakte berüchtigt ist. Zudem verteidigt er damit ein eigenes Programm: Die 32Bit-Variante von dcraw. Das sind für mich noch keine validen Belege.
Seitens der RT-Entwickler wird angeführt, dass Integer-Genauigkeit bei komplexen Bearbeitungen zu Rundungsfehlern führen kann. Hierfür habe ich Indizien gefunden. Ich habe eine Reihe von extrem weichen SW-Negativen durch Abfotografieren digitalisiert. Der niedrige Tonwertumfang von ca. 2EV musste anschliessend auf das volle Spektrum aufgezogen werden, dazu kamen ein paar weitere Bearbeitungsschritte. C1 schaffte das nur mit sichtbaren Tonwertabrissen, während RT-Bilder deutlich sauberer aussahen. Das könnte eine Folge der Fliesskomma-Engine sein, ist aber auch eine extreme Anwendung.
Elle Stone behauptet, Fliesskomma-Genauigkeit bringe weniger Artefakte bei der Bayer-Interpolation. Er beweist das anhand von AHD - einem Verfahren, dass ohnehin für seine Artefakte berüchtigt ist. Zudem verteidigt er damit ein eigenes Programm: Die 32Bit-Variante von dcraw. Das sind für mich noch keine validen Belege.
Seitens der RT-Entwickler wird angeführt, dass Integer-Genauigkeit bei komplexen Bearbeitungen zu Rundungsfehlern führen kann. Hierfür habe ich Indizien gefunden. Ich habe eine Reihe von extrem weichen SW-Negativen durch Abfotografieren digitalisiert. Der niedrige Tonwertumfang von ca. 2EV musste anschliessend auf das volle Spektrum aufgezogen werden, dazu kamen ein paar weitere Bearbeitungsschritte. C1 schaffte das nur mit sichtbaren Tonwertabrissen, während RT-Bilder deutlich sauberer aussahen. Das könnte eine Folge der Fliesskomma-Engine sein, ist aber auch eine extreme Anwendung.
Was auch noch ein Vorteil von Fließkommaberechnung ist, das Verwenden von Farbräumen wird einfacher. Viele Algorithmen arbeiten mit einer Normierung der Werte von 0,0-1,0 um in LAB zu konvertieren. Viele Filter lassen sich nur dadurch sinnvoll implementieren und profitieren von der erhöhten Genauigkeit.
Gast_380655
Guest
Könnte mir vorstellen, dass es bei mehreren komplexen Bearbeitungsschritten, wenn die Zwischenergebnisse gehalten werden und erst beim Speichern wieder konvertiert wird, weniger Rundungsfehler geben kann. Ansonsten spricht alles gegen die Fliesskommadarstellung.
Das Zahlenformat der Datei ist integer und muss zum lesen/schreiben konvertiert werden, die CPU kann nur mit Integer vernünftig umgehen, für Fliesskomma gehts langsam oder muss dir GPU verwendet werden, für Eingabe-/Ausgabeoperationen Muss von/nach Integer konvertiert werden.
Schöne Grüße
Wolf
Das Zahlenformat der Datei ist integer und muss zum lesen/schreiben konvertiert werden, die CPU kann nur mit Integer vernünftig umgehen, für Fliesskomma gehts langsam oder muss dir GPU verwendet werden, für Eingabe-/Ausgabeoperationen Muss von/nach Integer konvertiert werden.
Schöne Grüße
Wolf
Gelöschtes Mitglied 6223
Guest
Klar, Input und Output sind normalerweise Integer. Während der Bearbeitung mit einer teils komplexen Abfolge von Arbeitsschritten, wie es z.B. bei HDR häufig geschieht, sollte FP logischerweise zu geringeren Rundungsfehlern bzw. zu einer höheren Genauigkeit führen. Fraglich somit, ob 16 Bit Integer allen Situationen gewachsen ist, wenn es um das letzte Quäntchen geht?
PS: Picturecode NoiseNinja arbeitet angeblich mit 32 Bit FP-Präzision und der hauseigene RAW-Konverter PhotoNinja, übrigens mein Favorit, möglicherweise auch.
PS: Picturecode NoiseNinja arbeitet angeblich mit 32 Bit FP-Präzision und der hauseigene RAW-Konverter PhotoNinja, übrigens mein Favorit, möglicherweise auch.
Zuletzt bearbeitet von einem Moderator:
Gelöschtes Mitglied 6223
Guest
Ok, soweit mal die Meinungen dazu. Spannend wäre jetzt die Frage, welcher Konverter nun klassisch mit 16 Bit Integer und welcher mit 32 Bit Floating-Point arbeitet?
Bitte einfach mal eine Aufzählung reinkippen ...
Bitte einfach mal eine Aufzählung reinkippen ...
Gelöschtes Mitglied 6223
Guest
Ok, RawTherapee hatten wir bereits, aber wie ich jetzt erstaunt feststellen musste mit einer 96 bits (floating point) processing engine!!!
Gast_175389
Guest
Komische Werte imho... Allgemein gilt auf x86: float 32bit, double float 64bit, long double 96bit. Die FPU rechnet intern aber mit max. 80bit. Für 96bit wären also imemr 2 Anläufe pro Zahl nötig (?)
Ich weiß nicht wer x87 long double auf x86-64 rechnet, aber das dürfte schon ziemlich lahm sein. x86_64 long double (SSE2 aufwärts?) ist 128bit und dürfte mehrfach schneller abgehen. An sich aber immer lahmer als integer.
Vielleicht erklärt das die gefühlten Unterschiede in der Lebendigkeit der GUIs zwischen Lightroom 3.6 und 5.x, beim Rumzerren an den Reglern?
Ich weiß nicht wer x87 long double auf x86-64 rechnet, aber das dürfte schon ziemlich lahm sein. x86_64 long double (SSE2 aufwärts?) ist 128bit und dürfte mehrfach schneller abgehen. An sich aber immer lahmer als integer.
Vielleicht erklärt das die gefühlten Unterschiede in der Lebendigkeit der GUIs zwischen Lightroom 3.6 und 5.x, beim Rumzerren an den Reglern?
Zuletzt bearbeitet:
Wäre schön mit Quelle.
Ansonsten ist das eine interessante Diskussion hier! Bei kaufmännischer Software ist die Rundungsfehlerproblematik lange bekannt und entsprechende FP-Algorithmen dürften allgemein vorgeschrieben und selbstverständlich sein. Seltsamerweise wird oft angenommen, dass die oft vielfach komplexeren internen Berechnungen der Bildverarbeitung womöglich mit 16Bit-Integer hinreichend abzubilden sind.
Gast_175389
Guest
Wann sollen die bei RawTherapee auf long double umgeschwenkt haben? Seite 13 von 109:
"RawTherapee 4 is probably the only real time raw converter which does all calculations in precise 32-bit floating point notation"
96bit wo, wie was?
Eigentlich haben wir 32bit integer und 64bit integer. Schon bisschen länger Vielleicht liegt es an den 12/14 bit der Raws? Und die 16bit (48bit) hinterher der gebräuchlichen Formate? Man weiß es nicht
p.s.
Ah ja, hier stehts, zu 4.0.
http://rawtherapee.com/blog/features
Im Handbuch steht auf genannter Seite, im Gegensatz zu 3.0 und integer16 rechnet 4.0 mit 32bit float. Sehr schön. PR-Bullshitbingo bei solchen Projekten finde ich massiv merkwürdiger als wenn es Adobe wäre. Irgendwie...
p.s.2:
Zu RawTherapee selbst. Hauptseite, 4.0, Win 64bit. Ist u.a. mit -mfpmath=sse und -msse2 kompiliert. Haut ja schonmal hin. Nix x87
Zum Programm selbst: Neulingen (aber nicht Raw-Neulingen) fällt gleich auf, daß es bei Defaults (Belichtung Auto) sehr hart Details aus den Tiefen holt. Und es dauert zuweilen Tage bis man lernt es auf ein DPP/Lr (z.B.) Niveau "runterzubringen".
Ich war mit der ersten 4.0 davon damals sehr angenervt und das hat sich mit 4.0.11.79 unter Win nicht geändert... Das ist schon ein fetter Fehler gewesen. Die Leute meinen das ist die Entwicklungsgrundquali des Programms. Denn andere Raw-Entwickler machen keine autobelichtung per Default. Echt übel.
"RawTherapee 4 is probably the only real time raw converter which does all calculations in precise 32-bit floating point notation"
96bit wo, wie was?
Eigentlich haben wir 32bit integer und 64bit integer. Schon bisschen länger
Vielleicht liegt es an den 12/14 bit der Raws? Und die 16bit (48bit) hinterher der gebräuchlichen Formate? Man weiß es nicht p.s.
Ah ja, hier stehts, zu 4.0.
http://rawtherapee.com/blog/features
Im Handbuch steht auf genannter Seite, im Gegensatz zu 3.0 und integer16 rechnet 4.0 mit 32bit float. Sehr schön. PR-Bullshitbingo bei solchen Projekten finde ich massiv merkwürdiger als wenn es Adobe wäre. Irgendwie...
p.s.2:
Zu RawTherapee selbst. Hauptseite, 4.0, Win 64bit. Ist u.a. mit -mfpmath=sse und -msse2 kompiliert. Haut ja schonmal hin. Nix x87
Zum Programm selbst: Neulingen (aber nicht Raw-Neulingen) fällt gleich auf, daß es bei Defaults (Belichtung Auto) sehr hart Details aus den Tiefen holt. Und es dauert zuweilen Tage bis man lernt es auf ein DPP/Lr (z.B.) Niveau "runterzubringen".
Ich war mit der ersten 4.0 davon damals sehr angenervt und das hat sich mit 4.0.11.79 unter Win nicht geändert... Das ist schon ein fetter Fehler gewesen. Die Leute meinen das ist die Entwicklungsgrundquali des Programms. Denn andere Raw-Entwickler machen keine autobelichtung per Default. Echt übel.
Zuletzt bearbeitet:
Die Verwendung von Fließkommazahlen gibt mehr als nur die Genauigkeit. Die Anzahl darstellbarer Zahlen ist natürlich auch begrenzt, wobei diese nicht gleich verteilt sind zwischen Minimal- und Maximalwert. Die höchste Dichte findet sich bei kleineren Werten und nach außen hin werden immer weniger Werte darstellbar, bzw. die Lücken zwischen ihnen größer.
Normalerweise arbeitet man wie oben erwähnt auf einem von 0 bis 1 normierten Bereich. Dabei bleiben dennoch für Algorithmen Reserven übrig den Bereich nach oben oder unten zu überschreiten, ohne gleich Information zu verlieren. In Darktable wird dies mWn auch so genutzt beim einen oder anderen Modul.
WERBUNG