slashCAM Forum

Kann jemand mal das original ProRes Raw dem von mir konvertiertem ProRes 4444 gegenüber stellen und schauen, ob man mit dem 4444 genauso weit kommt?
Leider kann ich das PRR mit Resolve ja nicht testen und nur das 4444 allein sagt ja auch nicht viel.

Wenn man also quasi genauso viel damit machen kann, dann würde für mich eine konvertierung Sinn machen, auch wenn man an der Stelle noch nicht weiß, was ein echtes 10Bit 422 bereit stellen würde bzw könnte. Der file wurde zu BT 2020 gerendert.

Positiv in Bezug auf Dateigröße ist, dass das ProRes nicht größer ist.
Danke! :-)

Hier der original Link zum PRR & das ProRes:
https://filmplusgear.com/prores-raw-test16
https://we.tl/t-KKc3Xcoo6d


Mediainfo:

Format : MPEG-4
Format-Profil : QuickTime
Codec-ID : qt 2005.03 (qt )
Dateigröße : 1,26 GiB
Dauer : 9s 40 ms
Modus der Gesamtbitrate : variabel
Gesamte Bitrate : 1 193 Mb/s
Kodierungs-Datum : UTC 2021-01-29 19:53:42
Tagging-Datum : UTC 2021-01-29 19:54:12
verwendete Encoder-Bibliothek : Apple QuickTime
TIM : 13:57:59:20
TSC : 25
TSZ : 1

Video
ID : 1
Format : ProRes
Format-Version : Version 1
Format-Profil : 4444
Codec-ID : ap4h
Dauer : 9s 40 ms
Bitraten-Modus : variabel
Bitrate : 1 191 Mb/s
Breite : 4 112 Pixel
Höhe : 2 176 Pixel
Bildseitenverhältnis : 1,890
Modus der Bildwiederholungsrate : konstant
Bildwiederholungsrate : 25,000 FPS
ColorSpace : YUV
ChromaSubsampling/String : 4:4:4
Scantyp : progressiv
Bits/(Pixel*Frame) : 5.323
Stream-Größe : 1,25 GiB (100%)
verwendete Encoder-Bibliothek : adb0
Sprache : Englisch
Kodierungs-Datum : UTC 2021-01-29 19:53:42
Tagging-Datum : UTC 2021-01-29 19:53:42
colour_primaries : BT.2020
transfer_characteristics : PQ
matrix_coefficients : BT.2020 non-constant

Audio
ID : 2
Format : PCM
Format-Einstellungen : Little / Signed
Codec-ID : sowt
Dauer : 9s 40 ms
Bitraten-Modus : konstant
Bitrate : 1 536 kb/s
Kanäle : 2 Kanäle
ChannelLayout : L R
Samplingrate : 48,0 kHz
BitDepth/String : 16 bits
Stream-Größe : 1,66 MiB (0%)
Sprache : Englisch
Kodierungs-Datum : UTC 2021-01-29 19:53:42
Tagging-Datum : UTC 2021-01-29 19:53:42

Andere
ID : 3
Type : Time code
Format : QuickTime TC
Dauer : 9s 40 ms
Bildwiederholungsrate : 25,000 FPS
TimeCode_FirstFrame : 13:57:59:20
TimeCode_Striped/String : Ja
Sprache : Englisch
Kodierungs-Datum : UTC 2021-01-29 19:53:42
Tagging-Datum : UTC 2021-01-29 19:53:42

push ;-)

Du könntest den Header von dem File das Du nicht öffnen kannst (mutmaßlich GH4(5)) selber patchen.

Bluboy hat geschrieben: ↑Sa 30 Jan, 2021 10:52 Du könntest den Header von dem File das Du nicht öffnen kannst (mutmaßlich GH4(5)) selber patchen.

Du hast da irgendetwas nicht ganz verstanden...

Was ganz anderes, eine Kamera mit Bayer Sensor, die nicht oversamplet kann rechnerisch eh nicht 444 haben. 4:2:2 ist höchstwahrscheinlich das Optimum.

Oder nicht?

Mantas hat geschrieben: ↑Sa 30 Jan, 2021 12:15 Was ganz anderes, eine Kamera mit Bayer Sensor, die nicht oversamplet kann rechnerisch eh nicht 444 haben. 4:2:2 ist höchstwahrscheinlich das Optimum.

Oder nicht?

Genau, wir erhalten durch Interpolation (Downsampling) Farbwerte ohne Interpolation ("echte").
So lustig ist die Welt.
Hier ;)

Man braucht aber ProRes 444 in klusters Fall, weil das 12bit Farbtiefe speichert, während die ProRes HQ, 422 & Co. nur 10bit unterstützen.

ich kann dir hier leider auch nicht helfen, da es auf meinen betriebsystem bisher leider auch noch keine möglichkeit gibt, prores zu öffenen. :(

was mir aber aufgeffallen ist bzw. für deine überlegung rund um die gleichwertigkeit des materials eine nicht zu unterschätzende rolle spielt, ist die tatsache, dass dieses prores4444 material laut deiner mediainfo-ausgabe offenbar YUV darstellung statt RGB nutzt:
prores4444 unterstützt grundsätzlich beides. die damit verbundenen unterschiede müssen sich nicht unbedingt gravierend auswirken, weil das hauptsächlich rundungsfehler und eine tiefgreifende verzerrung der werteskalen berührt, deren tatsächliche relevanz aber nur sehr schwer abgeschätzt oder verallgemeinert werden kann.

Mantas hat geschrieben: ↑Sa 30 Jan, 2021 12:15 Was ganz anderes, eine Kamera mit Bayer Sensor, die nicht oversamplet kann rechnerisch eh nicht 444 haben. 4:2:2 ist höchstwahrscheinlich das Optimum.

Oder nicht?

16Bit Raw ist 4444

So, da bin ich wieder. ;-)
Erst schon mal danke an alle Helfenden.

Vielleicht erstmal warum das ganze.
Meine neue Cam gibt 16Bit Raw aus und ich habe einen Shogun 7 der das zumindest mit 12Bit (wenn nicht sogar mehr) aufzeichnen kann.

Da ich aber nun mal Resolve benutze ist das momentan nur mit konvertierung zu lösen, aber natürlich steht die Frage im Raum, ob das alles was bringt und vor allem wenn man schon XAVC-I 300 intern hat.

Leider weiß ich aber garnicht was sowohl das echte, als auch das Shogun Raw könnte.
Eben habe ich mal ein Raw & XAVC-I aufgenommen und vergleiche dann die Konvertierung, denn wenn das nix bringt, dann kann ich es mir eh sparen und den Shogun gegen einen BM5III tauschen, denn einen Fieldmoni hätte ich schon nach wie vor gerne.

Dumm nur, das ich eigentlich sogar nicht recht weiß, wie ich die Daten vergleichen soll, denn die Dynamic ändert sich ja dadurch nicht.
Ich schätze ich brauche ein paar distructive roki luts? ;-))

siehst du irgendeine möglichkeit einige frames aus dem ursprünglichen ProResRaw als cDNG auszugeben bzw. umzuwandeln? dass kann man dann nämlich schon bspw. im natron wirklich bis an die grenzen zrlegen und im detail analysieren bzw. mit anderem material vergelichen.

derartiger detektivischer eifer macht zwar zwischendurch durchaus spass, ist aber natürlich für den tatsächlichen arbeitsalltag völlig irrelevant bzw. viel zu umständlich und langwierig.

ich würde mir auch nicht zu viel davon erwarten. mit vernünftig gehandhabten LOG-formaten kannst im alltag sicher auch genauso befriedigende und ausreichend nachbearbeitbare aufnahmen schaffen.

mash_gh4 hat geschrieben: ↑Sa 30 Jan, 2021 20:07 siehst du irgendeine möglichkeit einige frames aus dem ursprünglichen ProResRaw als cDNG auszugeben bzw. umzuwandeln.

Gibt's irgendeine Software, die das kann? Das wäre mir völlig neu... (und sehr willkommen als Alltagslösung.)

cantsin hat geschrieben: ↑Sa 30 Jan, 2021 20:08

mash_gh4 hat geschrieben: ↑Sa 30 Jan, 2021 20:07 siehst du irgendeine möglichkeit einige frames aus dem ursprünglichen ProResRaw als cDNG auszugeben bzw. umzuwandeln?

Gibt's irgendeine Software, die das kann? Das wäre mir völlig neu... (und sehr willkommen als Alltagslösung.)

ehrlich gestanden ist mir das im video-umfeld bisher praktisch auch nur einmal untergekommen, als sich ein richtig guter colorist der oberliga nach derartigen möglichkeiten einer ausgabe in RAW-format umgehört hat.

normalerweise wird derartiges material in dfiesem umfeld ja tatsächlich immer nur als eingabeformat genutzt und im besten fall in irgendwelche schrecklich platzverschwendenden hochwertigen intermediate formate umgewandelt. du kennst aber sicher noch diesen alten ursprünglichen adobe raw-converter, mit dem fotografen vor langer zeit einmal die verschieden herstellerspezifischen raw-bilder weitestgehend verlustfrei nach DNG umverpackt haben, weil wichtige programme noch nichts anderes unterstützt haben. im video-umfeld steht aber offenbar auch dieser workflow, der aus praktischen erwägungen heraus ohnehein nicht sonderlichen einladend klingt, in der regel gar nicht erst offen.

Ups sorry, ihr könnt mein Testfile vergessen, denn MediaEncoder ist scheinbar doch nicht in der Lage auf das Raw plugin zuzugreifen um das Material in Slog3 bereit zustellen.
Stattdessen kommt es scheinbar als art Rec raus, was dazurführt das es sofort clippt.

Versuche es nochmal mit export aus Premiere.

cantsin hat geschrieben: ↑Sa 30 Jan, 2021 20:08

mash_gh4 hat geschrieben: ↑Sa 30 Jan, 2021 20:07 siehst du irgendeine möglichkeit einige frames aus dem ursprünglichen ProResRaw als cDNG auszugeben bzw. umzuwandeln.

Gibt's irgendeine Software, die das kann? Das wäre mir völlig neu... (und sehr willkommen als Alltagslösung.)

Ich hatte vermutet das ME das können sollte, wenn Pr es kann, scheinbar doch nicht.

Ich lade das gerade hoch und poste gleich den Link, vielleicht kann sich das dann jemand noch mal ansehen.

klusterdegenerierung hat geschrieben: ↑Sa 30 Jan, 2021 19:53 Ich schätze ich brauche ein paar distructive roki luts? ;-))

Der User ksingle ist der richtige Ansprechpartner, er hat natürlich alle kostenlose LUT's...

Hab gerade mal footage mit 12,8K Iso verglichen und wenn man wegen des Rauschen den denoise anwendet, sieht man im XAVC-I Material mehr Kompressions Kluster als im 4444, aber nur wenn sich das Material bewegt, sonst sieht man kaum einen Unterschied.

Ich teste noch mal die alte Lut von damals wo mir das Material um die Ohren geflogen ist, vielleicht sieht man ja damit einen Unterschied.

klusterdegenerierung hat geschrieben: ↑Sa 30 Jan, 2021 18:07

Mantas hat geschrieben: ↑Sa 30 Jan, 2021 12:15 Was ganz anderes, eine Kamera mit Bayer Sensor, die nicht oversamplet kann rechnerisch eh nicht 444 haben. 4:2:2 ist höchstwahrscheinlich das Optimum.

Oder nicht?

16Bit Raw ist 4444

wirklich? Ich dachte das mit RAW sei etwas anders? Hier ein Beitrag aus BM Forum:

It has nothing to do with it.

4:4:4, 4:2:2, 4:2:0 etc are all descriptions of a form of lossy compression which reduces the resolution of the chroma channels of video. They do not describe colour space nor are they in any way related to bayer patterns or bit depth. It is worth pointing out, that because bayer pattern data needs to be debayered before it can be viewed - the actual quality of the footage is very much dependant on how it is debayered.

The confusion often arises from the fact that people talk about chroma resolution in terms of having a high enough sensor resolution in order to have 1 coloured photosite per channel. This is because a bayer pattern sensor uses photosites which are either red, green or blue. 1 pixel on the raw image originally came from a photosite which was either red green or blue, not one with full RGB data. The RGB colour for each pixel is derived by interpolating the data from the surrounding pixels - how well this is done can make a big difference to the overall image quality. The argument is that because each 1 pixel does not have proper non-interpolated RGB data, the sensor should have a higher resolution than the final video resolution, in order that the final resolution ends up having x1 photosite of each colour per pixel. The BMCC sensor does not have a high enough resolution so that when converting to 1920x1080 HD video, each pixel has x1 red, x1 green and x1 blue photosite behind it. This would suggest that in a similar way to how 4:2:2 has a lower chroma resolution, the bmcc sensor also has a lower chroma resolution. The problem with this is that when compressing to 4:2:2, the effect is uniform and specific. When debayering the raw data, the effect is very variable and dependant on the debayering method. Hence one should not confuse chroma-subsampling with bayer pattern sensors.

The BMCC shoot raw uncompressed video as bayer pattern data. This means that it is true to say you can take that footage and turn it into 4:4:4 compressed footage. The Raw footage is also 16bit data stored in a 12bit log file.
...

https://forum.blackmagicdesign.com/view ... 623#p56024

Hab mal die Madmax Lut mit extremen Verbiegungen angewendet.
Links sieht man das 10Bit XAVC-I und Rechts das 16Bit Raw zu 12Bit Log.

Finde links sieht irgendwie krasser aus, oder tut sich da nix?

auf 8Bit Bildschirm sieht beides nach 8Bit aus? ;)

Finde links sieht irgendwie krasser aus, oder tut sich da nix?

Bei Bild rechts, sieht man genau soviel Banding, wie auf dem Bild links.
Links etwas braun/orange/gelblicher, rechts rosa/rötlicher...

Guter Einwand, ja in Resolve auf 10Bit Monitor sieht es identisch aus wie im Screenshot auf dem 8Bit Monitor.
Könnte für meine 8Bit These sprechen. ;-))

PS, übringens, damit man das nicht falsch versteht, sobald man die lut deaktiviert, ist all der Spuk weg.

klusterdegenerierung hat geschrieben: ↑Sa 30 Jan, 2021 18:07

Mantas hat geschrieben: ↑Sa 30 Jan, 2021 12:15 Was ganz anderes, eine Kamera mit Bayer Sensor, die nicht oversamplet kann rechnerisch eh nicht 444 haben. 4:2:2 ist höchstwahrscheinlich das Optimum.

Oder nicht?

16Bit Raw ist 4444

Das ist doch völlig egal. Eine Bayer Kamera kann es doch rechnerisch nicht füllen.
8bit sieht im 10bit Codec trotzdem wie 8bit aus. Als Beispiel.

klusterdegenerierung hat geschrieben: ↑Sa 30 Jan, 2021 21:50 Guter Einwand, ja in Resolve auf 10Bit Monitor sieht es identisch aus wie im Screenshot auf dem 8Bit Monitor.
Könnte für meine 8Bit These sprechen. ;-))

PS, übringens, damit man das nicht falsch versteht, sobald man die lut deaktiviert, ist all der Spuk weg.

kannst Du mir diese LUT posten womit diese Banding auftreten und auch was Du genau bei Curves extrem verbogen hast?

roki100 hat geschrieben: ↑Sa 30 Jan, 2021 21:44 Bei Bild rechts, sieht man genau soviel Banding, wie auf dem Bild links.
Links etwas braun/orange/gelblicher, rechts rosa/rötlicher...

derartiges banding hat meist sehr viel mit der YUV-codierung bei der übertragung und kompression zu tun, weil dadurch die konkreten abstufungen in den farben an ganz anderen stellen zu liegen kommen als die helligkeitsstufen. man kann zwar dem selben effekt grundsätzlich auch bei RGB material begegnen, wenn die kanäle eine deutlich unterschiedliche aussteuerung aufweisen, und dann beim spreizen in unterschiedlicher geschwindigkeit die werte wechseln, aber in der regel ist meist erstere erklärung zutreffender, dort wo es wirklich weh tut. ;)

ich habe Banding in DR nur mit 8bit. Mit 10Bit (mit 12Bit sowieso) keine, nur mit 8bit - mehr muss ich da nicht verstehen, egal was ich mache, ob (BMD DR eigene) LUT oder nicht, wenn ich 8Bit grade, sehe ich immer wieder an manchen stellen im Video, Artefakte/komische flecken/Banding.

roki100 hat geschrieben: ↑Sa 30 Jan, 2021 23:03 ich habe Banding in DR nur mit 8bit. Mehr muss ich da nicht verstehen, egal was ich mache, ob LUT oder nicht, wenn ich 8Bit grade, sehe ich immer wieder an manchen stellen im Video, Artefakte/komische flecken/Banding.

nein -- man hat nur exakt 4x weniger abstufungen im ausgangsmaterial, aber im grunde genau die selben probleme, wenn man die eingriffe übertreibt. alles was man 8bit demonstrieren kann, lässt sich auch in selber weise mit ein bisserl mehr gewalt auch an 10bit beispielen hervorzaubern. wie man es vermeidet, ist die größere kunst! ;)

Mantas hat geschrieben: ↑Sa 30 Jan, 2021 21:59

klusterdegenerierung hat geschrieben: ↑Sa 30 Jan, 2021 18:07

16Bit Raw ist 4444

Das ist doch völlig egal. Eine Bayer Kamera kann es doch rechnerisch nicht füllen.
8bit sieht im 10bit Codec trotzdem wie 8bit aus. Als Beispiel.

Keine Ahnung was Du meinst?
Klar wenn ich 16 in 12 presse ist das nicht mehr unbedingt 16, aber immer noch mehr als 8 und 10.

mash_gh4 hat geschrieben: ↑Sa 30 Jan, 2021 22:59

roki100 hat geschrieben: ↑Sa 30 Jan, 2021 21:44 Bei Bild rechts, sieht man genau soviel Banding, wie auf dem Bild links.
Links etwas braun/orange/gelblicher, rechts rosa/rötlicher...

derartiges banding hat meist sehr viel mit der YUV-codierung bei der übertragung und kompression zu tun, weil dadurch die konkreten abstufungen in den farben an ganz anderen stellen zu liegen kommen als die helligkeitsstufen. man kann zwar dem selben effekt grundsätzlich auch bei RGB material begegnen, wenn die kanäle eine deutlich unterschiedliche aussteuerung aufweisen, und dann beim spreizen in unterschiedlicher geschwindigkeit die werte wechseln, aber in der regel ist meist erstere erklärung zutreffender, dort wo es wirklich weh tut. ;)

Öh nur zur info, das eine ist RGB das ander YUV und bei 8Bit Rec sieht es auch so aus.

roki100 hat geschrieben: ↑Sa 30 Jan, 2021 23:03 ich habe Banding in DR nur mit 8bit. Mit 10Bit (mit 12Bit sowieso) keine, nur mit 8bit - mehr muss ich da nicht verstehen,

Schade das Du Dich selbst so begrenzt.
So kommste Du leider nicht vom Fleck und erklärt mir jetzt auch das selbst wenn ein Wissenschaftler Dir belegen könnte das es nicht an Bit liegt, Du würdest es trotzdem nicht glauben und widersprechen! Strange!

mash_gh4 hat geschrieben: ↑Sa 30 Jan, 2021 23:15

roki100 hat geschrieben: ↑Sa 30 Jan, 2021 23:03 ich habe Banding in DR nur mit 8bit. Mehr muss ich da nicht verstehen, egal was ich mache, ob LUT oder nicht, wenn ich 8Bit grade, sehe ich immer wieder an manchen stellen im Video, Artefakte/komische flecken/Banding.

nein -- man hat nur exakt 4x weniger abstufungen im ausgangsmaterial, aber im grunde genau die selben probleme, wenn man die eingriffe übertreibt. alles was man 8bit demonstrieren kann, lässt sich auch in selber weise mit ein bisserl mehr gewalt auch an 10bit beispielen hervorzaubern. wie man es vermeidet, ist die größere kunst! ;)

Die Tgae hatte ich ein Video zu diesem Thema gesehen und da zeigte jemand, das genau solche effekte bei graden auftraten, wenn er das Material gedenoised hat. Erst als er die Parameter behutsame mit visueller 1:1 Kontrolle veränderte, gingen die Rainbows wieder weg, aber auch dabei ging es nicht um 8Bit.

roki100 hat geschrieben: ↑Sa 30 Jan, 2021 22:32

klusterdegenerierung hat geschrieben: ↑Sa 30 Jan, 2021 21:50 Guter Einwand, ja in Resolve auf 10Bit Monitor sieht es identisch aus wie im Screenshot auf dem 8Bit Monitor.
Könnte für meine 8Bit These sprechen. ;-))

PS, übringens, damit man das nicht falsch versteht, sobald man die lut deaktiviert, ist all der Spuk weg.

kannst Du mir diese LUT posten womit diese Banding auftreten und auch was Du genau bei Curves extrem verbogen hast?

Hab eine Node davor geschaltet und an dieser einfach ein bisschen die Gain & Gamma Werte hoch gezogen.
Allerdings tauchte dieser Effekt nicht durchgehend auf,scheint eine art Frequenz zu sein, deswegen wohl auch Bit unabhängig.

klusterdegenerierung hat geschrieben: ↑Sa 30 Jan, 2021 18:07 16Bit Raw ist 4444

bevor hier noch mehr sachen bunt durcheinander geworfen werden:

"Raw ist 4444"

das stimmt leider in dieser weise nicht, weil zwar in einem raw-file tatsächlich keine farbunterabtatstung vorliegt, wie man es mit dieser 4:4:4 notation in anderen zusammenhängen andeutete, aber eine ungebayertes RAW bild besitzt nur einen einzigen kanal mit helligkeitsinformationen, nicht drei -- so wie ein s/w bild. nur die lage der pixel ermöglicht es, später die farbe zu rekonstrieren. trotzdem passiert das in einer gänzlich anderen weise als bei YUV-codierter übertragung mit farbunterabtastung, so dass es nicht viel sinn macht, die beiden sachen ohne langes überlegen in einen topf zu werfen. tatsächlich gibt es aber einen zusammenhang bzgl. der enthaltenen bzw. rekonstruierberen farbinformation, nur ist der ein bisserl komplizierter gelagert.

Das 4444 steht ja auch eher symbolisch in Bezug auf Raw, denn bei Raw gibt es ja keine Farbkomprimierung.
Das 4444 kommt ja vom ProRes 4444 und ist dort die höchste Quali und gibt keine Bittiefe mehr an, deswege gehe ich mal davon aus, dass das 4444 für kein subsampling und 16Bit steht, sofern ProRes 16Bit kann. :-)