Funktioniert Highlight Recovery auch ?cantsin hat geschrieben: ↑Fr 10 Dez, 2021 18:01 Breaking news:
Es gibt jetzt einen Software-Konverter von ProRes Raw zu CinemaDNG für MacOS:
https://www.cined.com/raw-convertor-new ... cinemadng/
https://apps.apple.com/app/raw-convertor/id1598580439
Damit lässt sich ProRes Raw jetzt in Resolve und Foto-Rawkonvertern bearbeiten.
Funktioniert bisher nur mit ProRes Raw-Material aus der Sony a7S III, Sony FX3, Sony A1, Nikon Z 6 und Nikon Z 7.
Darth wird schon wieder esoterisch :) Meinst Du der RAW Konverter von Davinci ist besser als der anderer Hersteller? Natürlich ist ein extra Schritt, den man vorab machen muss, kein Vorteil und es wäre besser wenn auch Davinci den Codec unterstützen würde. Aber das ist ja ein Defizit von Resolve, nicht eines der Formate die nicht unterstützt werden :) Ob man die 12 Bit und Felxibilität in der Post jetzt braucht, läßt sich auch nicht pauschal beantworten. Das kann ja jeder so machen wie er mag. Nur weil man eine RAW Option hat, heißt das ja nicht dass man sie immer nutzen muss. Mittlerweile ist PRR aber bei so vielen Kameraherstellern implementiert, dass man früher oder später mit dem Format konfrontiert werden wird. Außer man filmt immer nur mit Arri, Red, oder Blackmagic-Kameras.Darth Schneider hat geschrieben: ↑Sa 11 Dez, 2021 05:55 Weil ich denke ein RAW Format in ein anders RAW Format konvertieren bedeutet eigentlich schon vor dem Schnitt, ein kleiner Qualitätsverlust..
Genau das versucht man ja eigentlich mit solchen RAW Codecs ja eigentlich von Anfang an zu vermeiden.
Das ist ganz sicher sinnvoll, denn in der Regel bringt man seine unterschiedlichen Formate erstmal in ein Einheitliches, um es anschließend zu graden. Falls dies erforderlich sein sollte. Ich weiß auch nicht wo Deine Theorie herkommt, das ein zusätzlicher Speichervorgang ein Qualitätsverlust bedeuten sollte? Natürlich sollte das Inmtermediate-Format groß genug sein, und den kompletten Farbraum des Ursprungsformats abdecken, aber das tun sie ja. Ich wandele einmal in ACES, REC2020, P3, oder was auch immer und das war's. Ich weiß auch nicht wo Du mit Deiner Qualitätsverlust-Theorie, die nicht mal homöopathische Unterschiede ausmacht, hin möchtest? Du machst Dir Gedanken über Dinge die völlig irrelevant sind.Darth Schneider hat geschrieben: ↑Sa 11 Dez, 2021 06:38 Das ist keine Esoterik. Klar muss ich auch rendern, aber eben nur einmal…
Nicht von einem RAW Format und Programm aufs andere RAW Format und womöglich wieder zurück springen.
Das ist doch ganz bestimmt nicht sinnvoll, lieber gleich zusätzlich zu Resolve eine Final Cut Lizenz kaufen, wenn man das womöglich fast jeden Tag machen muss…
Würde ich jetzt darüber nachdenken.
Gruss Boris
ja -- da muss ich dir recht geben!pillepalle hat geschrieben: ↑Sa 11 Dez, 2021 06:33 Ob Du das (den Farbraum und Container wechseln) vorher in einem anderen Programm machst, oder später in Resolve, macht keinen Unterschied. Und Du verlierst dabei nicht mehr Qualität. Aber es ist natürlich etwas unpraktischer.
so lang nur "verlustfreie" komprimierung im spiel ist (was allerdings bei BRAW normalerweise nicht der fall ist!), geht da tatsächlich nichts verloren.Darth Schneider hat geschrieben: ↑Sa 11 Dez, 2021 07:03 Also wenn ich jetzt von BRaw Material in ProRes RAW wandle hat das gar keinen Einfluss auf die Bildqualität ?
Das Obwohl das Material ja auch erst dekomprimiert und dann wieder in ein neues Format komprimiert werden muss..?
Jungs, das kann ich mir wirklich nicht vorstellen das ist sowas von unlogisch für mich.
Ein wenig Verlust muss da doch rein physikalisch bedingt einfach sein…
Verlustfreie Kompression sind mit 1:4 bei Raw nicht möglich.mash_gh4 hat geschrieben: ↑Sa 11 Dez, 2021 07:11so lang nur "verlustfreie" komprimierung im spiel ist (was allerdings bei BRAW normalerweise nicht der fall ist!), geht da tatsächlich nichts verloren.Darth Schneider hat geschrieben: ↑Sa 11 Dez, 2021 07:03 Also wenn ich jetzt von BRaw Material in ProRes RAW wandle hat das gar keinen Einfluss auf die Bildqualität ?
Das Obwohl das Material ja auch erst dekomprimiert und dann wieder in ein neues Format komprimiert werden muss..?
Jungs, das kann ich mir wirklich nicht vorstellen das ist sowas von unlogisch für mich.
Ein wenig Verlust muss da doch rein physikalisch bedingt einfach sein…
wenn du eine datei in ein .zip file packst, und danach wieder woanders auspackst, erwartest du ja auch, dass das file tatsächlich wieder das gleiche ist bzw. nichts unterwegs verloren gegangen ist.
diesen anspruch verbindet man normalerweise auch mit RAW-datenformaten, weil man von denen auch ein klein wenig mehr verlangt, als nur eine täuschen ähnliche erscheinung zu bewahren -- eben eine "verlustfreie" kompression der ursprünglichen daten, was ja tlw. ohnehin mit kompressionsraten bis zu 1:4 möglich ist, wenn die enthaltenen redundanzen in der übertragung minimiert werden.
Aber schau dir mal den Komprimierungsfaktor an.lensoperator hat geschrieben: ↑Sa 11 Dez, 2021 10:42 Ich hoffe ihr wisst alle das man bei Arri Kameras nach dem Filmen eigentlich immer noch mal das RAW durch einen Arri Converter jagd um es zu komprimieren.
Uncompressd RAW brauch doch niemand auf der Welt.
doch -- das gilt gegenwärtig so in etwa als orientierung für zeitzgemäße verlustfreie bildkompression. derartiges ist mittlerweile sogar in echtzeit umsetztbar.
ja -- das hat damit zu tun, dass neben dem unkomprimierten modus in DNG als einzige verlustfrei kompressionsvariante nur diese uralte JPEG92 methode (in der grafik ganz unten links!) zur verfügung steht, die eben leider ganz gar nicht mehr dem stand der technik entspricht.
oder sich mit dieser nicht ganz optimalen kompressionsrate von etwa 1:2 standardkonformer verlustfreier DNGs zufrieden geben.
Das geht schon damit los, daß es gar nicht geht.Darth Schneider hat geschrieben: ↑Sa 11 Dez, 2021 07:03 Also wenn ich jetzt von BRaw Material in ProRes RAW wandle
Sakrileg!!!!!pillepalle hat geschrieben: ↑Sa 11 Dez, 2021 06:19 Nur weil man eine RAW Option hat, heißt das ja nicht dass man sie immer nutzen muss
Der Konverter bietet aber eben die verlustfreie DNG-Komprimierung nicht. Daher bleibt - wenn man wirklich das Maxium will - nur unkomprimiertes CDNG.mash_gh4 hat geschrieben: ↑Sa 11 Dez, 2021 10:55doch -- das gilt gegenwärtig so in etwa als orientierung für zeitzgemäße verlustfreie bildkompression. derartiges ist mittlerweile sogar in echtzeit umsetztbar.
hier eine -- leider schon wieder reichlich veraltete -- grafik, die den fortschritt im feld der verlustfreien bildkompressione ein wenig veranschaulicht:
ja -- das hat damit zu tun, dass neben dem unkomprimierten modus in DNG als einzige verlustfrei kompressionsvariante nur diese uralte JPEG92 methode (in der grafik ganz unten links!) zur verfügung steht, die eben leider ganz gar nicht mehr dem stand der technik entspricht.
oder sich mit dieser nicht ganz optimalen kompressionsrate von etwa 1:2 standardkonformer verlustfreier DNGs zufrieden geben.
aber, wie gesagt, es gibt eben mittlerweile deutlich effektivere verlustfreie kompressionsmechanismen.
im falle von verlustfreier komprimmierung ist es übrigens immer sehr schwer überhaupt derartige kompressionsfaktoren zanztugeben, da sie in wahrheit sehr stark von den verwendeten bilddaten abhängen.
im gegensatz zu einfacheren formen verlusbehafteter DCT- od DWT-komprimierung, wo man bloß eine beliebige anzahl an kleineren koeffizienten wegschneiden muss, um eine festgelegte größe, bandbreite od. eben kompressionsrate zu erzielen, müssen hier ja tatsächlich alle koeffizienten übertragen werden, damit das ganze anschließend wieder verlustfrei umkehrbar ist. es bleibt also nur der weg, im zuge des nachfolgenden entropy codings doch noch möglichst viele redundanzen aufzufinden und in vorteilhafter weise zu umschreiben, um das ganz doch noch noch weiter zu verkleinern, was aber ein vergleichsweise rechenintensiver vorgang ist.
das ist ein derart einfach zu behebendes implementationsdetail, dass vermutlich ein simpler bug-report reichen würde, um diesbezüglich abhilfe zu schaffen.
alle dort aufgeführten verfahren beziehen sich ausschließlich aus verlustfreie bildkompression!
wie kommst du auf diesen unsinn!
ja -- natürlich! -- innerhalb der programme wird natürlich ausschließlich mit unkomprimierten bilddaten gearbeitet.
Das lässt sich aber mit SlimRaw lösen (wobei es nur unpraktisch ist, sein Material zweimal hintereinander zu konvertieren).
hast du noch nie den inhalt einer .zip-datei ausgepackt?Darth Schneider hat geschrieben: ↑Sa 11 Dez, 2021 13:14 Etwas schon komprimiertes wieder zu verwandeln in etwas unkomprimiertes…
Ja ist das denn nicht ein Widerspruch in sich selber ? ;)
Das sind dann aber keine verlustfreien Methoden, denn hier werden dann Mittelwerte gebildet und eben nicht mehr jeder einzelne Wert wiederherstellbar gespeichert.
ja -- diese anforderung wird von diesen mechanismen, die die heligkeitswerte nicht einfach nur als räumliche anordnung von pixeln bzw. helligkeitswerten betrachten, sondern vielmehr die diesbezügliche änderungen und übergänge zw. benachbaren pixeln als beschreibung nutzen -- also mittels DCT od. DWT eine transformation in die frequency domain vornehmen -- durchaus erfüllt. man kann ihre arbeitsweise bzw. die durchgeführte transformation später wieder vollständig und ohne jeden verlust in die andere richtung umkehren.
diese riesige liste hab ich nur zu illustrationsszwecken eingeworfen, um aufzuzeigen, dass sich in den vergangenen jahrzehnten in dieser frage doch noch einiges getan hat und dieser konstante wert, von dem iasi gesprochen hat, nicht haltbar ist.freezer hat geschrieben: ↑So 12 Dez, 2021 10:54 Ich verstehe nicht ganz, warum Du hochspezialisierte verlustfreie Kompressionsalgorithmen hier ins Spiel bringst, die vor allem auf die Kompression von Satellitenbilder hingetrimmt wurden. QLAIS-LUT dient der Kompression von hyperspektralen AVRIS Daten unter ganz bestimmten Bedingungen (künstliche Regelmäßigkeiten die durch die Konvertierung der Rohdaten in Strahlungsdaten entstehen). Das lässt sich eben nicht auf normale Videodaten umlegen.
Mit zunehmender Rechenleistung kann man zwar komplexere Kompressionsmethoden nutzen, aber ich sehe das aktuell nicht bei verlustfreier Raw-Komprimierung.mash_gh4 hat geschrieben: ↑So 12 Dez, 2021 13:46diese riesige liste hab ich nur zu illustrationsszwecken eingeworfen, um aufzuzeigen, dass sich in den vergangenen jahrzehnten in dieser frage doch noch einiges getan hat und dieser konstante wert, von dem iasi gesprochen hat, nicht haltbar ist.freezer hat geschrieben: ↑So 12 Dez, 2021 10:54 Ich verstehe nicht ganz, warum Du hochspezialisierte verlustfreie Kompressionsalgorithmen hier ins Spiel bringst, die vor allem auf die Kompression von Satellitenbilder hingetrimmt wurden. QLAIS-LUT dient der Kompression von hyperspektralen AVRIS Daten unter ganz bestimmten Bedingungen (künstliche Regelmäßigkeiten die durch die Konvertierung der Rohdaten in Strahlungsdaten entstehen). Das lässt sich eben nicht auf normale Videodaten umlegen.
würde man von verlustfreien aktuellen formaten sprechen, ist normalerweise eher von FLIF, JPEG XL, AVIF, HEIF und FFV1die rede.
aus: The Impact of State-of-the-Art Techniques for Lossless Still Image Compression:
lossless.png
die bieten zwar durchwegs sehr gute kompressionsraten, brauchen dafür allerdings viel zu viel rechenzeit, um sie für bewegtbildaufnahmen in echtzeit nutzen zu können.
für diese zwecke nutzt man daher bewusst einfacher gehaltene lösungen, wie sie in JPEG XS, GPR u.ä. zu finden sind. diese basieren im kern zwar natürlich auch auf mechanismen, die schon länger bekannt sind, aber doch ständig wieder ein kein wenig weiterentwickelt und verbessert wurden, so dass auch dort verlustfreie kompressionsraten von 1:4 im hier relevanten kontext (=CFA daten) mittlerweile nichts völlig ungewöhnliches mehr sind.
aber wie bereits gesagt: die tatsächlich erzielbare kompressionsrate ist bei diesen techniken immer sehr stark vom bildmaterial abhängig! -- also z.b. davon, ob die kamera ein OLPF vor dem sensor nutzt...