ZFX + Developia

Hi,

Hat schonmal jemand versucht, HDR-Bilder in PNGs zu speichern?
Der pCAL-Chunk bietet ja extra einen Gleichungstyp an, um Gleitkommawerte auf Integer-Werte abzubilden – ich blicke allerdings nicht ganz durch, wie man dabei die Parameter zu wählen hat und das Thema ist nirgendwo ausreichend diskutiert.

Gruß, Ky

Ich hab bisher DDS für alles abseits von ARGB32 benutzt. Dass PNG das unterstützen würde, ist mir neu.

DDS ist aber unkomprimiert und das verursacht – gerade mit Gleitkommadaten, die sich nicht einfach packen lassen – Platzprobleme …

PNG unterstützt auch keine direkten Gleitkommadaten, es unterstützt aber, die Kurve der Integer-Daten genau an die Kurve der Gleitkommadaten anzupassen. Ein 16-Bit-PNG soll so einen Wertebereich ähnlich dessen von 32-Bit-IEEE-Floats eine Abweichung von nicht mehr als 1/256 bieten können.

Die Sache ist nur, dass ich ein bisschen zu wenig mathematisches Verständnis habe, die Parameter für die Formel P0 + P1 * sinh(P2*(original_sample - P3)/(X1-X0)) richtig auszuwählen und dass man im Netz so gut wie nichts über diese Möglichkeit findet :(

Schon mal ein Programm ausprobiert das so eine Konversion durchführt? Könntest ja einfach die Formel herleiten wenn du vorher/nachher vergleichen kannst...

Vielleicht hilft dir das hier weiter, da steht ein bissel mehr über die Parameter:
http://www.libpng.org/pub/png/spec/regi ... 0-pdg.html

Wie man sich plötzlich für anderer Leute Probleme interessiert, wenn man eigentlich für eine prüfung lernen müsste :D...

Chromanoid hat geschrieben:Vielleicht hilft dir das hier weiter, da steht ein bissel mehr über die Parameter:
http://www.libpng.org/pub/png/spec/regi ... 0-pdg.html

Super, sogar mit Beispiel! :) Danke danke … ich hatte sicher ein Dutzend Paper gefunden, die aber alle nur aus meinem Link zitiert haben. Endlich mal was Handfestes!

Chromanoid hat geschrieben:Wie man sich plötzlich für anderer Leute Probleme interessiert, wenn man eigentlich für eine prüfung lernen müsste :D...

Und was für Fragen man plötzlich hier stellt, wenn man eigentlich für seine Klausuren lernen müsste.

Für HDR-Bilder sind OpenEXR-Files interessant. RGBE ist ebenfalls keine üble Idee.

OpenEXR-Bilder sind besonders wegen der Kompression (da wird ja von 2:1 trotz Film-Grain gesprochen) interessant. Das wäre dann aber ein weiteres Dateiformat, das ich extra implementieren müsste … :/

RGBE bietet – korrigier mich, wenn ich mich irre – nur 32-bpp-Präzision, unterstützt keinen Alpha-Kanal und ist unkomprimiert.

RGBE hat keinen Alphakanal, aber man kann RGBE problemlos in PNGs speichern, dann hat man zumindest eine verlustlose Kompression. Hinzu kommt, dass 32 bpp vs. 64/128 bpp doch um einiges kleiner sind. Ich würd RGBE empfehlen, wenn man intern bereits RGBE nimmt, ansonsten OpenEXR. Aber für die meisten Texturen sollte normales DXT/RGBA8 ausreichen.

dv hat geschrieben:[…] aber man kann RGBE problemlos in PNGs speichern, dann hat man zumindest eine verlustlose Kompression.

Wo ist das Runterrechnen von Gleitkommadaten zu RGBE (mit eventueller Aufgabe des Alpha-Kanals) verlustlos?

dv hat geschrieben:Hinzu kommt, dass 32 bpp vs. 64/128 bpp doch um einiges kleiner sind.

Doch nur, weil sie auch um einiges weniger genau sind.

Das Speichern von RGBE in PNG ist verlustlos. Was anderes habe ich ja auch nicht gesagt. Was die Genauigkeit von RGBE angeht; die Fehler gehen üblicherweise unter. RGBE macht hauptsächlich beim Blending Probleme.

dv hat geschrieben:Das Speichern von RGBE in PNG ist verlustlos. Was anderes habe ich ja auch nicht gesagt.

Nagut, aber auch das ist kein Vorteil – theoretisch könnte ich auch 16-Bit-Minifloats bitgleich in ein PNG schreiben und sie damit verlustfrei speichern (auch wenn sie schlecht komprimieren würden).

dv hat geschrieben:Was die Genauigkeit von RGBE angeht; die Fehler gehen üblicherweise unter.

Ich habe hier aber Daten, die auf jedem Kanal ziemlich unterschiedliche Daten enthalten, und das ist die große Schwäche von RGBE.


Ich habe hier mal eine HDR-Szene in ein logarithmisches PNG geschrieben … habe das Ergebnis nicht gegengetestet, aber es dürfte einen Eindruck vermitteln, wie solche Bilder aussehen – sehr grau nämlich: Ich habe extra die Atmosphäre abgeschaltet, um den Kontrast zu erhöhen (zwischen Himmel und Sonnenscheibe (dem kleinen weißen Punkt in der Mitte) sollte der Kontrast ungefähr 1:100 Billionen (oder 14 Dekaden) betragen). Wie man sieht, wird immernoch nur ein Bruchteil des 32-Bit-Gleitkommabereichs ausgenutzt (daher so trüb – nur ungefähr die Hälfte der möglichen positiven Werte des Bildes sind belegt).
Als Nächstes implementiere ich einen vernünftigen Dekoder, danach werde ich die Parameter so wählen, dass alle negativen Werte rausfliegen und dass ich die Obergrenze variabel angeben kann (um den Wertebereich optimal auszunutzen).


Edit: In der Spezifikation werden beispielhaft die Parameter

p0 = 0.0
p1 = 1.0e-30
p2 = 280.0
p3 = 32767.0

genannt, um 32-Bit-Floats zu speichern. Es ist allerdings nicht erklärt, wo diese Werte herkommen … daher:

p1 ist der zu Null nächste Wert, den man darstellen möchte.
p2 legt den Umfang auf Basis von p1 fest. Ist immer asinh(max ÷ min) – falls man sowohl positive als auch negative Werte kodieren möchte, muss man es verdoppeln (im Beispiel: 2 × asinh(1e30 ÷ 1e-30) ≈ 280).
p3 ist der Nullpunkt in den kodierten Werten (je nach Bittiefe 32767 oder 255, oder Null falls man nur positive Werte kodiert).

Schon daran gedacht, vielleicht mehrere Layers im PNG Bild zu nutzen?

Nein - was soll das bringen?

Krishty hat geschrieben:Nein - was soll das bringen?

naja - eher so als primitiver cheat - mit unterschiedlichen (also vorberechneten) Exposures in unterschiedlichen Layers, zwischen denen man dann interpolieren kann... waere zwar nicht mehr ein wirkliches HDR, aber sollte recht einfach zu implementieren sein.

Achso – neinein, ich brauche tatsächlich wissenschaftlich verwertbare Samples mit Dimension und einigermaßener Präzision, für Verwendung jenseits einfacher Bildbetrachtung oder HDR-Fotografie :) Afaik unterstützt PNG auch garnicht mehr als einen Layer pro Datei.