Bisher geht es z.B. bei Adobe in 3 Schritten:
1. Raw-File auf den Raw2DNG-Konverter ziehen, der dann DNGs erstellt.
2. In Photoshop die DMGs öffnen und im Raw-Converter bearbeiten, dann als Einzelbilder speichern.
3. In Premiere als Bildfolge importieren.
Umständlich mag das zwar sein, aber letztlich braucht man doch immer einen Raw-Konverter - einzig der 1.Schritt könnte wegfallen, wenn z.B. Photoshop das "Auspacken" selbst übernehmen würde.
Automatisches Umwandeln der RAW-Files in ein anderes Format wie ProRes verspielt doch nur Möglichkeiten ...
Die Konjunktion "dass" wird mit doppeltem "s" geschrieben, aber nicht das Relativpronomen "das".
Nichts für ungut, liebes Slashcam Team. Ich muss einmal etwas beanstanden, was mich bei jedem zweiten Artikel nervt und in den Habitus der ganzen filmenden Schüler eingeht, die auf Slashcam mitlesen...
Edit: Sorry, war zum falschen Artikel gepostet ;)
Zuletzt geändert von molch am Mo 03 Jun, 2013 14:14, insgesamt 2-mal geändert.
Also ich hab die Bilderfolgen lieber testhalber mit Lightroom geöffnet. Ein Bild nach Wunsch bearbeiten, Änderungen mit dem Rest synchen, als TIFF exportieren, fertig.
Oder Raw-DNG, In After Effects als Sequenz importieren und dann debayern.
Dann mit Dynamic Link oder Export nach Premiere.
Am einfachsten wäre tatsächlich ein Converter bei dem man die ML Raw Datei über ein Interface debayern kann und dann direkt in einen DnxHD oder Prores Codec 12 Bit oder sowas exportieren
auf DNG codieren mit dem gratis tool von ML
mit photoshop als batch auf TIFF oder direkt in ein MOV
alternativ mit QT7 oder compressor ein MOV aus der TIFF sequenz machen (in einen beliebigen codec)
cinema5d hat diesen workflow getestet und der ist wesentlich schneller und stabiler als über afterFX oder dergleichen am mac.
Für die Mac User: Ich verwende Raw2dng von Magic Lantern, um DNGs zu erzeugen welche dann mit AE CS6 zb in ProRes gewandelt werden.
Raw2dng ist sehr schnell, sagen wir mal halbe "Realtime".
AE braucht für den Export von zb 3 Minuten etwa 1 Stunde. Es läuft aber stabil durch, insofern ists mir egal. Für Szenisches Filmen sicher ok, für Run n Gun wohl zu aufwändig.
Die Quali find ich schon sehr beeindruckend, guckt Euch mal die letzten drei Vergleich von mir von h.264 vs RAW hier an: https://vimeo.com/user1971791/videos/so ... mat:detail
Sorry, sind die gefürchteten und berüchtigten "Blumen Videos" ich gebs zu aber hey man sieht die erreichbare Qualität :-)
Was Ihr(Manche) in Eurer Betrachtung überseht: Jeder Konvertierungsvorgang vor der Schnittsoftware bedeutet, Ihr seid gebunden an das Ergebnis. CinemaDNG ist das unberührte RAW, das während der Arbeit in der Gradingsoftware debayered wird - und ob ich dann doch noch ne Blende herausholen möchte oder die Lichter weiter absenken, das mach ich in der Gradingsoftware - und nicht den herrlich unnötigen Schritt zurück nach ACR/Photoshop oder Aftereffects. Zudem arbeitet Ihr mit einem größeren Bitumfang und Banding ist deutlich schwerer hervorzurufen.
Tatsächlich werde ich demnächst noch 12Bit-Ausgabe reincoden - und das mit simplem Abschneiden der LSB 2 Bit - wir werden sehen, wie sehr das ins Gewicht fällt.
Das Ziel ist jedenfalls, ob nun raw2cdng oder die anderen Converter - möglichst noch mit dem hohen Bitumfang in der Schnittsoftware zu landen. Alles andere ist meines Erachtens halbbacken.
Ganz pervers ist es ja, daraus anschliessend eine DCT zu machen, wo sie schon (quasi) I-Frames haben.
Manchmal kann man wirklich nur den Kopf schütteln.
Wobei es im DNG auch einwenig darauf ankommt, was für ein RAW da eigentlich drin liegt und in welchem Zustand.
Das ist von dem Hack nicht wirklich klar denn DNG unterstützt ja verschieden Formate (und Profile) auch innerhalb z.B. von TIF und die Unterschiede sind schon deutlich.
Solange das nicht wirklich geklärt ist, wird man sich zwar die Bildchen zwischen den unterschiedlichen Kameras anschauen, aber keinen wirklichen Vergleich bezüglich einer Nachbearbeitbarkeit treffen können.
Die Daten in der raw-Datei sind Rohdaten des Sensors, gerade Zeilen mit RGRGRG.. beschrieben, die ungeraden mit GBGBGB... Wir haben es mit der "unbearbeitetsten" Art von Bilddaten zu tun, die die Kamera rausgeben kann - abgesehen von möglichen "Fuxereien", die Canon schon auf dem Sensor macht. Jedenfalls keinen Deut schlechter als die FotoRAWs - und auch der raw2dng-Converter gibt den Raw-Daten nur einen DNG-fähigen TIFF-Header, damit Software es lesen kann. (Inzwischen gibt es zwei kleine Dinge, die in der Software nachgebessert werden. (A) Pink fridging, welches quasi hart limitiert wird und (B) Vertical Lines, welche mit einer Multiplikation auf jeder 8 Spalte nachgebessert werden)
Ich hatte das gerade in einem andern Thread geschrieben, dass meine Vermutung ist, dass da dann TIFF 6.0 Daten drin sind, die die ganzen Vorprozesse (Dunkelstrom, Pixelfix usw) noch gar nicht hinter sich haben und auch kein DNG Profile.
In dem kleinen Konversionsprogramm wird wahrscheinlich nur der Header gesetzt und ein TIF.EP daraus gemacht.
Das ist natürlich nicht das, was man aus andern Kameras bekommt.
TIFF6/EP ist die Basis aller DNGs. Für CinemaDNG sind einige Tags verpflichtend - und viele habe ich nicht gesetzt, schlicht, weil ich damit in meiner Freizeit nicht umzugehen weiß :) WoWu, betrachtet man es als Geschenk der Community, hat man Bilddaten, die man zuvor in dem Preissegment nie erhalten hat.
Im Kino wird das RAW, wenn denn darauf gedreht wurde, oft erst einmal in ein LOG Format (Cineon/DPX) entwickelt, von wo es dann in nicht nur ins Grading sondern auch in die VFX geht.
In diesem Workflow, wo alles Grading direkt nach dem Editing mit Proxys gemacht werden muss, dass ich korrekte Daten raus bekomme, muss ich also die VFX am Ende machen; weiß nicht genau wie ich das finde.
Ja, das stimmt schon, nur unabhängig davon, was man mit den RAW Daten hinterher macht und welchen Weg man in der Weiterverarbeitung geht, müssen die Sensordaten im ersten Schritt (obligatorisch) von all den Sensorbedingten Störungen befreit werden.
Das geschieht immer in der Kamera, weil es (auch) vom dynamischen Sensorverhalten abhängig ist.
Geschieht das nicht, hat man die ganzen Störungen und Bildveränderungen hinterher im Nutzsignal.
Aber chmee hat natürlich völlig Recht ... als kostenlose Beigabe zur Kamera, schon nicht schlecht...und solange schöne Bilder damit entstehen und solche Sachen u.U. gar nicht stören ... alles prima.
Klar, das ist alles scho recht so. Aber ich frag mich immer wie der Signalweg dann immer genau aussehen soll - heutzutage ist ja nur noch RAW wahres wie es scheint, den gewöhnlichen LOG-Workflow scheint niemand was abgewinnen können. Immerhin exportieren sie alle in TIFF statt in ein LOG Format, wo ja auch schon viel verloren gehen kann...
Wem nur Editing und Grading bevorsteht, dem passt das sicher; aber ich frage mich nun (auch in Anbetracht meiner bevorstehenden Anschaffungen) für mich selbst, welchem Workflow ich da folgen soll(te). In den "einfachen Privat Workflows", die man hier so immer nachliest, fehlt mir halt ein komplettes Aufgabengebiet - und für den Highendworkflow tatsächlich ein wenig die Hardware als auch das Knowhow.
Die Workflows werden sich zukünftig sowieso angleichen.
Spätestens, wenn die verfügbaren Qualitäten aus den Kameras erschwinglicher werden, als man es sich in der Post noch (finanziell) leisten kann.
Ich sehe ja, wie teuer ein 12 Bit Monitoring gewesen wäre, sehe aber auch, dass man es mit dem richtigen Workflow gar nicht braucht und trotzdem im Endmedium (Filmbelichtung) die maximal mögliche Qualität daraus erzielt.
Die NLEs müssen nur erst mal in der Breite umgestiegen sein, von frameorientiertem Workflow zum sample-orientierten.
Dann spielt das eigentlich gar keine "Geige" mehr, wie gut- oder aufwändig dein Footage ist, weil es lediglich ein einziges Mal zum Finishing herangezogen wird.
Wir werden uns also mehr und mehr an die "indirekte" Bearbeitung gewöhnen müssen.
Dann ist es auch wieder egal, ob man RAW oder LOG hat.
Hm, ich sehe da nur noch nicht, wo ich da einharke, mit den Produktionsschritten; gerade in Bezug auf die VFX.
Ich finde nach wie vor die Blackmagic Lösungen für mich am Interessantesten; RAW wenn ich will, aber LOG als Hauptsache. Und zumindest diese Pocket kann ich "mal eben" kaufen, ohne mich finanziell zu sehr auf dünnes Eis zu begeben; das schaffe ich nicht mit einer normalen BMCC. Privat, nur für mich selbst, versteht sich; aber man will ja auch da am Ball bleiben ;)
Das deckt sich mit meiner Auffassung.
(Aber das ist für den Thread jetzt schon ziemlich OT)
Wir haben bisher meistens Video gemacht und relativ wenig Film und standen ebenfalls vor der Workflowfrage, zumal wir Grafik und (evtl. mal) VFX alles extern machen lassen (wollen) und das trotzdem sehr eng in den Workflow einbinden möchten.
Da kamen uns die neuen Workflows sehr entgegen. Und plötzlich gibt es eigentlich nur noch einen Einzigen, sowohl für TV, als auch Film, der sich letztlich nur noch im endgültigen Renderprozess unterscheidet.
Uns ist es jetzt also egal, ob wir lineares Video, LOG oder RAW verarbeiten, weil wir jedes Format nur noch über die entsprechenden LUTs abbilden und auf das Originalfile erst bei der Endfertigung zugreifen.
Es gibt also auch nur einen einzigen Renderprozess und damit auch die optimale Codierqualität (keine Bildkopien mehr, keine Renderverluste und uneingeschraenkte Reversibilität).
Wir machen zwar kein ausgeprägtes VFX aber das würde sich, wie andere "Blues/Greens" als Layer doch natlos einfügen.
Wir haben die BMCC zwar auch nicht (wie auch) aber wenn Du mich nach meinem Bauchgefühl fragst, ist das genau der richtige Weg.
Die Flexen, die wir haben, haben das übrigens genau anders herum gemacht.
Die haben einen ergonomisch guten Body und die entsprechende Verarbeitung, man kann die Sensorblöcke aber austauschen, um auf denselben Effekt zu kommen.
Die BMCs reduzieren das auf den Sensor und die Schnittstelle.
Mindestens ebenso gut, wenn man sich an die Ergonomie gewöhnen und auf ein paar teure Features verzichten kann.
Aber ich glaube, "der Zug" fährt genau dahin.
Auch wenn man über 10, 12 und 16bit, logarithmisch und linear so schön techniknerden kann - tatsächlich mache ich mir um log nur Gedanken, um die Datenmenge/rate weiter zu senken, was in jeglicher Hinsicht ein Vorteil ist. Nur steht da auch eine simple Datenkompression wie Huffmann zur Diskussion, weil es TIFF kann.
Ich bin halt noch nicht so recht sicher, wie das nachher in der Praxis ausschaut.
Wenn ich etwa die VFXen mache - wie kriege ich das Material rein?
In Nuke kann ich ohne Probleme div. Parameter bei unterstützten Formaten einstellen und anpassen (habe tatsächlich auch nur mit REDRAW im Nuke gearbeitet), und dann zB durch div. Colorspace-Änderungen das problemlos zum AlexaV3 LOG biegen um in der LUT zu arbeiten und entsprechend mit Alexa zu mischen. Fand ich in der Praxis nicht so lästig, wie sich das anhört.
Aber ich kann ja nur Pixelinformationen compen, keine rohen Daten; also, wie gehe ich wieder raus? Da ist es um einiges einfacher, die Daten als LOG (oder REC709, bei TV) zu importieren, die VFX zu machen, und genau so auszugeben wie sie reingekommen sind. So können Grading und VFX auch problemlos parallel gefertigt werden, was ich immens wichtig finde; im Moment scheint mir in den aktuellen Workflows, wo kein LOG genutzt wird, die VFX nach dem Grading anzufertigen als sinnvollste Option; aber das ist bei großen Produktionen ja Käse. Man stelle sich vor das Grading wird noch einmal geändert, dann können bei einer Hand voll VFX Shots aber gerne noch einmal ein paar Tage ins Land ziehen, bis man alles angepasst hat (hab ich auch schon erlebt, und da lag es "nur" an einer sehr extremen LUT, die alles verdreht hatte, aber erst später rein kam).
Wenn es mit After Effects geschehen soll hast Du über CameraRAW auch nur die Wahl, die Parameter anzupassen, aber dann bleibts eben auch so wie Du es eingestellt hast.
Überhaupt haben wir nur mit RAW gearbeitet, wenn es an Pan&Scan mit einer RED ging; sonst alles nur direkt in der Zielauflösung skaliert als LOG/REC709.
Insofern steht für mich der LOG-Workflow an dieser Stelle noch als sinnigste Option im Raum; es ist ja nicht so, als ob LOG irgendwas total schlimmes wäre - da muss man halt beim Entwickeln etwas aufpassen was man einstellt und man kann das Material nicht mehr komplett vergewaltigen, aber wenn wir mal von 14 Blenden bei 14bit Linear RAW ausgehen hast im 10bit LOG idR auch nicht den großen Verlust, qualitativ. Film wird doch heut noch so gescanned, und dessen Dynamik ist ja unerreicht.
Kann halt nicht mehr jeder Hansel, der schon einmal Photoshop raubkopiert hat, mit tollen Schiebreglerchen bunte BIldchen herstellen, müssen die Leute halt mal ein wenig schauen, was es heißt, richtig zu graden.
Ich kann Deinen Standpunkt verstehen und grundsätzlich stimme ich Dir zu, dass eine gute 10 Bit Verarbeitung sich im Produkt nicht wesentlich von einer 12 Bit unterscheidet.
Unterschied ist der, dass man in 10 Bit mit dem Originalmaterial noch arbeiten kann, in 12 Bit eigentlich nicht mehr sondern nur noch im Proxy.
Aber genau das ist ja der Grund für DNG.
Denn darin wird eigentlich nichts mehr am Originalfile gemacht sondern alle Veränderungen werden lediglich noch als Metadaten abgelegt und von der Maschine ausgeführt, die das endgültige Rendering durchführt.
Vorteil dabei ist zweifellos, das das Material noch farbraumneutral vorliegt und je nach Ziel-Content dann erst bearbeitet wird und dass es keinen Generationenverlust mehr gibt. Der Störabstand ist also traumhaft.
Nun bin ich mir nicht völlig sicher, welche genauen Auswirkungen das auf VFX hat, weil wir es quasi nicht machen ... oder zumindest noch nicht im DNG Workflow.
Aber ich kann mir gut vorstellen, dass es da einen ebensolchen Workflow gibt, weil die Mechanismen überschaubar und reproduzierbar sind.
Aber da tappe ich noch einwenig Im Dunkel und muss selbst forschen.
Die Hauptfrage, die sich im Augenblick nur eben stellt ist die, wann wird welche Firma den indirekten Workflow mit DNG unterstützen.
Apple hat ja sein FCPx schon auf Sampleverarbeitung umgestellt ... hat dafür aber andere Schwierigkeiten .... eigentlich wäre ja Adobe mit Premiere der angesagte Partner, aber da tut sich noch nix.
Von zwei Firmen weiss ich, sie habe's im Schirm, haben aber noch kein Produkt.
Nur dass es kommt, scheint mir mittlerweile ziemlich sicher zu sein.
Dann verliert auch diese ganze "Entwicklung" von RAW ihren Horror.
RAW ist derzeit ja nur deswegen nicht wirklich unterstützt, weil jeder seine eigene Suppe kocht.
Und das macht es ja auch gerade so unattraktiv.
DNG unterstützt derzeit zwar 5 Formate, aber manchmal sind die Formate selbst ja noch alles Andere als gut.
Wie auch hier und jetzt bei dem Hack ... kein Mensch weiss, was hinterher in dem Datensatz eigentlich drin ist und wie es aussieht, geschweige denn, wie eine solide Bearbeitung vonstatten gehen kann.
Solange das der Fall ist, bleibt so ein Format für des kommerziellen Einsatz ungeeignet.
Und selbst, wenn es in einem Container steckt, auf dem DNG draufsteht, ist noch lange nicht sicher, ob auch was Gutes drin steckt.
Solange wirst Du mit einem Videoformat in LOG Quantisierung sicher noch gut beraten sein.
Aber auf lange Sicht vermutlich auch umstellen auf Proxy-Verarbeitung und Metadaten.
Aber, um das auch nochmal klar zu sagen ... diese ganze 14/16/32 Bit Euphorie macht bei uns auch keiner mit, denn, wie gesagt: Ein gutes LOG Format ist kaum feststellbar schlechter.
chmee hat geschrieben:[..] Nur steht da auch eine simple Datenkompression wie Huffmann zur Diskussion, weil es TIFF kann.
Aber mit Huffmann kommt man ja nicht weit .... Wenn ich mich recht erinnere, macht der pro 2 Bit, 0,1 Bit Reduktion.
Das ist eigentlich mehr ein Add-On.
..Kann halt nicht mehr jeder Hansel,....müssen die Leute halt mal ein wenig schauen, was es heißt, richtig zu graden.
klingt n bissel elitär. ;) Die Spreu trennt immer vom Weizen, und wer es nicht kann, der kann es eben nicht. Das über ne log-LUT als besonders zu kennzeichnen find ich gelinde gesagt schlimm. Darüber hinaus habe ich mit Blackmagic-Produkten ziemlich oft zu tun. Und man kann Glück haben, und die Produkte funktionieren, aber wehe, Du findest nen Bug, der wird (A) mit ziemlicher Sicherheit nicht nachgebessert und (B) es wird eine Version 2 vorgestellt, die wieder den gleichen Betrag kostet - und die BMCC hat so manchen Käufer sauer gemacht, der sie immer noch nicht erhalten hat.
Thema Log vs. RAW
log ist nicht im Gegensatz zu RAW nennbar, sie sind sogar vereinbar - so, wie es in der BMCC gemacht wird. RAW hat einen immensen Ressourcenhunger, weil zur Ansicht immer demosaiced und mit Hilfe einer Colormatrix (und anderer Werte) in eine Ansicht gebracht werden muß. Im Gegensatz zu RGB oder YUV-Daten ein erheblicher Mehraufwand. Der größte Vorteil von RAW ist dennoch die "quasi"-Sicherheit, dass nicht irgendeine Software etwas halbherzig gemacht hat - und gerade das Demosaicing hat in den letzten 5 Jahren massive Sprünge gemacht - auch kann man mit Rausch-Signaturen an RAWs deutlich besser herumdoktorn als an vorgebügelten RGB/YUV-Daten.
..von 14 Blenden bei 14bit Linear RAW ausgehen..
Brauchen wir aber nicht. Nicht mal bei der BMCC.
@WoWu - Ich bin mit Filmproduktion an sich zu selten beschäftigt, ich sitze eher auf der anderen Seite und habe mit der Technik zu tun. Deswegen darf man mich da auch mal schlagen aufgrund von Unwissenheit. Ich bitte erstmal ganz klar zwischen DNG und CinemaDNG zu unterscheiden. Durch den Ansatz des ML-RAW-Hacks ist die Ausgabe so ziemlich auf das beschränkt, was jetzt auch rauskommt - dass die Hersteller nicht sofort aufspringen, herrje, die waren noch nie schnell - und wenn Canon unruhig mit den Fingern tippelt (weil auch die C-Serie verkauft werden will), dann ist auch an dieser Stelle Nix gegen die Lobby zu machen - das muß die Community lösen.
Nenn es wie Du willst; ich habe mit vielen Leuten zu tun, die eben etwas blauäugig da sind. Die verstehen auch nicht, dass RAW auch Nachteile haben kann (gerade Archivierung, Backups am Set, Speicherhunger etc) und sind sehr euphorisch, haben aber auch keine Ahnung, was eigentlich vielleicht auch dahinter steht. Das ist für die wie Photoshop - machst ein RAW auf, holst alles raus, am besten noch ein grauenhaft überzeichneter Look, und haben von LOG noch nie was gehört. Und nennen sich dann Coloristen.
Vielleicht kannst Du mir dann aber, wenn Du meinst, dass das mit dem RAW alles so viel besser sei, sagen wie ich das VFX Problem löse?
Du sagst, die Gefahr dass eine Software Mist baut ist weg. Nun mache ich aber die VFX auf XY, aber die andere gibt YZ aus. Und nun passts nicht mehr überein, ich kann ja keine RAW Daten generieren; REDRAW gibt es seit Jahren, auch da gibts keinen Workflow, der uns das generiert. Damit kannst ja nicht arbeiten, wenn Du nie weißt, wie es am Ende aussieht; generiert man Daten, die nicht ins Bild passen, das ja Mist.
Brauchen wir aber nicht. Nicht mal bei der BMCC.
Ich weiß. War das Gedankenspiel, weil bei 14bit LIN mehr als 14 Blenden nicht drin sind, die 14 Blenden aber auch problemlos (will sagen, nicht sichtbar) in 10bit LOG passen.
Man muss sich auch fragen, für was man produziert. Ich schätze dass ein Großteil der Nutzer, die jetzt RAW drehen (durch Blackmagic und 5D3), nicht für TV geschweige denn Kino produziert; ich bin so ehrlich, dass ich sage: ich tue das (privat) nicht. Und deswegen ist mein Plan mit einer Blackmagic nicht oft RAW zu drehen, weil mir LOG total langt. RAW in schwierigen Situationen. Und ich glaube, LOG könnte vielen langen, wenn sie es verstehen/kennen würden - aber das RAW, das natürlich cooler. Und einfacher, zugegeben, auch.
Das Format ist mir eigentlich egal, wichtig ist, dass es vom DNG Converter zu verstehen ist und ... und jetzt kommt's, dass die Kamerainformationen bezüglich der Farbmaske enthalten sind. Wenn sich andere Daten der Kamera hinzufügen lassen und die Rendering Hints übertragen werden, umso besser.
Nach meinem Dafürhalten ist DNG nur dann nützlich, wenn es die Kameradaten nicht interpretiert, weil das beliebig ungenau ist sondern wenn der Hersteller (für diese Kamera) DNG unterstützt, also alle erforderlichen in das DNG File angibt oder wenn der Hersteller ggf. sogar selbst ein DNG herausgibt, was unsere Flexen tun.
Das gewährleistet nämlich, dass die "Geheimnisse" der Hersteller, die sich oft sogar hinter einer Verschlüsselung befinden, soweit mitgeteilt werden, dass hinterher bestmögliche Bildqualitäten entstehen.
Ausserdem ist so gewährleistet, dass die Quailitäten nicht dadurch schwanken, dass Adobe seinen Konverter verändert.
Soll heissen: Sämtliche Informationen der Farbmaske müssen enthalten sein, weil sich sonst keine LUTs errechnen lassen.
Fehlen die, wird man es schwer haben, damit kommerziell zu arbeiten.
Ich habe in Bezug auf den Hack auch allergrösste bedenken, dass die Kamera die Sensorkorrekturen gar nicht durchführt, dass das Signal also an einer Stelle abgenommen wurde, an der die technischen Korrekturen noch gar nicht durchgeführt worden sind.
Ist das so, dann kann man das Signal ohnehin für den kommerziellen Einsatz nicht gebrauchen, weil dann im Bild alles Mögliche zur "Wundertüte" wird.
Also: Hot Pixel, Linearisierung zwischen einfallendem Licht und el. Werten, Inhomogenitäten der Empfindlichkeit zwischen den Pixels müssen beseitigt
sein, das Dunkelbild muss frei von Mustern sein usw.
Das sind alles Sachen, die kann man nicht mehr in der Post gradebiegen und müssen vom Kamerahersteller geleistet werden.
Und dann wären wir irgendwann bei der Datenreduktion, bzw. bei einem vernünftigen Interface.
Was man damit kaputt machen kann, sieht man bei der RED. (Farben und Schärfe). Wer's mag... prima. Aber man muss es wirklich mögen. Nicht jedermanns Sache, wenn man die Wavelet-Schwächen in jeder Bewegung sieht und man immer denkt, die Brille sei verschmiert.
Also, Du siehst, Bildansprüche orientieren sich immer an der zukünftigen Verwendung des Bildes.
Nicht daran, wie leicht, oder schwer man sie aus einer Kamera bekommt.
Bisher habe ich noch nicht den Eindruck gewonnen, dass solche Rahmenparameter berücksichtigt worden sind.
Davon ausgehen kann man bei Herstellern, die so eine Konstruktion vorsehen. daher ist mein vertrauen, auch verwertbare Signale aus einer BMCC zu bekommen, einfach grösser.
Es ist also nicht einfach mit einem DNG passenden Format getan. Die Inhalte müssen stimmen, sodass der DNG Converter nicht anfängt zu interpretieren.
@CameraRick
Der Vorteil wäre natürlich, dass du im RAW farbraumneutral bist und selbst festlegst, welches Format du ausgeben willst.
Setzt aber voraus, dass Du De-bayern kannst.
WoWu hat geschrieben:@CameraRick
Der Vorteil wäre natürlich, dass du im RAW farbraumneutral bist und selbst festlegst, welches Format du ausgeben willst.
Setzt aber voraus, dass Du De-bayern kannst.
Glaube, dass mir da die Software einen Strich durch die Rechnung macht... :)
Ich weiß tatsächlich nicht wie es mit DNG im Nuke ausschaut, bin auch leider gerade im Ausland und am Laptop nichts brauchbares zum Testen installiert.
Selbst wenn es geht, müsste ich alles durchs Nuke ziehen; das schafft man ja zeitlich nicht. Und wie geht man dann wieder da raus? LOG? ;)
Ich habe was im Kopf, das alles ins CineForm RAW zu schieben, da kann man wohl einen Debayer Algorythmus festlegen. Habe ich aber (noch) nicht probiert, auch wie gut das allgemein ist.
So oder so, das Problem ist immer, dass ich irgendwie aus einem Programm raus kommen muss. Sobald ich Pixelinformationen anfassen muss, geht das auch nicht mehr mit reinen Metadaten (wie etwa im Grading, solange man nie mit Masken arbeitet), sondern muss ausgegeben werden, im Zweifel als DPX/CIN.
@CameraRick. ich kann Dir einfach nicht folgen. Ich weiß einfach nicht, wie Du RAW gegen Log aufwiegst bzw. warum Du das tust.
RAW ist eine Kodierungsform der Bilddaten LOG ist eine Konvertierungsform der Bildwerte, eine Transfermatrix.
BMCC gibt eine RAW-Datei mit logarithmischer Zahlenwertigkeit raus - und der ML-Hack wird via meinem Konverter auch bald nen logarithmischen bekommen.
@WoWu
Ich gebe Dir natürlich recht, MagicLantern hat nicht den finanziellen Posten, um Standards vorzugeben - große Firmen können, sogar wenn ihre Idee blöd ist/war, einen Codecstandard verabschieden, schlicht, weil "too big to fail". Im ML-Fall kann man es aber auch positiv betrachten - (A) für "den" Indiefilmer ist kostenlos das Beste, was passieren konnte. Mit n bissel Schmalz ist ne Menge möglich. (B) Solange "nur" Rohdaten des Sensors ausgegeben werden, wird es keine außergewöhnlichen Änderungen geben - besser zu beschreiben mit "keine" - und so wird es auch sein, denn mehr ist man im Body gar nicht imstande.
"Der Profi" an sich gibt gerne das Geld aus, wenn er weiß, dass er langfristig darauf setzen kann - und somit ist Deinen Zweifeln nichts entgegenzusetzen.
Der Bereich ML-RAW ist grad mal 1 Monat jung - wir schauen mal..
Hab ich doch verstanden.
Ich frage Dich gerade, wie da ein gescheiter Workflow für Dich aussieht, der die Ausgabe nicht nur am Schluss hat. Mit LOG meine ich nun nicht direkt die Art wie die Werte gelesen werden, sondern wie mir das Footage vorliegt; etwa als CIN oder DPX, eben im LOG Verfahren. Oder als ProRes, wie Du magst (hab ich glaub ich auch im ersten Post geschrieben).
Bisher scheint es ja so zu sein, dass ich alles mit Proxies arbeiten soll, und dann im Grading erst an die Daten gehe. Was voraussetzt, dass ich vieles erst nach dem Grading machen kann. Das finde ich unpraktisch.
Also, wie soll es statt finden, der Wokflow? Das ist eine ernst gemeinte Frage. Weil bisher lese ich nur "RAW entwickeln erst zum Schluss".
Gebe Dir vollkommen Recht .... was da "for nothing" zusätzlich aus der Cam kommt wird sicher alle, die sie besitzen, freuen.
Und ich finde auch den Enthusiasmus, mit der daran gearbeitet wird, wirklich beachtenswert.
Chapeau !
Nur ich glaube auch CameraRick bewertet die Verwendbarkeit und in vielerlei Hinsicht muss ich ihm da Recht geben.
Der Unterschied zu RAW ist wirklich gering, bis kaum feststellbar.
Wir haben damals das Material auf einem "geliehenen" 12 Bit Monitor (weil rd. 60.000 $ etwas teuer) gegeneinander verglichen und wirklich wenig Unterschied gesehen. Mag nun auch sein, dass das Auge da bereits am Limit ist. Warum also auch immer.
Nun mögen die 12 Bit für CameraRick noch eine kleine Differenz machen, weil er VFX macht ... das kann ich nicht beurteilen, aber ansonsten sind LOG Quantisierungen nicht wirklich schlechter.
Der nächste Schritt besteht sicher darin, dass die alten DCTs den Bach runter gehen und LOG Kurven auf modernen Transformationen gemacht werden. Ich habe leider noch keine XAVC Resultate gesehen, aber man hört nur Gutes. Ebenso bin ich gespannt, bis Pansonic auf AVC-U 12 Bit Material ermöglicht. (soll auch dies Jahr noch kommen).
Was RAW betrifft, nehmen wir es, solange DNG von der Kamera unterstützt wird, weil wir flexibler im De-Bayering und den Farbräumen sind. Insofern hat RAW schon den einen oder andern Vorteil, wenn man ihn nutzen kann (und will).
Ansonsten heisst DNG ja noch lange nicht, dass die beste Güte darin steckt, speziell wenn das Kameraformat nicht vom Hersteller so ausgegeben wird und es vom DNG Konverter erst Re-engineered wird, denn dann ist es nicht besser, als Adobe es hinbekommt. Rendering Hints, die die Hersteller im Signal unterbringen und die deutlich zur Qualität beitragen, bleiben dabei nämlich auf der Strecke. Auch die Informationen über die Farbmaske lösen sich im Nirvana auf. Schlecht für's Signal.
Deswegen finde ich solche RAWs "aus zweiter Hand" nicht allzu nützlich und würde, wie CameraRick auch ein stabiles LOG vorziehen.
Bleibt abzuwarten, wie BMD das Format unterstützt und was alles enthalten ist.
Um nicht falsch verstanden zu werden. Ich habe nichts gegen eine Log-Transformation. RAW kann auch LOG-quantisiert sein. Der essentielle Punkt ist doch: Gegen einen wirklich schnellen/sinnvollen Workflow spricht erstmal die schiere Datenmenge, die beim Speichern auf Karte nicht geringer werden wird - weil es nicht umsetzbar ist. In egal welchem Body, der Digic bzw das Mainboarddesign hat nicht die Ressourcen, um RAW in etwas Sinnvolles zu encoden. Und damit hört der Gedanke um sinnvollen Einsatz bei mir fast schon auf. 7Minuten 1920x1080@24p@14Bit auf einer 32GB-Karte sind aber per se kein schlechter Wert - wenn man zB Werbung oder Musikvideo betrachtet.
Nun, CameraRick, mir scheint, als sei Dir der VFX-Anteil sehr wichtig. Da ich mit VFX nicht arbeite, kann ich Dir keinen sinnvollen Workflow zusammenreimen. Ich meine, wenn die größeren Compositing-Applikationen mit Grading und Layering klarkommen, warum nicht das alles in einem letzten Schritt machen? Was (Dir) meines Erachtens fehlt, wäre ein RAW2CIN/DPX-Transcoder. Kommt das etwa hin? Die Rohdaten geben es her - und in diesem Fall geht es uU um den CDNG-Converter, den ich für die Resolve-Jünger geschrieben habe - und auch ich bin weiterhin auf der Suche nach dem optimalen Format, mit dem ich mit 10Bit oder 12Bit im Adobelager bleiben darf, schlicht, weil ich damit arbeite..
Ich sehe das im Augenblick so:
(Korrigier mich, wenn ich falsch liege)
1) Die Kamera erzeugt n Limawerte, jeder Wert ist 14 Bit tief, was zu (zu) hohen Datenraren an der Kartenschnittstelle führt und immens grosse Files generiert.
2) Es ist nicht bekannt, was bisher kameraseitig mit den Daten geschehen ist, ob sie also die erforderlichen Sensorkorrekturen überhaupt erfahren haben.
3) Es handelt sich nicht um ein bekanntes RAW Signal, was aus der Kamera kommt sondern wird durch den DNG Konverter analysiert und als Re-engineertes Signal in ein TIFF Format konvertiert und mit einer definierten Kodierung belegt.
4) In dieser Konversion geschieht bereits ein De-bayering, das von Aussen nicht mehr beeinflussbar ist.
5) Es ist nicht bekannt, ob oder welche zusätzlichen Metadaten aus der Kamera kommen. Geschweige denn Rendering Hints.
Ist das so einigermassen richtig zusammengefasst ?
Oder gibt es genauere Infos ?
Da ich VFX Artist bin, ist mir das schon irgendwo wichtig, ja :)
Das Problem ist nicht mal das Transcoding, das wird eben "irgendwo gemacht" (keine Ahnung wie die das machen, ich bin kein DIT). Das RAW (wie etwa von der Alexa oder RED) wird irgendwo, mit irgendwelchen vermutlich sinnvollen Settings entwickelt und in einem LOG Format, idR als DPX ausgegeben. Egal ob TV oder Kino. Und von da aus arbeiten alle weiter.
Das hat den Vorteil, dass ich VFXen machen kann, aber jemand anders auch parallel graden. Wenn ich dann fertig bin, setzt man die Clips einfach ein. Weil es ohnehin unkomprimiert ist und genau so wieder bei mir raus kommt, wie es rein kam (Farbraum usw) gibt es da keine Probleme. Ist der Kunde zufrieden sind wir fertig, ist er unzufrieden (mit VFX ODER Grading) wird das in der Abteilung geändert und alles ist supi.
Nun stell ich mir das mit RAW vor. Ich könnte die VFXen ja nur noch nach dem Grading machen, weil ich ja die Comp nicht als RAW ausgeben kann und sicher nicht zu entscheiden habe, wie das RAW entwickelt wird. Und ich hab dazu auch (auf professioneller Ebene) gar keine Kompetenz.
Das ist erst mal lästig, da das Grading fertig sein muss. Nun worst case, das Grading wird geändert. Dann darf ich aber noch einmal im Idealfall nur eine Stunde ran (+Render), um das wieder anzupassen. Bei ein paar mehr Clips wird das extrem teuer.
Ich muss einfach im Kopf haben, dass jede Abteilung vom gleichen Material ausgeht. Solang ich aber mehr als Metadaten ändern muss, kriege ich ein Problem. Zumal ich ja auch nicht alles, was im Grading passiert, in Metadaten mitschicken kann; also, soweit ich weiß zumindest. Bin ja kein Colorist.
zu(2)
(*) Es ist eindeutig, dass die Daten direkt aus dem Sensor auf die Karte gesaugt werden, kein bearbeitender Chip etc liegt dazwischen. Man kann also sagen, es sind die rohen Sensorwerte.
(*) Man kann nicht sagen, was Canon auf dem Foto-Sensor an sich tut, um die Werte "nachzubessern". Dies bewegt sich aber im Bereich jedes Sensors - und die Antwort darauf findet man am Ehesten bei den Astrofotografen. Ich halte diese Korrekturen für "hier" unerheblich.
zu(3) Nein, es ist "das" RAW-Datenformat, das ein Bayersensor mit der Anordnung RG/GB-ausgibt. Mit raw2dng wird ein DNG ausgegeben, in welchem ein TIFF-Header vorgesetzt wird, die Daten haben sich - abgesehen von der Byterangfolge (BigEndian zu LittleEndian) - nicht verändert.
zu(4) Nein (raw2dng und raw2cdng). Ja bei dem anderen Converter (EyFrame), der hier vorgestellt wurde..
zu(5) Nun, es werden keine Metadaten mitgegeben. Aber einige essentielle (ColorCorrectionMatrix,Isomatrix zB) werden zB in raw2dng beachtet und in das DNG eingetragen.
Da MagicLantern Offen ist, kann jeder die Sourcecodes stöbern und da findet man auch alle Infos dazu. zB Hier die Headerdatei zum Raw-Modul.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
