Newsmeldung von slashCAM:
Hier geht es zur Newsmeldung mit Link und Bildern auf den slashCAM Magazin-Seiten:
Eyframe Converter unterstützt Magic Lantern Canon RAW
Antwort von iasi:
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 ...
Antwort von molch:
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 ;)
Antwort von AlexBardosch:
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.
Antwort von le.sas:
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
Antwort von Ab-gedreht:
Gibt es schon nen mac workflow?
Antwort von masterseb:
am mac:
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.
Antwort von WoWu:
und dann direkt in einen DnxHD oder Prores Codec 12 Bit exportieren
Gibt's noch nicht.
720p50 als 12 Bit gibt's unter AVC-U
Antwort von Joggel:
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 :-)
Liebe Grüsse Roger
Antwort von chmee:
Hier der Schreiberling von raw2cdng.
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.
mfg chmee
Antwort von WoWu:
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.
Antwort von chmee:
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)
mfg chmee
Antwort von WoWu:
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.
Antwort von chmee:
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.
Antwort von CameraRick:
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.
Antwort von WoWu:
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.
Antwort von CameraRick:
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.
Antwort von WoWu:
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.
Antwort von CameraRick:
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 ;)
Antwort von WoWu:
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.
Antwort von chmee:
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.
Antwort von CameraRick:
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.
Antwort von WoWu:
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.
Antwort von WoWu:
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.
Antwort von chmee:
@CameraRick - ..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.
http://www.phreekz.de/wordpress/2013/05 ... bei-adobe/
Die Frage ist also, wann wäre für Dich der Canon-Output in einem produktiv nutzbaren Status? Welche sind Deine vornehmlich genutzen Formate?
(ach ja, Huffman kann eine Kompression bis 1:2.5 hinkriegen, das wäre erstmal soo schlecht nicht).
mfg chmee
Antwort von CameraRick:
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.
Antwort von WoWu:
@chmee
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.
Antwort von CameraRick:
@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.
Antwort von chmee:
@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..
mfg chmee
Antwort von CameraRick:
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".
Antwort von WoWu:
@chmee
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.
Antwort von chmee:
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..
mfg chmee
Antwort von WoWu:
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 ?
Antwort von CameraRick:
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.
Antwort von chmee:
zu(1) ich sag erstmal ja.
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.
mfg chmee
Antwort von WoWu:
Danke für die Antwort.
Aber in 3) passiert das doch genau, dass ein Konverter das Format interpretiert und es als Tiff in einem DNG ausgibt.
Das ist doch genau der schwache Punkt der ganzen Kette, weil die Werte interpretiert und neue Werte aufgesetzt werden, ohne dass Metadaten Berücksichtigung finden und auch keine sensorspezifischen Render"Hints" übergeben werden.
Und meistens wird das De-Bayering in solchen Konvertern für TIFF gleich mit gemacht, weil man sonst noch ein Zwischenformat braucht. Denn bitonal kommt das da ja nicht raus.
Wie sehen denn die Filegrössen an der Stelle aus ?
Sorry, dass ich so nachfrage, aber ich versuche, mir ein Bild zu machen, was da eigentlich passiert um einen Eindruck zu bekommen, was hinten rauskommt.
Übrigens mit den Vorarbeiten für die Sensorkorrektur " nur für Astroleute" stimme ich nicht überein.
Wir hatten mal ein Sensormodul von Vison Research, wo die Routinen nicht alle implementiert waren.
Das hat aber ganz merkwürdig ausgesehen. Das hat 'ne Weile gedauert, bis wir die Ursache hatten, aber das war nix nur für Astrofotografen.
Antwort von chmee:
Nein.
DNG ist ein TIFF. TIFF ist ein Container. TIFF kann alles zwischen Schwarz/weiß und 32Bit/Kanal tragen, ob YUV, RGB, LaB oder Senseldefinitionen, wie sie im Bayer zugegen sind. Im Container stecken die unberührten RAW-Daten des Sensors, welcher im Header beschrieben wird, Anzahl, Lage, Ausrichtung der Bayer-Sensel. Da ist Nix umkonvertiert. Zusätzlich wird noch die Colormatrix hinzugefügt, der Whitelevel und der Blacklevel.
Um es jetzt nochmals positiv zu beschreiben -> Zwischen Sensorausgabe und Datei, die auf dem Rechner liegt, ist an den Daten noch Nix passiert.
Dieses Sensormodul von VisionResearch war ohne Chip? Der reine Sensor, den ihr ausgelesen habt?
mfg chmee
Antwort von WoWu:
Aber beim besten Willen, es ist doch Jacke wie Hose. Raw-Dateien sind im Prinzip alles Container-Formate.
Der Unterschied hier ist nur, dass die original RAW Daten vom Converter interpretiert und durch ein eigenes Format ersetzt.
Dabei werden die Inhalte ausgetauscht und durch Daten aus eigener "Gewinnung" ersetzt, weil diese Daten entweder im Originalsatz nicht zur Verfügung standen, verschlüsselt waren oder sonstwie nicht zu bekommen.
DNG ermöglicht es zwar OPTIONAL, die original-Datei zu embadden, um ggf. auf das Original später zuzugreifen, erzeugt aber in jedem Fall ein eigenes DNG Format, das mit eigenen Daten, ausgestattet ist.
Das betrifft in erster Linie Farbprofile und Spektrumsunterschieden, wo Adobe munter seine eigenen einsetzt.
Ich kann mir aber gut vorstellen, dass Firmen wie Cannon oder Nikon, oder Sony & Co genauer darüber Bescheid wissen und mehr herausholt, als jene, die die Formate bei Adobe, Apple und Corel zu rekonstruieren versuchen.
Fakt ist, dass das Originalformat nicht benutzt werden kann, weil alle Infos fehlen, es zu bearbeiten. Daher wird das Format ersetzt. DNG ist also streng genommen ein "pseudo"-RAW, mit vielen Adobe Anteilen.
Mag sein, dass eine Entwicklung auf einem Adobe Programm ganz gut funktioniert. Aber was ist mit einer Entwicklungssoftware eines andern Herstellers?
Es ist ja prinzipiell gegen DNG nicht einzuwenden, ganz im Gegenteil. Es wird nur zur Wundertüte, wenn der Kamerahersteller es nicht erzeugt weil ein Grossteil der Daten nur geschätzt werden.
Dieses Sensormodul von VisionResearch war ohne Chip? Der reine Sensor, den ihr ausgelesen habt?
Das sind komplette Sensoreinheiten incl. der dazugehörigen Elektronik, die man in den Kameras austauschen kann .
Die "leben" aber nicht allein, sondern nur mit der Kamera.
Antwort von chmee:
raw2cdng ist in version 1.1.1 raus.
http://www.phreekz.de/wordpress/2013/06 ... inema-dng/
mfg chmee
Antwort von WoWu:
Tja, aber das ist genau die Interpretation, von der ich oben gesprochen habe:
blacklevel, whitelevel, colormatrix read from rawdata
lowering whitelevel by 15% – maybe a helper for pink highlights
if blacklevel wasn’t found in raw – it turned zero – fixed that to 2037
blacklevel for 12bit was too high (/2 -> /4)
Da werden keine RAW Daten übernommen, sondern interpretiert.
Das mag sich jetzt von der Interpretation des ADOBE Programmes unterscheiden, aber im Prinzip sind es re-engineerte Daten.
Antwort von chmee:
WoWu, für unseren Dialog sollten wir doch mal festhalten, wie wir welchen Teil des Datensatzes beschreiben.
(A) Die RAW-Daten sind die Sensordaten. Nicht mehr, nicht weniger.
(B) Die Metadaten sind beschreibende Attribute, um die RAW-Daten konsistent und eben nicht zufällig zu erhalten.
(*) Blacklevel wird wie in quasi jeder Sensorbauart im nichtbelichteten Schwarzbereich gemessen. Dass ich ihn bei einem Canon-Sensor mit 14Bit-Ausgabe auf pauschal 2037 setze, ist kein Zufall, sondern ein guter Wert -> wenn der Eintrag fehlgeschlagen ist.
(*) Whitelevel als Maxima der "Sensorfüllung" ist noch nicht in der Software umgesetzt, aber mit 15.000 bzw. 13.000 (für die 6D) als ebenfalls sehr funktionierende Werte anzusehen.
(*) Dass ich bei 2bit Truncating den Schwarzwert genauso um 2Bit herabsetze, ist ebenfalls kein Zufall.
(*->*) Vor Allem, es sind alles konsistente Werte, die das Arbeiten ohne Überraschungen oder Datenverluste erlauben.
Was mich hierbei nervt ist, dass Du scheinbar glaubst, die Coder und Developer in den anderen Buden seien alles Sensorgötter. Dem ist nicht so - ich kenne doch die Coder - Spätestens bei Blackmagic haben sie ihren Verkaufs-Go gegeben, als die Daten aussahen und auf der Platte landeten. Und dennoch hege ich großen Respekt für Arri oder Sony-Broadcast, Jene, schlicht, weil sie viele Jahre damit zu tun haben.
Wenn Du Dir Deine Skepsis erhalten möchtest, bitte sehr, aber nicht mit mir - Du bist dann einfach im falschen Thread, denn zum CDNG-Wandler oder zum Eyeframe-Converter kannst Du scheinbar NIX beitragen.
mfg chmee
Antwort von WoWu:
Will ich auch gar nicht, nur RAW Daten als Kameradaten anzupreisen ist auch etwas fremd, nachdem man sie im Konverter nach Gusto verbogen hat.
Wie gesagt ... es gibt RAW Daten und solche zweiter Wahl, also einfach nur Interpretationen.
Und bei dem Hack kommen eben nur Daten zweiter Wahl heraus.
Nicht mehr und nicht weniger, ... wie Du so schön angemerkt hast.
Kritik und Analyse scheint wohl nicht bei der Hacker-Euphorie so willkommen zu sein.
Antwort von chmee:
im Konverter nach Gusto verbogen..?
Rohe Sensordaten Daten zweiter Wahl?
Ich schaffs echt nicht mehr, Dir zu folgen.
Der wichtige Punkt ist: Die Daten sind konsistent, es gehen keine Daten verloren, die Nutzbarkeit ist vollumfänglich gewährleistet..
Kritik und Analyse scheint wohl nicht bei der Hacker-Euphorie so willkommen zu sein.
Es geht nicht um Euphorie -> Deine Analyse ist zu oft zu wackelig. Wenn Du ein Sensormodul und das Fehlen der richtigen Codes als Diskussionsgegenargument nennst, weiß ich, dass Du keine Ahnung hast, wie die Daten in einem Canonbody geführt werden, und wo sie Magiclantern abgreift. Mit Sicherheit auch nicht, woher die Colormatrix kommt, und warum die Black und Whitelevel scheinbar doch passen.
Passt das auch so halbwegs?
Du Recht, ich Ruhe. besser?
Antwort von WoWu:
Viel Labern und keine Aussage und nun zu kommen und zu sagen, dass wir, weil wir die Vorbezeichnung "Cinema" vom DNG weglassen, von ganz andern Dingen reden fällt Dir vermutlich auch nur so als Hilfsargument noch ein, weil sachbezogene Argumente fehlen.
Fakt ist, dass es sich weder um die original KameraRAW-Daten handelt, weil sie nach Gusto von Euch im Konverter verbogen werden (nach dem Motto: Schwarz nicht gefunden, also nehmen wir mal diesen Wert) und dass offenbar auch alle Metadaten aus der Kamera fehlen und Ihr im Converter ebenso nach Gusto Parameter setzt.
Deswegen sind das interpretierte Daten und Werte.
Eben zweite Wahl.
Ist ja nicht schlimm, wem die Qualität ausreicht, kann sie ja benutzen.
Ich weiss also gar nicht, was Du Dich aufregst.
Bastelergebnisse sind ja manchmal auch ganz hübsch.
Habt Ihr mal die Nutzungsbedingungen für DNG von Adobe angeschaut ?
Ob die das so toll finden, was Ihr da aus dem Format macht ?
Offenes Format heisst ja nicht auch zugleich rechtsfreier Raum.
Antwort von chmee:
Wir? Du und wer?
Grundgütiger.
WAS SIND DENN ORIGINAL-RAW-DATEN AUS DER CANON?
Die Bilddaten (besser Sensordaten) sind - ohne einen Augenmerk auf die Metadaten zu legen - ORIGINAL! Und Metadaten zu den Sensordaten gibt es zu Genüge aus dem Fotobereich. Wir interpretieren sie, als ob es Fotos wären, wenn es um Metadaten wie Schwarz/Weisswert, Colorcorrection oder BayerGreenSplit etc pp geht. Dazu gibt es zu Genüge sehr fähige Menschen, die nicht für die Anderen arbeiten.
Wenn ich mich an die letzte Produktion erinnere, wo eine Arri Alexa als Datenproduzent für einen 10Bit-HD/SDI-Stream-Record fungierte, dann spüre ich auch hier das "Echte" irgendwo wegschwimmen - da müsste ja auch mindestens ein Debayering nach YPbPr oder RGB stattfinden..
Habt Ihr mal die Nutzungsbedingungen für DNG von Adobe angeschaut ?
Dann bitte ich doch mal um nen Passus, den Du mir gerade als kritisch vorsetzen möchtest.. Ein offenes Format, dass (Zitat Adobe-PDF)
The format is unencrypted and free from intellectual property
encumbrances or license requirements.
Euphorie und Recht hin oder her - Du glaubst den Daten nicht, ich belächle Deine Unterscheidung, wann Daten echt sind. Trennen wir uns bitte im "Normalen" und belassen wir es dabei.
Antwort von WoWu:
Wir interpretieren sie,
.... siehst Du, meine Rede.
In einem andern Thread ging es auch darum, ob sie kommerziell überhaupt zu gebrauchen sind .... und worauf die Artefakte darin zurückzuführen sind.
Gründe sind klar.
Schliesslich ist dies ja nicht der einzige Thread zu dem Thema.
Aber bastelt mal weiter... schliesslich ist der Weg das Ziel.
Antwort von chmee:
harhar. voll geil, Einzelbilder eines Films als Fotos-RAWs interpretiert. Ich gestehe, Euer Hochwürden, das ist nur eine Interpretation. Wie das nur die anderen Kameras machen..
Gründe sind klar.
Aha. Na dann, bitte mal verlinken.
Zu guter Letzt, ich warte noch auf den Link zu den CinemaDNG-Nutzungsbedingungen.. So viel Substanz lieferst Du nun auch nicht.
Antwort von WoWu:
Aber lesen wirst Du dann alleine können... oder auch nicht ?
Antwort von chmee:
Den Link zu den CDNG-Bedingungen hätte Dich weniger Aufstand gekostet. Keine Sorge, die anderen Diskussion finde ich auch alleine.
