Jump to content

RawTherapee Profile


Empfohlene Beiträge

Werbung (verschwindet nach Registrierung)

Die Gewinne von Floating Point sind nicht nur in Genauigkeit (dürfte man höchste beim „hochziehen“ von Schatten sehen), sondern im Wertebereich. Converter ziehen auch 12bit oder 14bit in 16bit auseinander, um bei den Zwischenberechnungen möglichst wenig Genauigkeit zu verlieren. Dadurch können sie aber meisten Highlights und Schatten <0 oder >2^16 nur abschneiden. Bei Floating Point bleiben die erhalten, so dass viele Benutzer berichten mit RT4 gibt’s mehr Details in Highlights als mit RT3/anderen herkömmlichen Konvertern.

Wie wäre es mit signed long int?

Link zum Beitrag
Auf anderen Seiten teilen

  • Antworten 67
  • Created
  • Letzte Antwort

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Hallo Harald,

 

Erst mal danke für die Leica-Profile, ich hab sie an unseren Profil-Spezialisten weitergeleitet.

 

Das mit dem "Profile applies Gamma" ist tatsächlich ein Bug in der Anzeige: die wird beim Anwählen nicht neu berechnet, von daher erscheint das (defekt aber korrekte) Bild erst später, bei der nächsten Aktion. Werde ich mir mal ansehen. Der Schalter wird nur sehr selten verwendet, da die üblichen Profile kein Gamma beinhalten.

 

Warum nicht signed long? Weil das auch 4 bytes wären. Kein RAM gewonnen.

 

Olli

Link zum Beitrag
Auf anderen Seiten teilen

Hallo Olli!

Erst mal danke für die Leica-Profile, ich hab sie an unseren Profil-Spezialisten weitergeleitet.

Gerne geschehen. Wie schon erwähnt, wenn ich noch welche liefern soll, bitte um Nachricht.

Ich werde auch noch welche für die Panasonic Lumix L10 anfertigen...

Das mit dem "Profile applies Gamma" ist tatsächlich ein Bug in der Anzeige: die wird beim Anwählen nicht neu berechnet, von daher erscheint das (defekt aber korrekte) Bild erst später, bei der nächsten Aktion. Werde ich mir mal ansehen.

Bitte, tu das, weil ansonsten sieht ja alles recht sauber aus.
Der Schalter wird nur sehr selten verwendet, da die üblichen Profile kein Gamma beinhalten.
Bei einem Kameraprofil ist eine Gammakurve auch nicht notwendig, aber du vergißt die "Quasigammakurve", die Linearisierungskurve, die in den Tags rTRC, gTRC und bTRC versteckt ist.

Da kann man recht elegant (zusammen mit der ColorLUT) Bereiche niedriger Zahlenauflösung kompensieren.

Warum nicht signed long? Weil das auch 4 bytes wären. Kein RAM gewonnen.

Integerarithmetrik ist schon um einiges flotter als float...

Und du must ja nicht alle 32 Bit abspeichern, 24 Bit tun es auch.

typedef struct {char rval[3],gval[3],bval[3]} RGB24,*PRGB24;

Bei float geht das natürlich nicht.

Link zum Beitrag
Auf anderen Seiten teilen

Werbung (verschwindet nach Registrierung)

Hallo Harald,

Bei den modernen Prozessoren ist float i.d.R. nicht viel langsamer als signed long int, da die aktuellen Prozessoren ohnehin alle FPUs an Bord haben. 24bit lohnt sich nicht, da die Prozessoren i.d.R. am schnellsten arbeiten, wenn sie an 32/16 etc. bitgrenzen gepadded sind. Von daher ist float schon eine gute Wahl, wenn man es genauer haben möchte.

Die Genauigkeit ist ohnehin mehr für Pixel-Peeper, die Farbmatrizen z.B. haben viel mehr Einfluss auf das Gesamtbild, deshalb auch der Wunsch nach Referenzbildern.

Hab mir den Berechnungs-Code von „Profile applies gamma“ mal angesehen (ist nicht von mir): die Bezeichnung ist wohl etwas irreführend, sie sollte wohl eher lauten „Apply gamma before profile“ ;-) Wenn der aktiviert ist, wird vor dem Füttern des CMS der Input-Wert mit einem Gamma überzogen.

Ich bin bei uns nicht der Profil-Spezialist, aber ich werde das mal adressieren. Wenn es so bleibt sollte es meiner Meinung nach zumindest umbenannt werden.

Olli

Link zum Beitrag
Auf anderen Seiten teilen

Hallo Olli!

Bei den modernen Prozessoren ist float i.d.R. nicht viel langsamer als signed long int, da die aktuellen Prozessoren ohnehin alle FPUs an Bord haben. 24bit lohnt sich nicht, da die Prozessoren i.d.R. am schnellsten arbeiten, wenn sie an 32/16 etc. bitgrenzen gepadded sind.

Ich denke, das ist theoretsich garnicht lösbar, da müßte man Benchmarks machen. Wahrscheinlich wird ohenhin vorher der Datenbus zugestopft, bevor noch die CPU schlapp macht.
Von daher ist float schon eine gute Wahl, wenn man es genauer haben möchte.
Eigentlich sitzen meine große Zweifel ja hier.

Dein Beispiel mit Erweiterung des Wertebereichs <0 und >Weiß überzeugen mich (noch?) nicht ganz.

Wo genau wird das zum Vorteil?

Beim Entmosaiken (Interpolation)?

Bei der Umwandlung in den Verbindungsfarbraum?

Die Genauigkeit ist ohnehin mehr für Pixel-Peeper,

Klar, die sehen ja auch Bruchteile von Pixel :-)
die Farbmatrizen z.B. haben viel mehr Einfluss auf das Gesamtbild, deshalb auch der Wunsch nach Referenzbildern.

Die "Farbmatrizen" (so wie ich das sehe) dienen lediglich zur Beseitigung der Farbnebendichten der Bayer-Filter bzw. wenn kein ICC-Profil verwendet wird, zur Überführung in den XYZ-Farbraum (und von dort in den Lab-Farbraum).

Sobald du aber ICC-Profile verwendest, hast du signed long int mit mehr als ausreichender Präzission.

Ach ja, und die Bradford Matrizen für die Umrechnung von D65 nach D50 hast du noch in float...aber spielen die bei der praktisch farbraumlosen Konvertierung der Sensordaten zum Verbindungsfarbraum überhaupt eine Rolle?

Hab mir den Berechnungs-Code von „Profile applies gamma“ mal angesehen (ist nicht von mir): die Bezeichnung ist wohl etwas irreführend, sie sollte wohl eher lauten „Apply gamma before profile“ ;-) Wenn der aktiviert ist, wird vor dem Füttern des CMS der Input-Wert mit einem Gamma überzogen.

Egal wie der Schalter heißt, er ist meiner Meinung nach fehl am Platz. Das (ICC-Kamera)Profil geht immer von linearen Werten aus. Von den Rohdaten bis zum Verbindungsfarbraum hat meiner Ansicht nach eine Delinearisierung nichts verloren.

Ist das vielleicht der Grund, warum Thorsten schrieb, man braucht ColorCheckeraufnahmen mit unterschiedlicher Belichtung?

 

Ich bin bei uns nicht der Profil-Spezialist, aber ich werde das mal adressieren. Wenn es so bleibt sollte es meiner Meinung nach zumindest umbenannt werden.

Siehe oben...

Link zum Beitrag
Auf anderen Seiten teilen

Hallo Harald

 

Egal wie der Schalter heißt, er ist meiner Meinung nach fehl am Platz.

meiner Meinung sollte es hier eine Auswahl geben, ob eine Gamma-Korrektur vor oder nach der CMS Transformation durchgeführt werden soll.

Fuer die von dir verwendeten Profile brauchst du eine nachträgliche Gamma-Korrektur.

Andere haben ueber ein Gamma-korrigiertes Bild profiliert und benötigen folglich die gleiche Gamma-Korrektur vor jeder CMS Transformation.

 

Von den Rohdaten bis zum Verbindungsfarbraum hat meiner Ansicht nach eine Delinearisierung nichts verloren.

die Profile von Thorsten wurden anhand der linearen Daten erzeugt und gegen die zur Farbtafel gehörenden Messwerte profiliert. Daher beinhaltet das so erzeugte Profil aber auch eine quasi-Delinearisierung ( d.h. nach der Transformation über dieses Profil, sollte keine Gamma-Korrektur mehr stattfinden )

Was daran jetzt besser sein soll, die in den Messwerten steckende Delinearisierung aus diesen herauszurechnen, nur damit man gegen solche pseudo-linearierten-"Messwerte" profilieren kann, verstehe ich nicht :confused:

 

 

Gruß

Günter

Link zum Beitrag
Auf anderen Seiten teilen

Hallo Günter!

meiner Meinung sollte es hier eine Auswahl geben, ob eine Gamma-Korrektur vor oder nach der CMS Transformation durchgeführt werden soll.

Genau das versuche ich ja zu widerlegen, weil es meiner Ansicht nach vor der Überführung in den Ausgangsfarbraum weder notwendig ist noch einen Vorteil bringen könnte.

Fuer die von dir verwendeten Profile brauchst du eine nachträgliche Gamma-Korrektur.

genau genommen auch nicht, weil die notwendige Gammakorrektur ja schon implizit in der Umwandlung Verbindungfarbraum (XYZ oder Lab) zum Ausgabefarbraum (sRGB oder welchem RGB auch immer) beinhaltet ist.

Nur als Beispiel, sRGB hat ein Gamma von (annähernd) 2.4, AdobeRGB ein Gamma von 2.2 (exakt 2.0 + 51.0 / 256.0).

Andere haben ueber ein Gamma-korrigiertes Bild profiliert

Ich sage es jetzt einmal ganz kühn: das ist dann einfach falsch.
und benötigen folglich die gleiche Gamma-Korrektur vor jeder CMS Transformation.

Wenn wirklich schon ein gammakorrigiertes Bild vermessen wurde, dann gehören die Meßwerte gammakorrigiert. Für das Farbprofil braucht man, da sich ja um ein Profil für ein lineares Inputdevice handelt, auch "lineare" Daten. Es besteht eine lineare Beziehung zwischen den Daten des Sensors und den eingefangenen Photonen.

Darum ist es unumgänglich eine kommerzielle Farbtafel zum Profilieren einer Kamera zu verwenden. Ich habe mich vergeblich bemüht, eine "Kopie" meines ColorCheckers per (manipulierten) Ausdruck zu erstellen. Ist mir nicht gelungen, hat immer in mindestens einem Farbfleck nicht gepaßt.

die Profile von Thorsten wurden anhand der linearen Daten erzeugt und gegen die zur Farbtafel gehörenden Messwerte profiliert. Daher beinhaltet das so erzeugte Profil aber auch eine quasi-Delinearisierung ( d.h. nach der Transformation über dieses Profil, sollte keine Gamma-Korrektur mehr stattfinden)

Wie gesagt, bei einem Profil für ein (lineares) Inputdevice sollte nie ein Gamma irgendwie mit dabei sein.

Was daran jetzt besser sein soll, die in den Messwerten steckende Delinearisierung aus diesen herauszurechnen, nur damit man gegen solche pseudo-linearierten-"Messwerte" profilieren kann, verstehe ich nicht :confused:

Ich glaube, jetzt schreiben wir aneinander vorbei.

Möglicherweise hat Thorsten (aus Unachtsamkeit oder warum auch immer) bei der Profilerstellung - wie hat er das überhaupt gemacht? - irgendwo ein Gamma eingegeben.

Ich lade dir am Abend mein readicc.exe hoch, dann kannst du dir beliebige ICC-Profile "anschauen" ob und welches Gamma du da findest.

Link zum Beitrag
Auf anderen Seiten teilen

Für das Farbprofil braucht man, da sich ja um ein Profil für ein lineares Inputdevice handelt, auch "lineare" Daten.

ich behaupte jetzt nicht, daß das sinnvoll ist, aber eine ( noch dazu bidirektionale ) Funktion über die "linearen" Daten drüberlaufen zu lassen, schränkt die Verwendbarkeit des Profils nur insofern ein, daß diese Funktion vor jeder Transformation mittels dieses Profils auch über die linearen Daten angewendet werden sollte.

In diesem Fall wird halt ein "virtuelles gamma-korrigiertes Inputdevice" profiliert, das in der praktischen Anwendung seine Nachteile haben mag, aber zum gleichen Ziel führt.

 

genau genommen auch nicht, weil die notwendige Gammakorrektur ja schon implizit in der Umwandlung Verbindungfarbraum (XYZ oder Lab) zum Ausgabefarbraum (sRGB oder welchem RGB auch immer) beinhaltet ist.

das ist ja auch der Grund warum mir Thorstens Profile am sinnvollsten erscheinen, da bei seinen Profilen nach der CMS-Transformation (zu sRGB) eben keine Gamma-Korrektur angewendet werden muß. ;)

bei "deinen" Profilen aber schon ;)

 

//edit

siehe: https://www.systemkamera-forum.de/colormanagement/24084-farbprofile-fuer-kamera-selbst-erstellen-5.html#post190092

 

Gruß

Günter

bearbeitet von gms
Link zum Beitrag
Auf anderen Seiten teilen

Hallo Günter!

das ist ja auch der Grund warum mir Thorstens Profile am sinnvollsten erscheinen, da bei seinen Profilen nach der CMS-Transformation (zu sRGB) eben keine Gamma-Korrektur angewendet werden muß. ;)

bei "deinen" Profilen aber schon ;)

Wie heißt es so schön?

Der Schein drückt :-)

Warten wir ab, was Olli daraus macht...

Link zum Beitrag
Auf anderen Seiten teilen

  • 2 months later...
  • 1 year later...
  • 1 month later...
z.B. hier:rawstudio - Revision 4318: /trunk/profiles

Du kannst auch das dem Adobe DNG-Konverter beiliegende Profil verwenden. Perfekt sind solche Profile allerdings nie, sondern allenfalls der Ausgangspunkt für eigene Arbeit.

Tolle Sache diese Profile, habe mir für meine Cams einige heruntergeladen, aber warum weigert sich, zumindest mein RT, diese Profile zu benutzen?

 

Habe RT 4.0.9.50, lade ein RAW-Bild, gehe rechts zu dem Icon "Profil aus Datei laden" -> im neuen Fenster "Bearbeitungsprofil laden ..." finde ich im Pfad "D:\\Programme\RawTherapee\profiles" eine Sammlung von Profilen mit der Dateibezeichnung .pp3 - aber von den dcp-Dateien sehe ich erstmal nix!

 

Gehe ich im Pfad zurück auf "RawTherapee" finde ich den Ordner "dcpprofiles", öffne ich diesen, sehe ich von den dort hinein kopierten rwastudio-profiles erstmal auch wieder nix!

 

Wechsele ich jedoch den Dateityp im Fenster unten rechts von "Bearbeitungsprofile" auf "Alle Dateien" werden die dcp-Dateien angezeigt.

Das hilft aber nicht sonderlich weiter, denn versuche ich eine dieser dcp-Dateien zu öffnen -> stürzt RT ab mit der Fehlermeldung:

"Microsoft Visual C++ Runtime - This application has requested the Runtime to terminate it in an unusual way ..."

 

Wäre schön, wenn die Experten hier zu einer Lösung dieses Problems beitragen könnten, bedanke mich im voraus!

Link zum Beitrag
Auf anderen Seiten teilen

Das Problem ist gelöst, denn es war eigentlich keines oder frei nach dem Motto "Mit Brille wäre das nicht passiert"!

 

Unter "Bearbeitungsprofile" versteht RT nur die pp3-Profile, die kameraspezifischen dcp-Profile sind halt "Eingabeprofile" und lassen sich nur im Reiter "Farbmanagement -> Eingabeprofil -> Benutzerdefiniert" aufrufen ...

Na ja, vielleicht wird aus mir auch noch ein Experte ... :D

Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...