SPP3: 16 vs. 8 Bit TIFF Bug?

Hallo zusammen!

Wenn ich mittels SPP3 meine Daten vom X3F-Format nach TIFF wandle,
erwarte ich bei 16-Bit TIFFs eigentlich den gesamten Dynamikumfang von
12-Bit Rohdaten dort abgebildet. Bei 8-Bit-TIFFs (wie auch bei JPEG)
verliere ich logischerweise an Dynamik.

Im dpreview-Forum geht das Gerücht, dass SPP3 bei 16-Bit TIFFs aber
nur 8-Bit Nutzdaten abspeichert. Mit einem Hex-Editor in die Daten
schauen bestätigt dies: keine 16-Bit-Darstellung. Lediglich der gleiche
8-Bit-Wert doppelt abgelegt.

Ein Vergleich (Differenzbild) von 8- und 16-Bit TIFF Version bestätigt
dies ebenfalls (PSP, "Image->Arithmetic->Difference").

Das wäre ja extrem unschön: Die 16-Bit-TIFFS brauchen bloss doppelt
soviel Platz. Kein Vorteil bei der Dynamik gegenüber 8-Bit. Und als
Archiv-Format auch nicht zu gebrauchen, wenn man nicht natives X3F
benutzen will...

Kann das jemand mit weiteren Tests bitte mal überprüfen? Danke!

Hier der Link zum Ursprungsposting bei dpreview:

http://forums.dpreview.com/forums/read.asp?forum=1027&message=24642145

Viele Grüsse aus Bielefeld,
Stefan

Hallo Stefan,

also ich seh's mal so.......

Obwohl ich ein absoluter RAW-Fan bin, ist es meiner Meinung nach doch so, dass die Bildinformation, die man auf einem Monitor, einem Bildausdruck oder einer Bildausbelichtung zeigen kann, schon in ein hochwertiges JPG-File passt! Ein X3F RAW enthält nun VIEL mehr Bildinfo, als Du in einem Bild unterbringen kannst. Das Tolle an unseren Foveon Rohdaten ist doch nun, dass wir uns genau den Teil der Bildinfo aussuchen dürfen, den wir später auf unserem Photo sehen möchten. Bei jeder Konvertierung in ein anderes Bildformat ist ein Großteil dieser Informationen futsch.

Insofern verstehe ich die Aufregung nicht so ganz??! Wenn Du Dir möglichst alle Optionen erhalten möchtest, dann bewahre Deine X3Fs am besten auf .... keine TIFFs! Versuche mal, bei einem TIFF später mal die Fill Light Funktion anzuwenden!! Das geht irgendwie nicht, oder?

Wenn Dir das X3F-Format nicht zukunftssicher genug ist, dann kannst Du die RAWs ja auch in das DNG-Format umrechnen ..... ADOBE bietet da einen kostenlosen Batchkonverter an. Die Daten lassen sich dann mit jedem beliebigen RAW-Konverter auswerten.

Grüße und schöne Photos

Klaus

bielefeld-33615 schrieb:

...Im dpreview-Forum geht das Gerücht, dass SPP3 bei 16-Bit TIFFs aber
nur 8-Bit Nutzdaten abspeichert. Mit einem Hex-Editor in die Daten
schauen bestätigt dies: keine 16-Bit-Darstellung. Lediglich der gleiche
8-Bit-Wert doppelt abgelegt. ...

Zum Vergrößern anklicken....

Hallo Stefan,

...Die spinnen bei DPREVIEW - da kann ich nur sagen RTFM.

Solange ich in SPP TIFF im sRGB-Mode oder Apple RGB-Mode speichere ist das klar (8Bit TIFF/ 24Bit Frabtiefe). In den Formaten kann man nicht in 16Bit TIFF (48Bit Farbtiefe) speichern (sRGB).

Speichere ich aber in ADOBE RGB, oder ColorMatch RGB wird definitiv als 16Bit Tiff (48Bit Farbtiefe) gespeichert.

Gruß,

RedFox.

Hallo und Danke für den Input!

Da ich's gern genau wissen wollte, habe ich heute ein und dieselbe X3F-Datei
mit SPP3 und SPP 2.1 in den unten aufgeführten Formaten abgespeichert
und anschliessend mal "Farben gezählt" (der Wert am Ende der Zeilen):

SPP 3:

8 Bit TIFF (ColorMatch): 193390
16 Bit TIFF (ColorMatch): 193390
8 Bit TIFF (AdobeRGB): 156665
16 Bit TIFF (AdobeRGB): 156665
8 Bit TIFF (sRGB): 181213
16 Bit TIFF (sRGB): 181213

SPP 2.1:

8 Bit TIFF (ColorMatch): 221119
16 Bit TIFF (ColorMatch): 221558
8 Bit TIFF (AdobeRGB): 179511
16 Bit TIFF (AdobeRGB): 179724
8 Bit TIFF (sRGB): 208553
16 Bit TIFF (sRGB): 208952


Was fällt auf?

SPP 3 speichert im Gegensatz zu SPP 2.1 bei 16 Bit TIFFs genausoviel
Informationen ab, wie bei 8 Bit. Ein direkter Vergleich mit einem Hex-Editor
zeigt, dass die jeweiligen Bytes bei 16 Bit lediglich redundant (gedoppelt)
gespeichert werden.
Es entsteht kein (!) Vorteil hinsichtlich des Informationsgehaltes
(bei zweifachem Speicherplatzverbrauch)!

SPP 2.1 speichert tatsächlich mehr Informationen in den 16 Bit Versionen
der TIFFs ab (im Vergleich zu den 8 Bit Formaten). Und zwar am meisten
im ColorMatch-Modus, danach folgt sRGB, dann AdobeRGB.

Für mich folgt daraus:

1. SPP 3 enthält genau den bereits auf dpreview vermuteten Bug im Bezug
auf die Speicherung von 16 Bit TIFFs.

2. SPP 2.1 legt bei 16 Bit TIFFs im ColorMatch-Modus den höchsten
Gehalt an Bildinformationen ab.

Fazit: Wenn ich bei der Nachbearbeitung von X3F das Format wechseln
will oder muss, und einen sauberen 16 bittigen Workflow beibehalten will
(um Konvertierverluste gering zu halten), ist SPP 2.1 für mich momentan
das Mittel der Wahl.

Viele Grüsse aus Bielefeld,
Stefan

Hallo Stefan,

folgendes zeigt mir z.B. PicturePublisher, wenn ich die Bilder (8Bit und 16Bit) öffne und in einen anderen Farbraum konvertieren will (Bild 1 8Bit TIFF Bild 2 16Bit Tiff zum konvertieren geladen, siehe Anhang).

Im Übrigen bin ich mal gespannt, was Dein HexEditor bei den Beiden Dateien auszählt :

http://www.computer-rely.de/sample/08B_IMG00036.tif

http://www.computer-rely.de/sample/16B_IMG00036.tif

und wenn Du die ausgezählt hast erklärst Du mir bitte weshalb das 2. TIFF-File doppelt so groß ist wie das Erste.

Gruß,

RedFox.

P.S. die Bilder sind mir halt gerade gelegen gekommen, da ich das x3f ohnehin löschen wollte , nicht bearbeitet, nur geladen und konvertiert.

Hallo Redfox!

Zum Verhalten von PicturePublisher kann ich keine Aussage treffen.

Bei den beiden Testdateien von Dir zähle ich jeweils gleich: 277976
(das Zählen mache ich übrigens nicht mit dem Hex-Editor, sondern
mit Paintshop, Menu: "Colors->Count Colors Used").

Ein Blick in das 16 Bit TIFF zeigt wieder, dass dort Bytes redundant
abgelegt sind, das erklärt auch die doppelte Grösse der Datei.

Mach Dir doch auch einmal die Mühe, z.B. ein Differenzbild Deiner
beiden Versionen zu bilden. Das Ergebnis wird "leer" sein, d.h. es
existieren keine Unterschiede in der Anzeige.

Viele Grüsse aus Bielefeld,
Stefan


Screenshot anbei: Dein mit Hex-Editor geöffnetes 16 Bit TIFF
und Zeiger auf beispielhafte Doppelung. Im Bild-Datenbereich
(nicht im Header und Abspann) sind alle Werte derart gedoppelt.

Ich komme mit dem Bildbetrachter XNView zum gleichen Ergebnis: ausser der Dateigröße kein Unterschied in RedFox' Bildern. Ich wittere Beschiss

Grüße Ingo

bielefeld-33615 schrieb:

...Ein Blick in das 16 Bit TIFF zeigt wieder, dass dort Bytes redundant abgelegt sind, das erklärt auch die doppelte Grösse der Datei.

Zum Vergrößern anklicken....

Hallo Stefan,

dann schau Dir mal die Bilddaten nach dem TIFF Header in beiden Dateien an. Bei mir sieht das anders aus :

Hallo Redfox!

Die Daten in Deinem 2. Screenshot sehen so aus,
weil beim 16 Bit File der Offset natürlich anders ist!

Das Byte n aus der 8 Bit Darstellung liegt bei n*2 im
16 Bit File. Da der Header hier beidesmal jeweils 8
Byte lang ist: bei: 8+(n*2) bei relativer, bzw.
8+((n-8)*2) bei absoluter Positionsangabe.

Nach Umrechnung liegt das Byte aus Deinem Beispiel
also in der 16 Bit Version an Position 0x0000238 bzw.
Dezimal 568.

Das Abspeichern von 16 Bit TIFFs mit SPP3 bringt also
keinerlei Vorteile was den Informationsgehalt angeht.

Die Vergeudung von Speicherplatz (doppelte Menge)
ist das Eine. Das Andere und viel ärgerlichere ist,
dass Anwender meinen könnten, mit dem Export als
16 Bit TIFF hätten sie die grösstmögliche Informations-
menge abgespeichert (z.B. als Archiv-Alternative zu
X3F)...

Viele Grüsse,
Stefan

sehr interessant dieser thread!

so ganz verstehe ich es aber nicht- wieso täuscht der konverter eine 16bit abspeicherung vor? was soll das für einen grund haben?

ist das ein trick um zeit zu schinden (beim verarbeiten?)

hat aber spp2 definitv 16bit abspeicherung? wäre ja noch ein grund spp3 außen vor zu lassen....

lg matthias

Wirklich interessanter Thread...
ich habe gerade die zwei Tiffs von RedFox runtergeladen und bei beiden die gleiche Tonwertkorrektur vorgenommen.
Die Tonwerte reißen beim 16 Bit genausoschnell ab wie beim 8 Bit ... von daher ist das 16 Bit Tiff wirklich eine Mogelpackung...

Ich kanns ja wie wohl die meisten Nutzer nicht direkt nachvollziehen.
Kann die 16 Bit-Funktion ein "Platzhalter" für zukünftige Firm- u. Softwareupdates sein?

Digitalios schrieb:

Ich kanns ja wie wohl die meisten Nutzer nicht direkt nachvollziehen.
Kann die 16 Bit-Funktion ein "Platzhalter" für zukünftige Firm- u. Softwareupdates sein?

Zum Vergrößern anklicken....

Ne, das ist einfach nur fehlerhaft programmiert. Wenn du dir den weiter oben von mir verlinkten XNViewer (Freeware) runterlädst, kannst du es auch selbst nachvollziehen.

Grüße Ingo

Hallo!

feuervogel69 schrieb:

so ganz verstehe ich es aber nicht- wieso täuscht der konverter eine 16bit abspeicherung vor? was soll das für einen grund haben?
ist das ein trick um zeit zu schinden (beim verarbeiten?)

Zum Vergrößern anklicken....

Es ist ein Bug, siehe Thread-Titel

feuervogel69 schrieb:

hat aber spp2 definitv 16bit abspeicherung?

Zum Vergrößern anklicken....

Ja, hat es. Blick in Files und optische Kontrolle belegen dies.

feuervogel69 schrieb:

wäre ja noch ein grund spp3 außen vor zu lassen....

Zum Vergrößern anklicken....

Wäre vor allem ein Grund für diejenigen, die sich mit SPP3s
16 bittigen TIFFs auf der sicheren Seite wähnten...

Ein weiteres Ergebnis meiner Farb-Pixel-Zählerei (siehe weiter oben)
ist ja: SPP3 liefert zugunsten der Entrauschung auch weniger Farb-
Informationen ab: Das eine bedingt wohl das andere...

Wer also einen 16-bittigen Workflow mit möglichst grossem Farbraum
haben will, kann auf SPP 2.1 (TIFF16, ColorMatch) derzeit nicht verzichten.

Viele Grüsse,
Stefan

bedeutet das im endeffekt, dass ich in photoshop keinerlei berechnungsvorteil bei 16bit habe und ich getrost bei 8 bit bleiben kann oder bringt 16 bit wärend den bearbeitungen immer vorteile?

danke für die antworten.

in der summe heißt das wiedermal, daß ich mit der sd10 und spp2 immer noch foveonmäßig fast state of the art bin ;-))))

gibt noch keinen grund ernsthaft aufzurüsten. gut, wenn man nicht unbedingt noch in PS rummurksen will, kann man ja die tonwertkorrekturen in spp machen, aber ausgegoren ist das nicht und schon gar kein fortschritt.

hoffen wir, daß aus irgendeinem grunde mal noch jemand ins foveon-boot mit hineinspringt, damit dieses an sich doch erstklassige konzept mal wieder technisch auf der höhe der zeit mitspielt. eine 8bit-verarbeitung macht ja wohl noch die letzten vorteile des systems kaputt...

lg matthias

Also jetzt wird doch mal wieder etwas übertrieben, oder?

Die Bildqualität, die sich mit SPP 3.0 im Vergleich mit SPP 2.1 erreichen lässt, ist schon um einiges besser. Wer von uns hätte das denn (wäre das Thema jetzt nicht explizit geworden) überhaupt bemerkt? Ein SPP 3.0 Update ist ja nun schon lange ankekündigt (eigentlich noch für dieses Jahr).

Bis dahin können doch nun diejenigen (wenigen), die meinen, sie seien auf 16 Bit TIFFs angewiesen auch den Umweg über DNG nutzen, um dann einen beliebigen, moderneren Konverter als SPP2.1 zu verwenden.....

SPP3.0 unterdrückt nun wirklich einige Foveon Probleme entschieden besser als SPP2.1. Luminanzrauschen und das extrem niederfrequente RGB-Rauschen (die Flecken) bei ISO 800 und ISO 1600 AL-Photos, fallen nun wirklich um "Etagen" gefälliger aus. Da würde ich mir aber überlegen, ob das alte SPP da günstiger ist??!

Grüße und schöne Photos

Klaus

klaus: natürlich hast du da recht, aber "unterdrückung" gleich welcher art ist immer mist ;-)

ich ging natürlich bei meinem obigen post davon aus, daß man (also in dem fall ich) mit der sigma so fotografiert, daß es da gar nix zu unterdrücken gibt, was dann wiederum in spp3 besser ginge.

iso 100+ stativ ist besser als jedes update. und genau bei dieser vorgehensweise (stativ) ist es dann ärgerlich, wenn die qualitätskette dann daran zerbricht, daß bei den tonwertkorrekturen die 8bitverarbeitung anfängt rumzumatschen. gerade die hervoragende farbtrennung der sigma-dateien (durch die exakten rgb-pixel. NICHT die schlechte farbtrennung des sensors an sich!!) z.b. macht mir dann in ps immer freude was das verstärkung oder abschwächen bestimmter farben angeht. für mich ein sigmapotential was in der landschaftsfotografie freude macht.

das ist mir dann im hinblick auf dei dp1 natürlich doppelt wichtig! eine dp1 ohne verfügbare 16bit verarbeitung in PS bracuhe ich nicht! denn die dp1 wird ja, wenn, eher eine landschaftskamera werden. himmelsverläufe, luftperspektive,grüne flächen mit kleinen details (wald,wiese etc.)
da bin ich der meinung, daß sich dieses potential nur mit einer 16bit verarbeitung erschließt, wenn man nicht nur ablichten will, sondern auch mal digitale duka-arbeit reinstecken möchte. da kann ich ja sonst gleich auf film fotografieren ;-)

lg matthias

Klaus-R schrieb:

Also jetzt wird doch mal wieder etwas übertrieben, oder?

Zum Vergrößern anklicken....

Ne finde nicht, dass übertrieben wird.
So ein Bug ist ein Witz. Jeder der Sigma Bilder ordentlich weiterverarbeiten will, wird sie in SPP entwickeln, dann als 16 Bit Tiff abspeichern und dann in Photoshop oder ähnlichen Programmen, weiterverarbeiten. Je nach Art der Bearbeitung ist man froh wenn einem die Tonwerte nicht so schnell abreißen, was aber genau der Fall ist bei 8 Bit (256 Grauwerte), im Vergleich zu 16 Bit (65536 Grauwerte).
Das empfinde ich als den schwerweigendsten Bug in SPP3.

OK... akzeptiere ich so .... auch wenn ich's wahrscheinlich so schnell nicht gemerkt hätte ....

Bleibt jetzt aber die Frage, ob das ein wirklicher BUG ist (wenn's denn so ist), oder ob man es sich hier zu "einfach" gemacht hat. Letzteres wäre dann in der Tat "Beschiss".

Tja .... bis ein Update verfügbar ist, wären diejenigen, die 16BIT TIFFs nutzen wollen, dann wohl auf Umwege z.B. über DNG oder SPP2.1 angewiesen.

Ich hab das ja schonmal geschrieben ..... SIGMA muss doch Geld an ARCSOFT bezahlt haben ..... da müssen die doch ein Recht auf Nachbesserung haben, bei sooo vielen Programmfehlern. Ist mir unbegreiflich sowas!

Grüße

Klaus