Das hängt aber schon auch mit von der Kamera ab, wobei das bei der RED so wie Du schreibst zutrifft.
In einer seiner Antworten auf einen Kommentar hat er geschrieben, dass die Aufnahme mit der RED eine Woche früher gemacht wurde und die mit der Sony nachdem er sich einen Sonnenbrand zugezogen hatte.Frank Glencairn hat geschrieben: ↑Mi 27 Jun, 2018 22:11 Was das Beispiel aber deutlich zeigt, ist - wie ich in dem anderen Tread schon vermutet hatte - Prores raw ist kein wirkliches raw, und entsprechend scheiße und unbrauchbar sah das Ergebnis, vor allem in den Hauttönen aus.
Und von wegen, "I was in the sun" - bei dem Red Material ist nix davon zu sehen.
Naja....
Vielleicht einfach doch mal S-LOG/S-GAMUT „abdenken“ - ich hab´ immer gesagt dass x-LOG die Tonwertstufen bzgl. der verfügbaren Dynamik im mittleren Bereich der Tonwerte sichtbar einschränkt. Probier´ mal Cine1 und ITU Farben (bei der a6500 "gefiel" mir ITU nicht, das war noch ne andere Color Engine), dann biste wahrscheinlich nen entscheidenden Schritt näher dran. Meine Hautfarben sind super und ich kann in dem "missglückten" RED Video jetzt nichts "Besonderes" erkennen.klusterdegenerierung hat geschrieben: ↑Mi 27 Jun, 2018 23:13 Na ja! So lieb ich die A7III habe, aber so eine schöne Farbe haut die nicht raus!
Zudem, hast Du mal gesehen wie homogen die Hautoberfläche ist, das sieht nicht nach 10Bit, sondern nach mehr aus,
da können wir nur von träumen!
Ich denke mit Colorchecker daneben wäre Dir aufgefallen, das die Farben sitzen.
Nein, PRR ist einfach nur ein Monochrom-ProRes mit ein paar Metadaten. Und im Zusammenspiel mit der EVA1 wird ein ISO-variantes System daraus. Selbst der Weißabgleich ist in den Sensordaten eingebacken. Meine Theorie ist, dass Panasonic das so handhabt, da sie ansonsten keinerlei Einfluss auf den Gain- und WB-Algorithmus haben. Meine andere Theorie besagt, dass dadurch nach der 10 bit log EVA1 raw-Ausgabe im 12 bit lin in PRR mehr relevante Werte für den definierten ISO- und WB-Bereich gespeichert werden können. Und meine dritte ist, dass Panasonic einfach prinzipiell mit analogem Gain (auch für Kanalspezifischen gain für WB) arbeiten will. Habe aber von Panasonic noch keine sinnvolle Antwort dazu bekommen.Roland Schulz hat geschrieben: ↑Do 28 Jun, 2018 08:44 ...so richtig Licht haben wir in PRR anscheinend tatsächlich noch nicht. Eine Idee dazu von mir wäre noch dass PRR aufgrund der höheren Performance vielleicht bereits ein debayertes und "komprimiertes" Bild enthält. Damit wäre trotzdem noch ein großer Spielraum im Post vorhanden wenn wir, oder sagen wir einige davon ausgehen dass auch in den meisten anderen RAW Prozessen das Debayering ohnehin an erster Stelle steht.
Müssen wir nicht weiter verfolgen oder beleuchten, ich weiß dass es da verschiedene Ansichten gibt und bis auf ein paar Hinweise aus Manuals (u.A. Resolve) und verschiedenen gefundenen Blockschaltbildern ist mir kein grundsätzlicher Nachweis bekannt dass grundsätzlich immer so verfahren wird.
Ich denke den Vergleich so wie er geführt wurde kann man ziemlich vergessen!
Da Sony RAW bei den kleineren Cams (u.A. FS5, FS7) nur mit 12bit quantisiert wird ist stärkstens davon auszugehen dass der (ISO) Gain bereits vor der Speicherung erfolgt, also ISO variant. Redcode RAW quantisiert mit 16bit dagegen "höchstwahrscheinlich" die komplette ISO invariante Dynamik des Sensors.
Na ja, Teil 1 kennen wir nicht zu 100% was nun wirklich die "Monochrom-ProRes Daten" sind. Denke Du meinst noch reine Pixeldaten hinter dem CFA, also undebayerte Daten? Mag sein, vielleicht aber auch ein komprimiertes, debayertes Bild. Beides hebt Deine weiteren Theorien die ich sinnvoll sehe nicht aus, wobei normalerweise der WB nicht in den Sensordaten eingebacken wäre, das hier Aufgrund der kleineren Quantisierung aber durchaus Sinn machen würde (pre gain per channel) und sein kann. So hätte man aber nicht den vollen RAW Vorteil mehr sondern würde wie seinerzeit bei der Nikon D2x bereits ein "vorbewertetes" RAW Bild (WB ist grob vorgegeben) speichern.7nic hat geschrieben: ↑Do 28 Jun, 2018 09:01 Nein, PRR ist einfach nur ein Monochrom-ProRes mit ein paar Metadaten. Und im Zusammenspiel mit der EVA1 wird ein ISO-variantes System daraus. Selbst der Weißabgleich ist in den Sensordaten eingebacken. Meine Theorie ist, dass Panasonic das so handhabt, da sie ansonsten keinerlei Einfluss auf den Gain- und WB-Algorithmus haben. Meine andere Theorie besagt, dass dadurch nach der 10 bit log EVA1 raw-Ausgabe im 12 bit lin in PRR mehr relevante Werte für den definierten ISO- und WB-Bereich gespeichert werden können. Und meine dritte ist, dass Panasonic einfach prinzipiell mit analogem Gain (auch für Kanalspezifischen gain für WB) arbeiten will. Habe aber von Panasonic noch keine sinnvolle Antwort dazu bekommen.
Redraw speichert nicht nur höchstwahrscheinlich, sondern definitiv einfach nur die komplette Dynamik des Sensors. Aber Red kontrolliert das Raw-processing durch sein SDK und stellt so in jeder r3d-fähigen Anwendungen identisches Ausgangsmaterial zur Verfügung.
Und ja, das demosaicing steht sehr weit vorne im Prozess. Nicht gleich an erster Stelle, aber vor jeglicher (digitalen) Farbanpassung.
Ich meine: Es wird ein Lumawert pro Sensel/Pixel gespeichert. Alles andere wäre schwachsinnig, da, wenn einfach drei Werte gespeichert würden wir wieder bei ProRes wären. Das ist, als würde man behaupten DNGs seien JPEGs, nur weil man auch JPEGs in den Container speichern kann. Es gibt nicht viele wirklich feste Definitionen von raw, nur die, dass eben kein drei Werte (echtes RGB, oder eben durch chroma-subsampling datenreduziert), sondern nur ein Wert pro Pixel übertragen wird. Die Datenraten von PRR würden in RGB eine so hohe Kompression bedeuten, dass es völlig unsinnig wäre.Roland Schulz hat geschrieben: ↑Do 28 Jun, 2018 09:52Na ja, Teil 1 kennen wir nicht zu 100% was nun wirklich die "Monochrom-ProRes Daten" sind. Denke Du meinst noch reine Pixeldaten hinter dem CFA, also undebayerte Daten? Mag sein, vielleicht aber auch ein komprimiertes, debayertes Bild. Beides hebt Deine weiteren Theorien die ich sinnvoll sehe nicht aus, wobei normalerweise der WB nicht in den Sensordaten eingebacken wäre, das hier Aufgrund der kleineren Quantisierung aber durchaus Sinn machen würde (pre gain per channel) und sein kann. So hätte man aber nicht den vollen RAW Vorteil mehr sondern würde wie seinerzeit bei der Nikon D2x bereits ein "vorbewertetes" RAW Bild (WB ist grob vorgegeben) speichern.7nic hat geschrieben: ↑Do 28 Jun, 2018 09:01 Nein, PRR ist einfach nur ein Monochrom-ProRes mit ein paar Metadaten. Und im Zusammenspiel mit der EVA1 wird ein ISO-variantes System daraus. Selbst der Weißabgleich ist in den Sensordaten eingebacken. Meine Theorie ist, dass Panasonic das so handhabt, da sie ansonsten keinerlei Einfluss auf den Gain- und WB-Algorithmus haben. Meine andere Theorie besagt, dass dadurch nach der 10 bit log EVA1 raw-Ausgabe im 12 bit lin in PRR mehr relevante Werte für den definierten ISO- und WB-Bereich gespeichert werden können. Und meine dritte ist, dass Panasonic einfach prinzipiell mit analogem Gain (auch für Kanalspezifischen gain für WB) arbeiten will. Habe aber von Panasonic noch keine sinnvolle Antwort dazu bekommen.
Redraw speichert nicht nur höchstwahrscheinlich, sondern definitiv einfach nur die komplette Dynamik des Sensors. Aber Red kontrolliert das Raw-processing durch sein SDK und stellt so in jeder r3d-fähigen Anwendungen identisches Ausgangsmaterial zur Verfügung.
Und ja, das demosaicing steht sehr weit vorne im Prozess. Nicht gleich an erster Stelle, aber vor jeglicher (digitalen) Farbanpassung.
Der pre Gain muss aber nicht zwingend analog sein. Immerhin werden teilweise auch Gammakurven bereits mit eingebacken. Das kann analog erfolgen, es kann aber auch im DSP erfolgen. Unsere Baumarktcams kommen auch mit mindestens 10bit vom Sensor und schreiben nach WB, Gamma etc. 8bit Daten.
Ich gehe auch "höchstwahrscheinlich" davon aus dass REDRaw auch nach Kompression/Wavelet die komplette Sensordynamik speichert.
Da wir aber weder "in" die Kamera noch ins SDK gucken können bleibt da "definitiv" die Gefahr einer Grauzone ;-)!
Gut, glaube wir kommen etwas vom Kurs ab. Sony wird höchstwahrscheinlich mit pre gain und 12bit RAW ISO variant sein, RED ist mit 16bit ISO invariant.
Entweder ein Sensel geht full-well, dann ist das Bild überbelichtet, oder eben nicht, dann ist das Bild nicht überbelichtet. Wenn nicht alle drei Kanäle in der Gegend überbelichtet sind, kann das IPP2-processing die fehlenden Werte noch recht gut schätzen und du bekommst wahrscheinlich mit etwas Glück noch ein sinnvolles Bild zurückgeholt, diese zusätzliche (errechnete) Dynamik ist aber nur wirklich für den Rolloff in den Lichtern zu gebrauchen. In Gesichtern ist es recht einfach: Clipping heißt überbelichtet. Kein clipping heißt nicht überbelichtet. Die evozierte Raw-Magie ist einfach nur Unsinn. Die Faktoren auf die man beim Dreh achten muss sind einfach andere als bei 8bit Rec709.klusterdegenerierung hat geschrieben: ↑Do 28 Jun, 2018 10:05 Ja Jungs, dann mach ich einfach noch einen extra Hautton Thread auf und ihr könnt auch hier weiter über einen Anfänger aufregen.
Das schöne daran ist ja, das Profis nie Anfänger waren, Profis kommen schon als solche zur Welt!!
@7nic
Natürlich hast Du mit der Iso Invariant Nummer Recht, trotzdem liegt Du falsch, denn er hat ja beides gemacht,
auf der einen Seite den Iso Wert hochgedreht um dann die Invariants über den Iso Slider auf 320 zu zeigen und zusätzlich einmal den Isowert hochgedreht und dann eine Lampe voll drauf gehalten,
um damit die Invariants zu umgehen, denn an der Stelle hatte er dann 3200 plus überbelichtung durch externe Quelle.
Irgendwas "neues" muss denen aber eingefallen sein denn, ich glaube da waren wir schon, wäre die Performance schwer zu erklären. Alles gut, wir stochern etwas im Nebel.7nic hat geschrieben: ↑Do 28 Jun, 2018 10:07 Ich meine: Es wird ein Lumawert pro Sensel/Pixel gespeichert. Alles andere wäre schwachsinnig, da, wenn einfach drei Werte gespeichert würden wir wieder bei ProRes wären. Das ist, als würde man behaupten DNGs seien JPEGs, nur weil man auch JPEGs in den Container speichern kann. Es gibt nicht viele wirklich feste Definitionen von raw, nur die, dass eben kein drei Werte (echtes RGB, oder eben durch chroma-subsampling datenreduziert), sondern nur ein Wert pro Pixel übertragen wird. Die Datenraten von PRR würden in RGB eine so hohe Kompression bedeuten, dass es völlig unsinnig wäre.
Denke wir haben da dann eine "halbwegs" verlässliche Quelle ;-)! Nein, es wird so sein. Es gab genug statische DR Prüfungen zu den Cams und die haben alle sehr gute bis hervorragende Ergebnisse geliefert. Das geht "eins zu eins" durch...
Die Prämisse, man könne mit raw ausgebrannte Bereich irgendwie "zurückholen" ist schon falsch, und natürlich alles was aus der falschen Prämisse dann folgt.klusterdegenerierung hat geschrieben: ↑Do 28 Jun, 2018 10:05 ..und zusätzlich einmal den Isowert hochgedreht und dann eine Lampe voll drauf gehalten, um damit die Invariants zu umgehen,
denn an der Stelle hatte er dann 3200 plus überbelichtung durch externe Quelle.
Das würde mich wirklich beeindrucken, da Resolve das Material gar nicht lesen kann.
100%!!! Auch die "Reparatur" ist schwierig und begrenzt, aber ich denke das wolltest Du ausdrücken.Frank Glencairn hat geschrieben: ↑Do 28 Jun, 2018 10:29 Die Prämisse, man könne mit raw ausgebrannte Bereich irgendwie "zurückholen" ist schon falsch, und natürlich alles was aus der falschen Prämisse dann folgt.
Klar kann man einen einzelnen geclippten Kanal mit diversen Tricks halbwegs "reparieren", aber das ist ein Notnagel, und kein Workflow.
Es gibt die Möglichkeit in FCPX das Bild in ProRes 4444 log auszugeben und dann in Resolve zu graden. Und das funktioniert recht gut, ist eben nur unsinnig umständlich. Nur geht die "Raw-Magie" dann flöten, weil man im log-Bild sieht welche Werte aufgezeichnet wurden und diese nicht beim 'Mapping' für die Ausgabe verloren gingen.Frank Glencairn hat geschrieben: ↑Do 28 Jun, 2018 10:30Das würde mich wirklich beeindrucken, da Resolve das Material gar nicht lesen kann.
Jein. Wie ich oben schon geschrieben habe, geht es zum Teil schon geclippte Rohdaten wiederherzustellen, bzw. von einem Algorithmus schätzen zu lassen, wenn zumindest ein Kanal der umliegenden Sensel nicht überbelichtet ist. Das funktioniert zum Beispiel in überbelichteten Vorhängen, in Wolken usw. recht gut. Haut z.B. bekommst du aber fast gar nicht wieder hin.Roland Schulz hat geschrieben: ↑Do 28 Jun, 2018 10:35100%!!! Auch die "Reparatur" ist schwierig und begrenzt, aber ich denke das wolltest Du ausdrücken.Frank Glencairn hat geschrieben: ↑Do 28 Jun, 2018 10:29 Die Prämisse, man könne mit raw ausgebrannte Bereich irgendwie "zurückholen" ist schon falsch, und natürlich alles was aus der falschen Prämisse dann folgt.
Klar kann man einen einzelnen geclippten Kanal mit diversen Tricks halbwegs "reparieren", aber das ist ein Notnagel, und kein Workflow.
Man hat nur eine Chance wenn sich die auf die RAW Daten gelegte Gammakurve / das Processing noch "innerhalb" der RAW Daten Dynamik bewegt und noch "Luft" ist, also Wertebereiche an den "Enden" noch ungenutzt sind. Die kann man dann durch Korrektur im Post noch ansteuern und nutzen.
Geclippte RAW Daten sind geclippte Bilddaten, da ist keine Information mehr reproduzierbar!
...ebenfalls Jein ;-). Denke pauschal kann man das kaum beantworten. Gerade in Wolken (weiß) wären je nach CFA ja alle Kanäle tendenziell geclippt, bei Hautfarbe eher rot.7nic hat geschrieben: ↑Do 28 Jun, 2018 10:46 Jein. Wie ich oben schon geschrieben habe, geht es zum Teil schon geclippte Rohdaten wiederherzustellen, bzw. von einem Algorithmus schätzen zu lassen, wenn zumindest ein Kanal der umliegenden Sensel nicht überbelichtet ist. Das funktioniert zum Beispiel in überbelichteten Vorhängen, in Wolken usw. recht gut. Haut z.B. bekommst du aber fast gar nicht wieder hin.
Es geht darum, dass Wolken, Vorhänge oder sonstige Bildinhalte, die meist in den Highlights zu finden sind mehr Spielraum für die farbliche Ungenauigkeit der Methode zulassen. Wie genau die Wolke aussah, ist für den Zuschauer irrelevant, so lange sie im finalen Bild nach Wolke mit etwas Zeichnung aussieht. Wenn in Hauttönen Nuancen fehlen oder die Verläufe auch nur minimal irgendwie unecht wirken, fällt das sofort auf. Selbst wenn nur ein einziger Kanal clippt, ist das meistens der Fall. Bei Red-Sensoren verlierst du am Himmel (auch in den Wolken) verlierst meist den Grünkanal eine halbe bis ganze Blende vor rot, kurz danach erst blau. Und diesen Spielraum von bis zu einer Blende kannst du durchaus nutzen.Roland Schulz hat geschrieben: ↑Do 28 Jun, 2018 10:59...ebenfalls Jein ;-). Denke pauschal kann man das kaum beantworten. Gerade in Wolken (weiß) wären je nach CFA ja alle Kanäle tendenziell geclippt, bei Hautfarbe eher rot.7nic hat geschrieben: ↑Do 28 Jun, 2018 10:46 Jein. Wie ich oben schon geschrieben habe, geht es zum Teil schon geclippte Rohdaten wiederherzustellen, bzw. von einem Algorithmus schätzen zu lassen, wenn zumindest ein Kanal der umliegenden Sensel nicht überbelichtet ist. Das funktioniert zum Beispiel in überbelichteten Vorhängen, in Wolken usw. recht gut. Haut z.B. bekommst du aber fast gar nicht wieder hin.
Sagen wir so, es fällt in Wolken durch die überwiegende Gleichmäßigkeit weniger auf wenn man Überbelichtetes/Geclipptes nach Grau verschiebt als in der Haut, die meist von Rot dominiert wird.
Bei der Haut oder generell farbigen Elementen besteht aber eine größere Wahrscheinlichkeit dass benachbarte Kanäle nicht geclippt sind, von daher gehe ich die Annahme nicht unbedingt mit.