Mathematische Funktionen direkt auf Raws anwenden?

[quit007]

Geht das auch schon mit CS2?

 

[DerDude]

da wir hier aber über bildbearbeitung reden und die pixelwerte nicht mathematisch auswerten um eine nuklearreaktor zu dimensionieren... halte ich das für komplette zeitverschwendung.

Ich habe den TO so verstanden, dass er seine eigenen Algorithmen implementieren will. Ich weiß nicht detailiert, welche Operationen er ausführen will (ist auch egal), aber er will sie hintereinander ausführen und die Verkettung dieser Operationen soll stabil sein.

 

[Hoogo]

Der Raw-Importer von Photoline ist ein DCRaw-Ableger, und irgendwo versteckt gibt es da auch die Möglichkeit, das RawBild "Roh" ohne Demosaicing als 16Bit-Bild zu öffnen. Evtl. kommt das dann aber schon in 3 Kanälen mit Weißabgleich, weiß ich jetzt nicht.

Da beim Aufblasen von 14Bit-Raw zu 16Bit Bild eh schon 2 Bit "Nachkommastelle" hinzukommen, sehe ich das mit dem Rundungsunterschied zwischen Fließkomme und Int nicht soo eng. Das würde ich mal an der konkreten Rechnung nachrechnen, ob da ein Fehler bis in die spannenden Bits reinläuft.

Bliebe aber noch die Frage, wie man am Ende der Kette das Demosaicing nachholt? Da hatte ich zwar mal eine Aktion in PL für hingezaubert, aber das war dann nur einfache lineare Interpolation. Such da mal in diesem Forum nach Motorola Pixl. DCRaw hat da bestimmt aber auch eine Lösung für, und sei es, daß man dieses Raw der Pixl (ein normales tiff) hinfälscht.

EDIT: Einschränkung mit 16Bit-Ebenen hatte Photoshop Elements, das normale Photoshop sollte das schon ziemlich lange ordentlich machen.

 

[Canon2010]

Ich habe den TO so verstanden, dass er seine eigenen Algorithmen implementieren will.

nee so verstehe ich ihn nicht:

Ich befürchte deshalb, dass wenn ich die erst in 8 bit entwickle und dann die Operationen drauf anwende, dass mir die Farben abreißen.
Die Funktionen die ich im Vorfeld nutzen muß sind hauptsächlich Addition und Division und vielleicht auch noch Subtraktion und Helligkeitsanpassung

Der Raw-Importer von Photoline ist ein DCRaw-Ableger, und irgendwo versteckt gibt es da auch die Möglichkeit, das RawBild "Roh" ohne Demosaicing als 16Bit-Bild zu öffnen.

was dann reine helligkeitwerte der jeweiligen ROT/GRÜN/BLAU sensoren sein dürften und keine farbinformationen.
daraus dann ein bessere RGB resultat zu basteln als ACR es vermag dürfte schwer werden.

und ich verstehe ihn so das es ihm um das beste endresultat geht.
man möge mich korrigieren wenn ich falsch liege!

 

[DerDude]

nee so verstehe ich ihn nicht:

Ich befürchte deshalb, dass wenn ich die erst in 8 bit entwickle und dann die Operationen drauf anwende, dass mir die Farben abreißen.
Die Funktionen die ich im Vorfeld nutzen muß sind hauptsächlich Addition und Division und vielleicht auch noch Subtraktion und Helligkeitsanpassung

Das sagt ja nichts, außer, dass ihm nicht klar war, überhaupt in 16bit entwickeln zu können. Aber er schrieb ja bereits an anderer Stelle, dass er seine Operationen bereits gerne vor der Interpolation durchführen will (über Sinn und Unsinn könnte man natürlich auch diskutieren).

Abgesehen von alldem: Das Eingangsbild in die Verarbeitungskette ist immer ein Integer-Array. Der Knackpunkt sind die Zwischenergebnisse. Ich würde nicht ausschließen, dass PS oder andere Tools intern mit Fließkomma arbeiten, weil das Ergebnis am Ende der Kette weniger Störungen aufweist. In der Tat ist das aber egal, weil man daran sowieso nicht drehen kann. Da muss man sich dann eben drauf verlassen, dass das Optimum rauskommt.

Wenn er aber selbst entwickeln will, ist eine Fließkommarepräsentation durchaus ein sinnvoller Ansatz.

Der TO wird sicher nochmal klar stellen, was ihm wichtig ist und ob er selbst Algorithmen entwickeln will.

 

[Canon2010]

soweit ich weiß arbeitet PS mit fließkomma, daher das problem der quantisierung im LAB modus.


such... kram.. stöber... ha hier:

Bei internen Farbtransformationen arbeitet Photoshop mit Fließkomma-
Arith metik, um eine hohe Genauigkeit sicherzustellen. Verwendet man Lab
jedoch als Modus für Bilder, sind wir mit einem Problem konfrontiert:
der Quantisierung durch die Integer-(Ganzzahl-)Arithmetik.
Lab ist riesig, Gerätefarbräume sind deutlich kleiner. Wandelt man ein
Bild bei einer Farbtiefe von 8 Bit/Kanal von einem anderen in den Modus
„Lab“ um, dann sind Tonwertverluste unvermeidlich, weil die Lab-
Werte so weit auseinanderliegen, dass sich etliche Ursprungsfarben einen
einzigen Lab-Wert teilen müssen.
Deshalb ist das Beherzigen einer elementaren Grundregel der digitalen
Bildbearbeitung nirgends so wichtig wie hier: zuerst in „Bild > Modus >
16-Bit-Kanal“ und dann in „Bild > Modus > Lab-Farbe“ konvertieren. Die
gesamte Lab-Bildbearbeitung erfolgt ausschließlich auf Basis der erhöhten
Farbtiefe. Lab ist nur zusammen mit 16 Bit/Kanal sinnvoll verwendbar.

 

[quit007]

Ich habe den TO so verstanden, dass er seine eigenen Algorithmen implementieren will. Ich weiß nicht detailiert, welche Operationen er ausführen will (ist auch egal), aber er will sie hintereinander ausführen und die Verkettung dieser Operationen soll stabil sein.

Genau
Z. B. möchte ich u. A. von mehreren Bildern einen Mittelwert bilden.
Ich habe vor allem dunkle Bereiche im Bild. Keine Ahnung wie groß so eine 21 MP Datei im 16 bit-Format ist. Aber ich bezweifle daß ich mit meinem Rechner effektiv mehr als 4 Bilder bearbeiten kann (vorausgesetzt CS2 unterstützt 16bit-Ebenen). Durch die dunklen Bereiche habe ich bereits wenige Tonwerte. Ich habe aber viele Bilder, in denen sich die Lichtverhäktnisse nur leicht ändern. Mal angenommen, dass wir das Rauschen vernachlässigen (was ein weiterer wichtiger Grund für mich für die Mittelung ist) kann ich ja aus vielen Bildern den "echten" "Floatingpoint-Tonwert" bestimmen. Wenn ich das gemacht habe will ich die Helligkeit um 1-3 Blendenstufen anheben.

(Es würde jetzt prinzipiell nichts dagegensprechen die Helligkeit erst anzuheben und dann zu mitteln. Aber ich habe ebenfalls einige wenige helle Bereiche auf den Bildern, in deren Umgebung die Mittelwertbildung versagen würde, da in dem Fall die Lichter unterschiedlich weit ausbrennen.)

Nehmen wir jetz mal einfach an, daß die 16 bit äquidistant zwischen 0 und 1 verteilt wären.
Der Farbtonabstand wäre dann 1/65535 = 1.5 e-5
Bei jeder Oeration kann schlimmstens das Flaoting ergebnis um die Hälfte
des Farbtonabstands daneben liegen sprich 0.75 e-5.
Bei 20 aufeinanderfolgenden Operationen ist es dann max. 3,05 e-4
Anheben um 3 Blendenstufen macht danm mal 8: 2.4 e-3
Das Ergebnis kann also schon um 162 Tonwertschritte vom wahren Wert abweichen. Oder andersherum ausgedrückt, es gäbe im wesentlichen dann nur noch 416 echte Tonwerte statt 65000.
Da die Tonwerte aber nicht äquidistant sind und im dunklen Bereich sowieso seltener vorkommen dürfte das Ergebnis vielleicht sogar schlimmer ausfallen.

Man könnte natürlich jetzt sagen, wir addieren alle Bilder zusammen und dann dividieren wir durch die Anzahl, aber die Fkt. habe ich bei PS nicht gefunden.
Für die Selbstprogrammierung beherrsche ich die Verwaltung des Arbeitsspeichers nicht hinreichend um so viele so große Dateien handhaben zu können. Daher müßte ich das, wenn ich es "zu Fuß" nacheinander mache in Floating point rechnen...

 

[JonSnow]

und du meinst ein HDR program oder ein program das viele unterschiedliche belichtungen fusioniert bringt dir nichts?

ich meine nur, wenn das irgendetwas bringen sollte was du vorhast... denkts du wirklich du bist der erste der darauf gekommen ist?

ich finde sowas ja auch immer probierenswert so als theoretischer versuchsballon.. aber 20 bilder so in die bearbeiten einbeziehen.. etwas viel aufstand oder?
und wie sieht es mit ghosting, abweichungen in den bildern aus?

 

[Hoogo]

soweit ich weiß arbeitet PS mit fließkomma, daher das problem der quantisierung im LAB modus.such... kram.. stöber... ha hier:

Nee, die meinen da was anderes. Während der Umrechnerei von RGB nach Lab und umgekehrt wird Fließkomma genutzt, aber das Ergebnis muß dann doch zum Ebenenmodus passen. Drum besser erst nach 16Bit und dann nach Lab wandeln, sonst sind die Rundungsfehler durch das Quantisieren zu 8Bit sehr stark.

Das 32Bit-Format von PS ist aber glaub ich ein kleines Fließkommaformat, ich weiß jetzt aber nicht, wie dessen Aufbau genau ist.

 

[thomaskeil]

mathematische Terme fast beliebiger Art auf ein 16-bit Bild anwenden geht mit der Kommandozeilenversion von G´MIC (http://gmic.sourceforge.net/gimp.shtml) (nicht die GIMP-plugin-Version, die ist wegen GIMP auf 8 bit beschränkt). Ob das spezifische raw-Format eingelesen wird kann ich allerdings nicht sagen, muss man ausprobieren.

Evtl.lohnt auch ein Blick auf mathmap http://www.complang.tuwien.ac.at/schani/mathmap/, macht auch die mathematischen Operationen auf Bilddaten, aber wieder der offene Punkt verarbeitbare Formate.

 

[quit007]

und du meinst ein HDR program oder ein program das viele unterschiedliche belichtungen fusioniert bringt dir nichts?

...

Es geht ja hier nicht um HDR. Ich habe zwar geschrieben, daß ich leichte Helligkeitsschwankungen habe, aber die sind für ein HDR viel zu klein.

 

[quit007]

@thomas:
vielen Dank, das könnte mir eventuell auch schon weiterhelfen.
Ich kann ja von Lightroom aus 16bit DNGs exportieren und die dann dort nacheinander einlesen. (Sodenn die Programme "DNG-Sprech" können)

 

[JonSnow]

mein vorschlag....
mach das was du vorhast doch mal mit 16 BIT ganz normal in photoshop.

dann zeig und die ~20 ursprungsbilder (als thumbnails) und das endresultat.

schätze das wirst du ja schon gemacht haben wenn du nach einer möglichkeit suchst das ergebnis zu verbessern.

damit man sich vorstellen kann was du überhaupt bezweckst.

 

[quit007]

Gemacht habe ich es noch nicht mit 20 Bildern.
Bisher habe ich mit 3-5 jpg Bildern gearbeitet und das im normalen 8bit Farbraum.
Seit kurzem habe ich halt deutlich mehr Bilder die ich zusammenfrickeln möchte-muß.
Und da wird es schon allein mit den ebenen knapp um Mittelwert zu machen.
Und es ist halt so, daß ich mich total auf die Raw-Entwicklung mit Lightroom eingeschossen habe. Wenn ich nicht muß nutze ich PS nicht. Mit verhältnismäßig wenigen Dateien habe ich das schon mit 8 bit in PS gemacht, die Ergebnisse waren ganz ok, aber das nachdem ich alle Bilder in LR entwickelt habe. Jetzt möchte ich halt das beste aus dem besten rausziehen und LR erst zum Schluß für Feinheiten nehmen.
Und bei 20 Bildern möchte ich einfach ein "simples" Programm: dividiere Wert von pixel 1 und pixel 2 mit 20 und summiere das Ergebnis. Addiere zum Ergebnis Wert von pixel/20 u.s.w. dass das auch als Batch funktioniert.
Irgendwo habe ich gelesen, dass astronomen solche Mittelwertoperation vor der Farbinterpolation machen. Warum habe ich entweder vergessen oder es stand nicht dabei

AUf jeden Fall möchte deshalb ein Ergebnis haben das wirklich genau ist.
Die andere Geschichte ist nämlich die, dass es nicht gerade sehr einfach wird mit PS. Um das BIld dann weiterzubearbeiten muß ich das System noch etliche weitere Ebenen aufblasen ...