Weitere Prores RAW Parameter in Assimilate Scratch einstellbar

[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

[R S K]

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

😏

[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.



VG

[R S K]

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

[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

[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

[cantsin]

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.)

[Jott]

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

[R S K]

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

[mash_gh4]

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.ä.

[cantsin]

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

[R S K]

Nur dass es hier um PRRAW geht und nicht cDNG oder DNxHD. 🤷🏼‍♂️

- RK

[cantsin]

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.

[R S K]

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

[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

[cantsin]

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.

[R S K]

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. 😄

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.

Mein Beispiel zeigt, dass es da im Resultat sehr wohl Unterschiede gibt.

Ja. Bei den Formaten.

- RK

[cantsin]

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.

[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

[R S K]

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?

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

[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

[R S K]

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. ☕️

fällt es echt schwer Dich ernst zu nehmen.

Wo mir im Leben nichts wichtiger ist… 😢

- RK

[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

[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

[pillepalle]

Reicht Dir das?



VG

[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

[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

[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

[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

[R S K]

Wenn du nichts kleineres hast… PN ist geschickt.

- RK

[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):

... nämlich so (Stelle getimet):

[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

[R S K]

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. 👍🏼

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

[pillepalle]

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.

[R S K]

… 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.

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.