Infoseite // Weitere Prores RAW Parameter in Assimilate Scratch einstellbar

Newsmeldung von slashCAM:



Das Prores RAW Format wird indirekt - über eine extrerne Aufnahme mit Atomos Rekordern - von immer mehr Kameras unterstützt. Jüngst kam Z-Cam als Kamerahersteller hinzu, ...



Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Weitere Prores RAW Parameter in Assimilate Scratch einstellbar



Antwort von R S K:

Unsinn. Kann gar nicht sein, wo wir doch wissen, dass PRRAW wegen dieser fehlenden Parameter kein echtes RAW ist!

😏



Antwort von pillepalle:

Gibt jetzt auch ein Video von Assimilate zum Thema. Nix sonderlich neues, aber wohl die einzigen die bisher alle Kameras unterstützen. In meinen Augen bisher die beste Software für ProRes RAW. Ob ich die miete weiss ich noch nicht. Neunzig Euro im Monat sind schon heftig. Vielleicht tut sich bis Ende Oktober bei dem ein oder anderen Software-Hersteller ja auch noch was.

https://www.youtube.com/watch?v=ji4kawGriJw

VG



Antwort von R S K:

pillepalle hat geschrieben:
aber wohl die einzigen die bisher alle Kameras unterstützen. 🤨??
Entweder unterstützt man PRRAW und damit auch alle Kameras oder man unterstützt es nicht. Es gibt kein entweder oder. Es gibt nur eine SDK.

Ob die verschiedenen OEMs sich schon die Mühe gemacht haben die neuen Parameter in Form von Slider, Pop-up, whatever zu implementieren ist eine andere Sache. Am Ende sind das aber auch Dinge die man SOWIESO schon einstellen kann und konnte! Keine Ahnung warum so viele irgendwelche lustigen Pop-ups scheinbar für eine „Echtheits-Zertifizierung” verstehen wollen/müssen. 🙄

- RK



Antwort von pillepalle:

Es geht nicht um die Zertifizierung, sondern um das Handling. Es ist viel einfacher die Farbkorrektur und die Belichtung mit den entsprechenden Slidern zu verändern als über drei Ecken mit anderen Parametern herum zu hampeln. Die Slider für ISO, WB und Tint gibt es in RAW Konvertern nicht ohne Grund, sondern weil sie sich bewährt haben ;)

VG



Antwort von R S K:

Die Slider für ISO, WB und Tint gibt es in RAW Konvertern nicht ohne Grund, sondern weil sie sich bewährt haben
Ich wiederum habe noch nie alles so gelassen wie es nach dem umstellen von irgendwelchen Pop-ups war. Da habe ich es irgendwann einfach von vornherein gelassen und alles „zu Fuß” (über bestenfalls EINE „Ecke” herum, da ich FCP benutze) korrigiert. Habe halt nicht verstanden was ich von den offensichtlich unnützen Redundanzen habe.

Wobei ich dessen Funktionalität oder Nutzen gar nicht in Frage gestellt habe. Wer es nutzen möchte, soll es tun. Nur zu! Mir ging es vielmehr darum, dass manche Dinge wie „Jetzt kann es sich endlich als Standard etablieren!” schreiben, wo sich vom Grundsatz her, also Qualität, Möglichkeiten etc., überhaupt gar nichts an PRRAW geändert hat.

- RK



Antwort von cantsin:

pillepalle hat geschrieben:
Die Slider für ISO, WB und Tint gibt es in RAW Konvertern nicht ohne Grund, sondern weil sie sich bewährt haben ;) Vor allem, weil sie auf die Bilddaten vor dem Debayering angewandt werden. Das Verschieben des Weißabgleich ist dann eine einfache Frage der Gewichtung (bzw. der Werteerhöhung oder -verminderung) der Rot+Grün-Pixel ggü. den Blaupixeln des Sensors, Tint eine einfache Gewichtung der Grün-Pixel ggü. den Blau+Rot-Pixeln, und ISO/Gain eine einfache Frage der Erhöhung bzw. Absenkung aller Sensel-Werte.

Wenn man diese Operationen erst nach dem Debayering macht, arbeitet man auf der Basis von interpolierten Daten und daher mit schlechteren Resultaten. (Und verschenkt einen der Hauptvorteile von RAW.)



Antwort von Jott:

fcp de-debayert live in der Timeline. Ist das der Grund der Verwirrungen?



Antwort von R S K:

cantsin hat geschrieben:
Wenn man diese Operationen erst nach dem Debayering macht, arbeitet man auf der Basis von interpolierten Daten und daher mit schlechteren Resultaten. (Und verschenkt einen der Hauptvorteile von RAW.) Du meinst also wenn ich dir ein Bild zeige, welches ich einmal so und einmal so bearbeitet habe, dass du mir sagen kannst welches welches ist? Natürlich nicht.

- RK






Antwort von mash_gh4:

cantsin hat geschrieben:
Vor allem, weil sie auf die Bilddaten vor dem Debayering angewandt werden. Das Verschieben des Weißabgleich ist dann eine einfache Frage der Gewichtung (bzw. der Werteerhöhung oder -verminderung) der Rot+Grün-Pixel ggü. den Blaupixeln des Sensors, Tint eine einfache Gewichtung der Grün-Pixel ggü. den Blau+Rot-Pixeln, und ISO/Gain eine einfache Frage der Erhöhung bzw. Absenkung aller Sensel-Werte.

Wenn man diese Operationen erst nach dem Debayering macht, arbeitet man auf der Basis von interpolierten Daten und daher mit schlechteren Resultaten. (Und verschenkt einen der Hauptvorteile von RAW.) die realisierung des weißabgleichs wird zwar in der praxis tatsäch in dieser höchst vereinfachten form von den meisten kameras umgesetzt, was aber bei genauer betrachtung zu eher unbefriedigenden resultaten führt (siehe: https://en.wikipedia.org/wiki/Color_bal ... or_balance od. https://web.stanford.edu/~sujason/Color ... ation.html).

dazu kommt noch das problem, dass ja die verschiedenfarbigen sensel die rezipierten grundfarben nicht ganz sauber trennen, sondern oft relativ eigenwillige spektrale sensibilitäskennlinen aufweisen. derartiges zu kompensieren ist viel wichtiger, wenn man RAW-daten zufreidenstellend aufbereiten will. in er praxis wird aber auch diese korrektur in der regel erst nach dem debayern durchgeführt, obwohl es dadurch natürlich an sehr scharfen farbübergängen mit den von dir beschrieben begleiterscheineungen behaftet ist -- was aber realistischer weise auch niemand wahrnehmen dürfte.

viel bedeutsamer sind in diesem zusammenhang vermutlich die fixed pattern und noise-kalibrierungs-erfordernisse, die in einem solchen zusammenspiels verschiedener korrektureingriffe auch nicht unbedingt einfacher werden. am optimalsten sind hier bekanntlich ansätzte, die mehre arbeitschritte in einem komplex bzw. rechenschritt zusammenfassen, statt sie hintereinader abzuarbeiten, um die entsprechenden wechselwirkungen mitzuberücksichtigen, was heute gestützt auf ML-techniken oft ganz gut realisiert werden kann.

weißabgleich, tint u.ä. kann man dann immer noch realtiv einfach später ausreichend sauber korrigieren, solange man sich dazu in dert linearen farb- bzw. helligkeitsdarstellung bewegt -- also nicht rec709 od.ä.



Antwort von cantsin:

"R S K" hat geschrieben:
cantsin hat geschrieben:
Wenn man diese Operationen erst nach dem Debayering macht, arbeitet man auf der Basis von interpolierten Daten und daher mit schlechteren Resultaten. (Und verschenkt einen der Hauptvorteile von RAW.) Du meinst also wenn ich dir ein Bild zeige, welches ich einmal so und einmal so bearbeitet habe, dass du mir sagen kannst welches welches ist? Natürlich nicht.

Mal abgesehen davon, dass zumindest FCP die Korrektur gar nicht erst VOR dem debayering anwendet, aber nu… mag wohl bei anderen anders sein. 🤷🏼??? Hier mal eine Challenge:

Ein mit der Sigma fp als CinemaDNG 12bit aufgenommener Color Chart, wobei der Weißabgleich der Kamera 'falsch' auf 2500K und der Tint auf maximal Grün gedreht war. (Bei CinemaDNG/der Sigma fp eine reine Metadaten-Einstellung.)

Dieses Material mit dem Kamera-Weißabgleich in Resolve importiert und einmal als DNxHR 12bit 4:4:4 exportiert und einmal (in noch höherer Farbtiefe) als 16bit-TIFF:
white balance as shot.png
Der Weißabgleich des CinemaDNG-Materials ließ sich in Resolve mit zwei Reglern im "RAW"-Tab korrigieren: WB von 2456 auf 4670 und Tint auf von -14.71 auf 0.
white balance corrected.png
Wenn ich das DNxHR 4:4:4-Material sowie das 16bit-TIFF in Resolve reimportiere und die Farbtemperatur- und Tint-Korrekturregler im normalen Farbkorrekturmodul (also Tab 2 in der "Color Wheels"-Arbeitsfläche) anwende, komme ich beim besten Willen nicht auf das obige Resultat, sondern erhalte ein Bild mit diversen Farbstichen, verschobenem Gamma und anderer Farbsättigung, die weitere Korrekturen erfordern:
white balance tiff corrected_1.3.1.png
Wäre mal neugierig, ob das in FCPX anders ist.

Die Dateien gibt's hier zum runterladen:
http://data.pleintekst.nl/wb_challenge.zip



Antwort von R S K:

Nur dass es hier um PRRAW geht und nicht cDNG oder DNxHD. 🤷🏼???

- RK



Antwort von cantsin:

"R S K" hat geschrieben:
Nur dass es hier um PRRAW geht und nicht cDNG oder DNxHD. 🤷🏼??? Das ist doch völlig egal, ProRes RAW und CinemaDNG sind nur zwei verschiedene Verpackungen derselben Daten.

Und der DNxHR/16bit-TIFF-Export demonstriert nur, wie sich Weißabgleich-Korrektur auf bereits debayerte Daten (bzw. interpolierte Farben) im Unterschied zur Weißabgleich-Korrektur auf nicht debayerte Daten auswirkt.



Antwort von R S K:

cantsin hat geschrieben:
Das ist doch völlig egal, ProRes RAW und CinemaDNG sind nur zwei verschiedene Verpackungen derselben Daten. Nein, eben nicht, sorry. Da es für beide in FCP nicht die Optionen gibt von denen wir hier reden? Was für mich persönlich auch völlig ok ist, da ich nie auf die Idee käme das eine noch das andere (nativ) zu verwenden.

- RK



Antwort von pillepalle:

Verstehe ehrlich gesagt auch nicht mehr warum ihr hier diskutiert. Man braucht doch nicht wieder bei den Vorteilen von RAW ggü. bereits debayertem Material anfangen. In dem Originalpost ging es doch nur darum das Scratch als erste (und für einige Kamerahersteller immer noch einzige Software) direkten Zugriff auf bestimmte RAW Parameter bietet (wie WB, ISO oder Tint). Das macht das arbeiten mit RAW Formaten schlicht weg bedeutend einfacher, um so mehr wenn es erstmal nur darum geht das Material vorab zu Normalisieren ohne gleich einen bestimmten Look drauf knallen zu wollen. Vielleicht bieten das die anderen Hersteller ja auch irgendwann mal, aber im Moment ist der Workflow mit ProRes RAW in vielen Programmen noch recht rudimentär.

VG



Antwort von cantsin:

pillepalle hat geschrieben:
Verstehe ehrlich gesagt auch nicht mehr warum ihr hier diskutiert. Man braucht doch nicht wieder bei den Vorteilen von RAW ggü. bereits debayertem Material anfangen. In dem Originalpost ging es doch nur darum das Scratch als erste (und für einige Kamerahersteller immer noch einzige Software) direkten Zugriff auf bestimmte RAW Parameter bietet (wie WB, ISO oder Tint). Es ging um das ursprüngliche Argument, dass es angeblich keinen Unterschied macht (bzw. eine unnötige Verdoppelung des User-Interfaces ist), ob man diese Parameter als RAW-Parameter einstellt oder in der normalen Farbkorrektur.

Mein Beispiel zeigt, dass es da im Resultat sehr wohl Unterschiede gibt. - EDIT: Ich habe das übrigens auch als Praxis-Experiment für mich selbst gemacht; die Unterschiede fielen tatsächlich noch größer aus, als ich erwartet hatte.



Antwort von R S K:

pillepalle hat geschrieben:
Man braucht doch nicht wieder bei den Vorteilen von RAW ggü. bereits debayertem Material anfangen. Worum es schon lange auch nicht mehr geht (oder hier je ging?). Aber schon ironisch, dass du gleich daraufhin das ansprichst worum es tatsächlich geht. 😄

pillepalle hat geschrieben:
Vielleicht bieten das die anderen Hersteller ja auch irgendwann mal, aber im Moment ist der Workflow mit ProRes RAW in vielen Programmen noch recht rudimentär. Was natürlich Unsinn ist, da jeder der die offizielle ProRes SDK nutzt auch die gleiche Funktionalität bekommt. Wie eben FCP, wo die Liste von oben kaum "rudimentär" suggeriert, sondern bestenfalls, dass bestimmte OEMs eben noch ihre Hausaufgaben machen müssen. ZCam z.B. wird einfach mal (sinnvollerweise) die alte SDK ignoriert haben, wenn sie es überhaupt je hatten.

Wenn Assimilate darüber hinaus irgendwelche faux Slider oder Pop-ups einbaut die die evtl. bei manchen Kameras bis jetzt fehlende simuliert, wo es die Metadaten gar nicht gibt, super. Am Ende sind sie so oder so nichts anderes als simple Werte-Presets die bestimmte (von den von den Metadaten vorgegebene Werte ausgegangen) nach einem voreingestellten Schema umstellen. Hurra. Keine Raketenwissenschaft und auch nichts was man nicht auch ohne hinbekäme.

Und ob ich die erst benutze und dann eine Korrektur drauflege für das Finetuning oder gleich nur eine Korrektur nehme… 🤷🏼??? Kann ja jeder machen wie er für richtig hält.

cantsin hat geschrieben:
Mein Beispiel zeigt, dass es da im Resultat sehr wohl Unterschiede gibt. Ja. Bei den Formaten.

- RK



Antwort von cantsin:

"R S K" hat geschrieben:
cantsin hat geschrieben:
Mein Beispiel zeigt, dass es da im Resultat sehr wohl Unterschiede gibt. Ja. Bei den Formaten. Darum hier noch einmal eine Wiederholung des Experiments, diesmal nur mit dem DNG-Material.

WB- und Tint-Korrektur des DNG-Materials im Raw-Tab: 1.1_1.1.1.png
WB- und Tint-Korrektur per normaler Farbkorrektur in Resolve ("Temperature" und "Tint"-Regler im "Color"-Modul): 1.2_1.2.1.png

Gleiche Chose - bzw. ungleiches Ergebnis.

EDIT: Im zweiten Fall kann ich's auch prima im Waveform-Monitor sehen - ich muss da auch bei bestem Feintuning von "Temperature" und "Tint" noch zusätzliche Lift-, Gamma- und Gain-Korrekturen machen, nur um die Farbstiche aus den monochromen Patches rauszukriegen - und dann stimmen übrigens Farben immer noch nicht.






Antwort von pillepalle:

Offensichtlich bietet FCP nicht die gleiche Funktionalität wie Scratch, denn z.B. für eine Nikon Kamera, kann ich diese Parameter nicht direkt einstellen. Das sind auch nicht alles faux Werte, wie Du es nennst, denn die ISO Werte werden z.B. richtig eingestellt. Ich weiß dass Du ein großer FCP Fan bist, aber muss auch mal zugeben können wo die eigene Software Defizite hat. Sie unterstützt den direkten Zugriff auf diese Parameter eben nicht für alle Hersteller, obwohl sie das könnte. Egal ob die 'richtigen' Werte nun angezeigt werden, oder nicht. Denn würdest Du die Farbtemperatur wirklich mal nachmessen, würdest Du auch feststellen wie ungenau die gespeicherten Kameraparameter diesbezüglich in Wirklichkeit sind. Also ohnehin nur eine grobe Orientierung.

VG



Antwort von R S K:

pillepalle hat geschrieben:
Offensichtlich bietet FCP nicht die gleiche Funktionalität wie Scratch, denn z.B. für eine Nikon Kamera, kann ich diese Parameter nicht direkt einstellen. Ach wirklich? Na WENN es denn tatsächlich so ist, dann: Offensichtlich halten sich Assimilate nicht an den SDK Vorgaben und kochen ihr eigenes Süppchen. Rate mal was mir lieber ist?

pillepalle hat geschrieben:
Ich weiß dass Du ein großer FCP Fan bist, aber muss auch mal zugeben können wo die eigene Software Defizite hat. Sie unterstützt den direkten Zugriff auf diese Parameter eben nicht für alle Hersteller, obwohl sie das könnte. 😄… aber natürlich. Apple kennt sich nicht genug mit dem Format aus und hatte keine Kopie des SDKs mehr! Haben die doch voll was übersehen. Mist.

https://support.apple.com/en-us/HT211277

Alles andere ist faux, weil nicht SDK konform, ob du es glauben möchtest oder nicht, sorry: Fakt.

Aber… wer sagt denn überhaupt, dass sie mehr Kameras bzw. Zugriff auf mehr Parameter haben, so wie du suggerierst? Du? Denn ich sehe nirgends einen Hinweis darauf, dass sie bei Nikon irgendwas mehr können. Weder hier noch auf deren Sewite. Link? Ah… oder doch nur wilde Spekulation und Wunschdenken um es „den doofen Apple-Jüngern zu zeigen”?

Danke jedenfalls, dass du noch beschreibst wie Assimilate es hinbiegen (und auch hier wieder: ein großes WENN). Also in dem Fall wie Apple es auch hätte hinbiegen können, aber sich halt nicht mit „Kludges” abgibt. Denn dann hätten sie z.B. auch für altes Material was reinfaken können, wie z.B. für das EVA1 Material was ich habe, wo ja auch sämtliche Metadaten fehlen und dementsprechend (und völlig korrekt) gar nichts angeboten wird, weil zu alt. Eben im Gegensatz zu neuem EVA1 Material.

Ach ja. Hat alles nur was damit zu tun, dass ich so „ein großer FCP Fan” bin (z.D. „Fanboy!!1!”), wie du so wunderbar typisch ad hominem erklärst. Demnach kann ich also durch reine Willenskraft die Realität verbiegen? Cool! 😄

WENN: Dann auch viel Glück mit alten Assimilate Projekten, sobald die Metadaten offiziell nachgepflegt und genutzt werden können. Hoffen wir mal, dass die gut geraten haben, sonst wird's echt lustig! Denn, so leid es mir tut, das sind nicht nur Daten „zur groben Orientierung”. Keine Ahnung wie du auf so ein Blödsinn kommst. Ach so, dann ist RAW in welcher Form auch immer einfach nur alles Schall und Rauch. Verstehe.

Kannst aber gerne mal erzählen wie du diese verräterischen Messungen anstellst mit dem man das nachweisen kann. Da wäre ich doch sehr interessiert.

Aber unterm Strich: ich kann mir auch nur sehr schwer vorstellen, dass Apple das ganze in der Form abgesegnet hat oder absegnen würde. Aber klar. Assimilate ist ja so FETT im Business, dass die sich einfach mal locker 'n „fuck you!” an Apple leisten können was die Entwickler Richtlinien angehen, oder?

Also: woher hast du dieses „FCP kann nicht so viel wie Scratch! Bätsch!” Ding? Hm?

Und wenn es stimmen sollte, dann kann ich nur annehmen, dass Assimilate ziemlich verzeifelt auf der Suche nach jedem noch so kleinen Alleinstellungsmerkmal ist, zwecks PR, angesichts der offensichtlichen, harten Konkurrenz, die immer noch rumschmollt was PRRAW angeht. 🙄 So sehr, dass sie sogar gegen Apple gehen würden. (ich denke wir wissen wie wahrscheinlich das ist)

Deine oh-so-kühne Behauptung kannst du demnach also ganz sicher belegen, gell? Oder ziehst du dir das doch nur wieder aus…?

- RK



Antwort von pillepalle:

@ R S K

Verstehe wirklich nicht warum Du Dich hier so zum Pinsel machen musst, weil jemand Deine Lieblingssoftware kritisiert. Ist eigentlich relativ einfach zu verstehen was ich geschrieben habe und das sind auch keine Vermutungen sondern praktische Erfahrungen ;)

Es können auch nur die Metadaten die von der Kamera geliefert werden von der Software interpretiert werden. Wenn also z.B. schon die Farbtemperaturangabe der Kamera nicht genau ist, kann sie die Software auch nicht richtig rücken. Nimm einfach mal drei Kameras verschiedener Hersteller, mache eine WB unter identischen Bedingungen und vergleiche die Angaben zur WB untereinander. Da wird die jede Kamera andere Werte anzeigen. Welcher ist nun wohl der richtige? Deshalb sind die Werte auch nur als grobe Orientierungen zu sehen. Das gleiche gilt für die ISO Angaben. Da zeigt Dir die Kamera vielleicht ISO 100 an, in Wirklichkeit sind es aber ISO 90 oder 110. Die Genauigkeit die Dir die Zahlen vorgaukeln haben nicht unbedingt etwas mit der Realität zu tun.

Von mir aus kannst Du gerne weiterhin den Apple Jünger spielen. Ist mir egal, aber mit so sinnfreien Post wie Deinem letzten, fällt es echt schwer Dich ernst zu nehmen.

VG



Antwort von R S K:

pillepalle hat geschrieben:
Verstehe wirklich nicht warum Du Dich hier so zum Pinsel machen musst, weil jemand Deine Lieblingssoftware kritisiert. 😂

Z.D.: "Ich habe nichts an Substanz oder Fakten, nur Unterstellungen und wilde Spekulation. Also zur Ablenkung: klassisches ad hominem ,Jünger'-Gequatsche vom feinsten."

Wir warten dann noch auf den Link. Lass dir Zeit. ??

pillepalle hat geschrieben:
fällt es echt schwer Dich ernst zu nehmen. Wo mir im Leben nichts wichtiger ist… 😢

- RK



Antwort von pillepalle:

@ R S K

Von was für einem Link redest Du? Mir fällt es offen gestanden schwer Deinen wirren Gedankengängen zu folgen. Lad Dir einfach Scratch herunter, nimm eine ProRes RAW Datei von Nikon und Du wirst feststellen, dass Du dort eine direkte Kontrolle über die Parameter WB, ISO und Tint hast. Etwas das Du in FCP vergeblich suchen wirst. Ist ganz einfach und real.
VG



Antwort von R S K:

Na dann: Screenshot reicht auch wo man Nikon und RAW Parameter sieht. Ich bin ja nicht hier um deine Behauptungen zu untermauern. Wenn es bei dir alles soweit flutscht wie beschrieben, sollte das ja ein leichtes sein! Oder etwa nicht?

- RK



Antwort von pillepalle:

Reicht Dir das?


zum Bild


VG



Antwort von R S K:

Den oder sonst irgendeinen Clip kannst du sicherlich irgendwo hochladen, gell? Dass man sich das mal „in echt” anschauen kann? Und das soll von welcher Kamera sein?

- RK



Antwort von pillepalle:

Das ist von einer Nikon Kamera die über einen Ninja V aufgenommen wurde (steht übrigens auch in klein neben auf dem Screenshot). Geht aber bei Scratch mit allen neuen Kameras, das ist ja das schöne. Wogegen FCP die Parameter nur bei einigen Herstellern (wie z.B. ZCam) direkt zugänglich macht.

Ich kann Dir auch die ProRes RAW Datei hochladen, allerdings weiß ich nicht was Du daran sehen möchtest? Du kannst auch die ProRes RAW Datei eines anderen Herstellers verwenden um das auszuprobieren.

VG






Antwort von R S K:

Ich habe schon, wie mehrfach gesagt, diverses anderes Material wo ich genau sehen kann was und was nicht „supportet” wird. Habe ich auch ausgiebig in meinem Video gezeigt. Nur von NIKON, wo im Gegensatz zu fast allen anderen angeblich gar nichts supportet wird, habe ich nichts und habe auch keinen Zugang dazu.

- RK



Antwort von pillepalle:

Also wenn Du magst und mir Deine E-Mail Adresse gibst, schicke ich Dir gleich mal einen kurzen ProRes RAW Clip vom selben Motiv per WeTransfer. Das Original aus dem Beispiel ist mir mit 3,5 GB zu groß um es mal eben zu versenden.

VG



Antwort von R S K:

Wenn du nichts kleineres hast… PN ist geschickt.

- RK



Antwort von Axel:

@pillepalle
Mich stört, dass du schreibst "Original 3200°K", dass aber darunter in Scratch steht "Kelvin 5600.00", was du auf "15000.00" änderst. Wenn ich dieses Bild in FCP laden würde, könnte ich es relativ einfach mit normalen Werkzeugen korrigieren, hätte aber ebenfalls keinen Anhaltspunkt, was bei der Aufnahme eingestellt war und wie ich gegensteuern muss.
Darüber hinaus: eine Änderung von ISO oder Kelvin in einem echten Raw-Modul sieht völlig anders aus als das (Stelle getimet):
https://youtu.be/I0mGdqMuPF0?t=115
... nämlich so (Stelle getimet):
https://youtu.be/0j7zNEoc8tg?t=580



Antwort von pillepalle:

@ Axel

Was sieht denn an dem RAW Modul anders aus bei mir?? Die ISO Werte sind ja richtig und Tint ist ohnehin ein Phantasie-Wert. Das was nicht stimmt ist die Kelvin Angabe. Möglicherweise weil der Ninja sie nicht in die Metadaten speichert, oder Nikon sie nicht überträgt. In der Kamera werden sie ja richtig angezeigt.

Die Werte spielen aber insofern keine wichtige Rolle, weil ich mich ohnehin nicht nach den Werten richte, wenn ich unterschiedliche Bilder aneinander angleiche, sondern danach, ob der Bildeindruck der gleiche ist. Wenn man z.B. eine Graukarte mit filmt, kann man sich bei verschiedenen Clips auch daran für den Weißpiunkt orientieren. Das ist aber nicht zwingend notwendig.

Der Vorteil des WB und Tint Reglers ist einfach der, das man den Weißpunkt sehr einfach mit zwei Reglern korrigieren kann, was über die anderen Optionen die man in der Farbkorrektur von NLEs hat normalerweise nicht so elegant geht. Wie gesagt, ich habe für das Beispiel je extra einmal mit der WB voll daneben gehauen, um zu sehen ob man es über die Regler wieder genau so hin bekommt, wie eine Aufnahme die mit korrekter WB aufgenommen wurde. Das kriegt man normalerweise nur mit Material hin das noch nicht debayert wurde.

VG



Antwort von R S K:

Axel hat geschrieben:
Darüber hinaus: eine Änderung von ISO oder Kelvin in einem echten Raw-Modul sieht völlig anders aus als das (Stelle getimet) Interessant. 🤔

U.a. das lässt mich nämlich vermuten, dass Assimilate tatsächlich nichts anderes machen als die Parameter da reinzustecken, aber in Wirklichkeit passiert gar nichts davon tatsächlich AUF RAW EBENE, ergo vor dem debayering. Sondern es sind nur stinknormale levels, hue, tint etc. Änderungen (a lá Color Wheels) die einfach als ISO und color temp getarnt sind, wie ich schon vermutet habe (was Apple nie machen würde).

Ich tippe also: ich habe recht. Nix RAW Parameter wo es gar keine Metadaten gibt = Kludge. Und wenn: ganz schön gefährliches Spielchen sollten sie irgendwann tatsächlich nachgeliefert und implementiert werden!



EDIT: habe es mir nun bestätigen lassen: Assimilate kochen tatsächlich ihr eigenes Süppchen und es ist genau wie oben beschrieben! Während FCP sich streng an tatsächliche Metadatenwerte hält, insofern sie vorliegen und weshalb (noch) nicht alle Kameras unterstützt werden, hat Assimilate offensichtlich einfach irgendwelche generischen Kontrollelemente eingebaut und auch für die Kameras die diese Werte gar nicht liefern können (Nikon) einfach ISO, WB etc. drangeschrieben. Na super. Viel Glück damit. Das erklärt auch wie sie schon vor einem Monat ein Video über "Whitebalance" bei PRRAW machen konnten. Das ganze ist also für die gar nicht neu.

Was im übrigen auch die Diskrepanz bei der manuellen Korrektur im Vergleich erklärt. Da sieht man gleich mal was man von solchen Alleingängen hat. 👍🏼
pillepalle hat geschrieben:
Wie gesagt, ich habe für das Beispiel je extra einmal mit der WB voll daneben gehauen, um zu sehen ob man es über die Regler wieder genau so hin bekommt, wie eine Aufnahme die mit korrekter WB aufgenommen wurde. Das kriegt man normalerweise nur mit Material hin das noch nicht debayert wurde. Was hier ganz klar nicht der Fall ist bzw. sein kann.

- RK



Antwort von pillepalle:

"R S K" hat geschrieben:
pillepalle hat geschrieben:
Wie gesagt, ich habe für das Beispiel je extra einmal mit der WB voll daneben gehauen, um zu sehen ob man es über die Regler wieder genau so hin bekommt, wie eine Aufnahme die mit korrekter WB aufgenommen wurde. Das kriegt man normalerweise nur mit Material hin das noch nicht debayert wurde. Was hier ganz klar nicht der Fall ist bzw. sein kann.
Wieso kann das nicht sein? Es funktioniert doch offensichtlich. Außerdem verstehe ich auch nicht wie Du darauf kommst, das das Material in Assimilate schon debayert ist? Das wird es erst, wenn Du es in irgend einem anderem Format ausgibst. Ist bei allen RAW Konvertern so. Keine Ahnung was Du für ein Problem damit hast. Deine Aussagen stützen sich jedenfalls nur auf Vermutungen, meine auf praktische Erfahrungen. Kann sich ja selber ein Urteil drüber bilden, oder es einfach ausprobieren.

VG

PS: Hatte Dir übrigens gestern Abend nochmal die Files geschickt.



Antwort von R S K:

pillepalle hat geschrieben:
… das das Material in Assimilate schon debayert ist? Das wird es erst, wenn Du es in irgend einem anderem Format ausgibst. Was für ein Unsinn. Du könntest überhaupt kein Bild sehen wenn es NICHT (in Echtzeit, wie in FCP auch) debayert werden würde, sondern würdest nur EIN BAYER PATTERN sehen. Das Wort… DE-BAYER… ja? 🙄

ProRes RAW directly encodes the Bayer pattern image. Demosaicing and processing are deferred to the time of playback and are performed by application software.
Und hast du die Metadaten nicht, dann kannst du keine (sinnvollen) Änderung auf RAW Ebene machen, Punkt. Und wie genau meinst du sollen sie z.B. Farbänderungen anwenden können VOR dem debayering, wo es noch keine keine Farbinformation als Referenz geben kann? Ich denke die RAW Slider etc. arbeiten eben anders, wie du selbst schon gesagt hast und sind dadurch doch so viel besser!

Sonst darfst du mir gerne deren SINN erklären und sagen warum sonst kein Format/Codec so etwas anbietet? Warum es als "RAW-only" Feature verstanden wird.

pillepalle hat geschrieben:
Deine Aussagen stützen sich jedenfalls nur auf Vermutungen 😄
Nee, sorry. Die Infos kommen direkt von "Entwicklerebene". Nix mit Vermutungen. Ich sehe jedenfalls nicht, dass du eine bessere hast. Ironischerweise, wenn denn einer hier auf Vermutungen reduziert ist, dann offensichtlich du.

Scratch ist also auf das RATEN reduziert, mangels irgendwelcher echten Daten von der Kamera und wendet die Änderung, wie schon erklärt, wie ein Color-Wheel an, nur unter anderem Namen. Und wenn es die Daten gibt, kann FCP sie haargenau so nutzen. Die Aussage "Scratch kann mehr als Apples eigene Software" ist demnach völlig unsinnig und reines Wunschdenken. Jedenfalls nichts was ich mir wünschen würde bzw. nicht sowieso auch schon kann, wie mit jedem anderen Clip auch, nur ohne falsche Tatsachen vorgegaukelt zu bekommen.

Wen das aber ersteres nicht stört, bitteschön. 🤷🏼???

Deine Datei habe ich übrigens nie erhalten. Ist auch nicht mehr nötig, danke. Die Sachlage ist auch ohne klar.

Ergo: Ich weiß dass Du ein großer Scratch Fan bist, aber du musst auch mal zugeben können wo die eigene Software Defizite hat. Sie faked halt den direkten Zugriff auf diese Parameter für alle Hersteller, obwohl es sie gar nicht hat.

😏

Genug der kreisförmigen Diskussion. Bin raus.



Antwort von pillepalle:

Haha... wie Du darauf kommst das ich ein großer Scratch Fan bin musst Du mir mal erklären ;)

Ich nutze das Programm nur, weil ich darin die ProRes RAW Dateien so einfach wie in keinem anderen Programm normalisieren kann, bei Bedarf noch die richtigen Audiospuren Syncen, oder Proxies erstellen kann und die Dateien dann als ProRes 4444 für die weitere Bearbeitung in Resolve ausgeben kann. Wenn Resolve das könnte, würde ich Scratch gar nicht benutzen. Davor habe ich das mit Premiere gemacht, weil ich privat mit einem PC unterwegs bin.

Das einzige was Du nicht verstehen kannst, das die Schnarchnasen der anderen Software-Unternehmen dieses Feature noch nicht bieten. Vielleicht kommt das ja irgend wann mal. Bisher aber jedenfalls noch nicht.

Und das Du nicht mal verstehst wie ein RAW Konverter arbeitet und das Bild nur für die Ansicht debayert wird und nicht die Originaldaten, zeigt auch wie wenig Du von der Ganzen Sache überhaupt verstehst. RAW Daten selber lassen sich überhaupt nicht verändern ;) Es lassen sich nur Veränderungen daran vor nehmen, wenn man die Dateien danach in einem anderen Format (eben einem debayertem) wieder speichert.

Lass es einfach gut sein. Ich glaube bei Dir ist Hopfen und Malz verloren.

VG






Antwort von R S K:

Sagt Mr. Wird-Erst-Beim-Export-Debayert!

🤣

Ja, werde jetzt nicht mehr auf den Senior Product Manager hören, nur auf dich! Wo du offensichtlich so viel Plan hast! LÖL
Schraub du nur weiter an deinen imaginären Nikon Parameter rum. 😉👍🏼



Antwort von pillepalle:

Na siehst Du, so kannst Du vielleicht auch noch was dabei lernen. Solange dabei reale Ergebnisse heraus kommen, habe ich auch mit imaginären Parametern kein Problem.

VG



Antwort von R S K:

"R S K" hat geschrieben:
Deine Datei habe ich übrigens nie erhalten. Ich nehm's zurück. Lag im Spam. Sowas.

- RK



Antwort von pillepalle:

Das ich das noch erlebe... ein Video zur Nikon Kamera :)

https://www.youtube.com/watch?v=L9om03cLJJs

VG



Antwort von Axel:

Unten getimete Stelle: .. was vielleicht nicht widerspiegelt, blablabla, was man aber trotzdem wärmer oder kälter machen kann ..."
https://youtu.be/L9om03cLJJs?t=152

Und?
Sieht so ein Tauchen durch die Farbtemperaturen aus?
Sieht so ein Drehen am Belichtungsregler ("... oder heller oder dunkler ...") aus?

Assimilate Crap.



Antwort von pillepalle:

Du kannst das gleiche machen wie in jedem anderen Raw Konverter. Sogar ein wenig mehr, den das bietet bisher kein anderes Programm in dem Umfang. Weiss nicht was daran Crap sein soll.

VG



Antwort von R S K:

pillepalle hat geschrieben:
Du kannst das gleiche machen wie in jedem anderen Raw Konverter. Sogar ein wenig mehr, den das bietet bisher kein anderes Programm in dem Umfang. Weiss nicht was daran Crap sein soll. „Crap” halte ich jetzt allerdings auch für überzogen und kurzsichtig.

Denn ich habe inzwischen einen regen Austausch mit Mazze gehabt und: es ist (fast) genau wie ich schon sagte! Auch wenn sie nicht wie vermutet den tatsächlichen Wert „erraten”, sie stellen bei PRRAW Material wo diese Information in den Metadaten faktisch nicht vorliegt, einfach auf ein Default von 5600 Kelvin ein. Im übrigen ohne irgendeinen Hinweis DAS sie es tun (ausser vielleicht im Video).

An dem ganzen kann ich Gutes und Schlechtes finden. Gut, weil das, wenn auch bestenfalls nur Messbar also im Grunde nur theoretisch, einen qualitativen Vorteil darstellt. Aber zu behaupten, dass es andere nicht KÖNNEN wo es wohl eher um WOLLEN geht? Schlecht finde ich da schon noch das vorzugaukel falscher Werte nur um einen weiteren Bulletpoint in der Featureliste packen zu können. Das ist zumindest nicht wie es bei Apple funktioniert. Sondern entweder richtig oder gar nicht. KÖNNEN tun sie es mit Sicherheit genauso.

Kann jeder von der einen und anderen Angehensweise halten was er will.

- RK



Antwort von Axel:

Ist mir echt ein Rätsel, wie ihr das gut finden könnt.

zum Bild




Antwort von pillepalle:

@ Axel

Eine Aufnahme vergeigen kann man mit jedem Programm irgendwie. Bei meinen Aufnahmen läßt sich der Weißpunkt und die Empfindlichkeit damit wunderbar steuern. Mehr will ich doch gar nicht.

VG






Antwort von cantsin:

Axels Screenshots sehen aber nicht so aus, als ob da der Weißabgleich wirklich auf bzw. mit den undebayerten RGB-Daten gemacht wird. (Just saying...)



Antwort von pillepalle:

Ich habe auch keine Ahnung was Axel da für Screenschots reingestellt hat. Ich weiß aber das es bei mir gut funktioniert und ich die WB und Empfindlichkeit genau so gut einstellen kann wie bei meinen Stills.

VG



Antwort von Axel:

pillepalle hat geschrieben:
Ich habe auch keine Ahnung was Axel da für Screenschots reingestellt hat. Die sind aus dem oben von dir verlinkten Scratch-Clip. Wo er sagt, nun gut, 5600°K ist ein Phantasiewert, aber man kann damit das Bild wärmer oder kälter machen, bzw. pauschal blauer oder oranger, wie ich sagen würde. Das ist genau dasselbe wie in FCPX' eigenem "Farbtemperatur"-Regler, der ironischerweise für normales Nicht-Raw auch tatsächlich funktioniert. Der Belichtungsregler, den er demonstriert, sieht auch aus wie ein "Helligkeit"-Regler. Damit sind für mich als Laien-Kolorist das überhaupt keine Raw-Werkzeuge, sondern Ettikettenschwindel.



Antwort von pillepalle:

Aber der hat im Video einfach mal wild an ein paar Reglern herum gedreht, ausgehend von einem halbwegs normalen Bild. Wenn Du mit Tint magenta rein knallst, siehts eben komisch aus. Das Du sowas als Maßstab für die Tauglichkeit nimmst, wundert mich schon ein wenig. Probier's doch einfach aus, wenn Du irgendwelches RAW Material hast. Die Software ist bis ende Oktober noch kostenlos. Es zwingt Dich auch keiner Scratch zu benutzen. Wenn Du andere Programme besser findest, dann nimm die doch einfach statt über Scratch zu mosern ;)

VG



Antwort von cantsin:

pillepalle hat geschrieben:
Aber der hat im Video einfach mal wild an ein paar Reglern herum gedreht, ausgehend von einem halbwegs normalen Bild. Wenn Du mit Tint magenta rein knallst, siehts eben komisch aus. Aber nicht so. Bin da bei Axel, die Ergebnisse sehen genauso aus, wie bei Anwendung der WB- und Tint-Regler von Resolve im normalen Color-Tab, nicht wie die Anwendung dieser Parameter im Raw-Tab. Das würde auch erklären, warum Scratch keinen Kelvin-Wert anzeigt, denn wenn es wirklich auf Raw (also undebayerten) Daten arbeiten würde, wäre es völlig egal, was da in der Kamera voreingestellt war oder ob da Metadaten gespeichert wurden oder nicht. (Denn RAW-/undebayerte Daten haben ja gar keinen Weißabgleich.)



Antwort von pillepalle:

Glauben könnt ihr natürlich was ihr wollt :) Ich hatte ja schon mal ein Beispiel gepostet, aber mehr als ungläubiges Staunen habe ich dafür nicht geerntet. Vermutlich ist die Vorstellung das eine Nikon Kamera das kann, oder ProRes RAW ein echtes RAW Format ist, für einige völlig abwegig ;)

VG



Antwort von Axel:

pillepalle hat geschrieben:
Vermutlich ist die Vorstellung das eine Nikon Kamera das kann, oder ProRes RAW ein echtes RAW Format ist, für einige völlig abwegig ;) PRAW ist schon interessant, für mich auch. Ob's Raw ist oder nicht, das ist mir völlig egal. BRAW soll z.B. kein echtes Raw sein, aber die Schnippsel, die ich geladen und in Resolve verbogen habe, waren unglaublich geschmeidig. Wenn ich schreibe "geschmeidig" meine ich damit jetzt nicht die Performance, obwohl auch die gut ist. Ich meine, dass es sich so anfühlt, als könnte ich im Nachhinein erst festlegen, was ich normalerweise vorm Drücken des Kamera-Auslösers festlegen muss. Weil das Bild so achselzuckend und lächelnd alles mitmacht, was mir idiotischerweise gerade so einfällt.

Ich bin ein Fan von Mischlicht. Aus diesem Grunde (und aus Bequemlichkeit) verzichte ich stets auf einen benutzerdefinierten Weißabgleich. Aber Mischlicht kann auch ziemlich heikel sein, weil nicht alle Farbtemperatur-Unterschiede harmonisch sind. Die dominierende Lichtfarbe in der Post akkurat (d.h. nicht als Färbung) festlegen zu können, ist ein Träumchen.

Das, was ich da in Assimilate sehe, erinnert mich an iMovie von vor 10 Jahren. Das aktuelle iMovie auf einem iPhone behandelt das eigene, erbärmlich magere Bordvideo raw-mäßiger. Das muss irgendeinen Grund haben.

Damit sage ich nicht, dass PRAW sich nicht lohnt. Aber für den Fall, dass 10-bit geschmeidiger sind als "16", muss ich's nicht haben (nämlich der Fall A7Siii). Ich habe den Ersteller dieses Videos in den Kommentaren gefragt, ob mittlerweile Metadaten mitgeschickt werden, aber bisher keine Antwort bekommen:

(nebenbei gesagt ist das Sigma 40mm eine zwar schöne, aber komische Sache. Tolle Brennweite und Schärfe, aber das Bokeh ist etwas nervös, nicht?)



Antwort von pillepalle:

Ich kann nicht mehr machen als von meinen eigenen Erfahrungen berichten und da komme ich mit Scratch eben wunderbar klar. Ich hatte bisher immer Premiere für ProRes RAW benutzt und fand das nicht besonders gut. Eben weil ich die essentiellen Einstellungen nur über Umwege realisieren konnte und mit den Tools auch nicht wirklich gut zurecht kam. Da kam Scratch wie gerufen. Ich nutze das zwar nicht als Resolve Ersatz, aber ich kann meine RAW Files damit schnell und einfach in Form bringen und als ProRes444 exportieren, damit ich sie in Resolve schneiden und ggf. noch graden kann. Ist natürlich ein extra Arbeitsschritt, aber solange andere NLEs für Windows Rechner bei ProRes RAW Files von Nikon Kameras diese Möglichkeit nicht haben, ist Scratch für mich relativ alternativlos. Wenn ich's schneller und unkompliziert haben möchte (ohne Zwischenformat) dann filme ich eben kein RAW, sondern z.B. ProRes 422HQ.

Ich kann ja verstehen dass es vielen zu umständlich ist und sie lieber alles in ihrer Lieblings NLE machen würden - geht mir nicht anders. Aber dass die Inkompatibilität der Formate und NLEs sich kurzfristig bessert ist zur Zeit zumindest unwahrscheinlich. Es dauert eben eine Weile, aber es werden sich schon noch vernünftige Workflows für das Format finden lassen. Scratch ist eben die erste Software die praktisch alle Kameras mit ISO, WB und Tint unterstützt und der Grund warum ich sie nutze.

VG



Antwort von Axel:

pillepalle hat geschrieben:
Ich kann nicht mehr machen als von meinen eigenen Erfahrungen berichten und da komme ich mit Scratch eben wunderbar klar. Dann ist doch alles gut.
pillepalle hat geschrieben:
Da kam Scratch wie gerufen. Ich nutze das zwar nicht als Resolve Ersatz, aber ich kann meine RAW Files damit schnell und einfach in Form bringen und als ProRes444 exportieren, damit ich sie in Resolve schneiden und ggf. noch graden kann. Klingt Scheiße, ist aber anscheinend ein professioneller Workflow für Raw, das in anderen NLEs geschnitten wurde. Ein flacher ProRes444-Master wird (ohne Titel, Überblendungen und sowas, ein „cleanplate“) exportiert, in Resolve importiert und schnöde per Rechtsklick scene cut detection angewendet. Hier (Stelle getimet) anscheinend „bacon blade“ genannt. Hat das schonmal jemand gehört?
https://youtu.be/A27lmVHig9U?t=281
Das "splice here" kenne ich noch gut. Seufz.

Ich habe mir auch gerade die DVR-Studio-Lizenz nicht gekauft, um meinen Kram dann doch in FCP zu graden. Ich bin gewohnt, mit XMLs rundzureisen. Im Zweifelfall kann man das aber natürlich probieren.