Infoseite // Kinefinity: Neuer komprimierter RAW Codec und Kinecolor 2

Newsmeldung von slashCAM:


Kinefinity hat auf der BIRTV 2014 Messe in Peking einige Software-Updates vorgestellt




Hier geht es zur Newsmeldung mit Link und Bildern auf den slashCAM Magazin-Seiten:
Kinefinity: Neuer komprimierter RAW Codec und Kinecolor 2




Antwort von WoWu:

Tja, und welche Software unterstützt das RAW Format ?
Das ist auch genau das, was gebraucht wird:
Ein weiteres proprietäres RAW Format, das kein anderer Hersteller unterstützt.



Antwort von Frank Glencairn:

Das wird jeden Tag besser und interresanter.



Antwort von rush:

Der Markt ist in Bewegung... mir gefällts.

Mit dem Codec und dessen möglicher Unterstützung habe ich mich dagegen noch nicht weiter beschäftigt.



Antwort von Valentino:

Naja der Markt ist aber gerade in Europa eher durch BM in Bewegung gekommen und Kinefinity tut sicht trotz einem "Vertrieb" in Berlin recht schwer.

Meiner Meinung sind die von Kinefinity deutlich zu spät in dem Segment aktiv geworden und müssen gerade schauen was nach Sony, BM, Red und Arri noch so vom Kuchen übrig ist.



Antwort von iasi:

Interessant - aber an der Software-Unterstützung wird es sich letztlich zeigen, ob der Raw-Codec etwas taugt.



Antwort von WoWu:

Ich habe auch -beim besten Willen- noch nicht die Vorteile dieser Kamera erkennen können.



Antwort von WoWu:

Interessant - aber an der Software-Unterstützung wird es sich letztlich zeigen, ob der Raw-Codec etwas taugt. Ich befürchte nicht denn selbst wenn ADOBE ihn durch CinemaDNG unterstützen sollte, wird das nur wieder eine Interpretation, wird also nicht die Sensorqualität widerspiegeln sondern lediglich so aussehen, wie auch die andern ADOBE DNG Schätzungen.



Antwort von iasi:

da es ja sowieso so aussieht, dass Kinefinity Red kopiert, könnten sie ja vielleicht ebenfalls den Softwareherstellern zuarbeiten - sinnvoll wäre dies allemal ...






Antwort von WoWu:

Die sollten lieber zusehen, dass sie sich keinen Inportverbot damit einhandeln, wenn das so sein sollte.



Antwort von Valentino:

Wenn Kinefinity von Red kopiert dann würden die Produkte doch etwas anders aussehen.

Nur weil eine Kamera in RAW aufzeichnet und dieses komprimiert, hat das erst mal nichts mit Red zu tun.
Das habe vor Red schon genügend andere Firmen so gemacht und ein echtes Patent auf komprimierte RAW Aufzeichnung hat Red ja auch nicht.



Antwort von iasi:

... also ich sehe mehr Ähnlichkeiten als Unterschiede ... der neue Raw-Codec erinnert doch schon auch sehr an Red ...



Antwort von Valentino:

Du hast keine Ahnung wie der RAW Codec arbeitet und auch von der Form sieht die oben gezeigte KineMINI 4k eher aus wie ein Brotkasten aus ;-)

Dazu sind die Kine Kameras von ihrer Firmware eher mit den ersten R1 Modellen zu Vergleich und ein Software wie RedCinePro wird Kinefinity die nächsten Jahr auch nicht wirklich liefern können.



Antwort von iasi:

Du hast keine Ahnung ... Mann Mann - lern mal etwas Benimm, denn sonst wirst du"s mal nicht weit bringen ...



Antwort von Valentino:

Was soll das den, nicht mal Wolfgang hat einen Schimmer davon was und wie die bei Kinefinity ihr RAW komprimieren aber du willst sofort eine Ähnlichkeit mit dem RED Codec gesehen haben, nur weil dieser auch komprimiert.

Hast du irgendwelche Whitepaper oder woher kommt deine Gewissheit?

Kannst du uns dann auch die Lottozahlen vorhersagen?



Antwort von iasi:

ok - Missverständnis - ich entschuldige mich - wenn du es so gemeint hattest.

Dennoch ist es ein eigener Codec - wie WoWu richtig bemerkt hat - und ebenso verfährt auch Red.

Wenn es dann so läuft wie z.B. auch mit komprimiertem DNG oder DNG allgemein bei Adobe, dann wird das eher eine maue Angelegenheit. Und dabei geht es doch gar nicht um die Qualität und die technische Umsetzung des Codecs.

Das Konzept der Kinefinity gleicht doch recht auffällig in vielen Punkten denen der Red-Cams. Nun folgt eben noch komprimiertes Raw. Das stelle ich übrigens nur mal fest und will es gar nicht wertend verstand wissen.



Antwort von WoWu:

Nur liegt eben genau da das Problem.
Du kannst eine tolle Kamera bauen und Dir wahnsinnig viel Mühe geben mit der Auswahl der Filterfarben und der Harmonisierung des Sensors, wenn das RAW Format, das Du an den Ausgang stellst, falsch behandelt wird.
Deswegen ist es so wichtig, dass Firmen solche Container wie CINEMA DNG aktiv unterstützen, denn dann geben Sie alle zur Bearbeitung dringend erforderlichen Daten an den Container weiter, aus dem sich das Entwicklungsprogramm dann die Parameter, z.B. für das De-bayering zieht und so auch ein adäquates Bild erstellen kann.
Unterstützt der Hersteller das nicht und/oder gibt auch nichts weiter über sein RAW Format bekannt, kann das Entwicklungsprogramm nur anfangen zu schätzen.
Dann wäre mir persönlich ein LOG Signal lieber, in dem die Kamera alle relevanten (und ihr vom Hersteller bekannten) Daten intern verarbeitet.
Wenn jetzt so ein Hersteller nun wieder ankommt und sagt : Hier ist RAW, macht damit, was ihr wollt, könnte man ihm eigentlich nur empfehlen, sich das Format in die Haare zu schmieren denn RAW ist nix wert, ohne die Parameter, die man für die Entwicklung braucht.
Deswegen hatte ich oben auch geschrieben, dass das genau das ist, was die Welt jetzt braucht ... ein weiteres, proprietäres RAW Format.



Antwort von iasi:

Hier hat es Red recht gut gemacht und die enge Kooperation mit den Softwareherstellern gesucht.
Sollte Kinefinity ähnlich verfahren, kann das durchaus etwas werden - ansonsten ist es eben so, wie WoWu es beschreibt.

Hier kann ich Red wirklich loben, denn sie belassen es eben nicht nur bei der Hardware inkl. Firmware, sondern stecken viel Energie in den Codec und den Workflow.






Antwort von TheBubble:

Deswegen ist es so wichtig, dass Firmen solche Container wie CINEMA DNG aktiv unterstützen, denn dann geben Sie alle zur Bearbeitung dringend erforderlichen Daten an den Container weiter, aus dem sich das Entwicklungsprogramm dann die Parameter, z.B. für das De-bayering zieht und so auch ein adäquates Bild erstellen kann. Ich würde weiter gehen und sagen, dass im Grunde ein leicht umzusetzendes RGB-Intermediate-Format mit ich nenne es mal "erweitertem Farbraum mit HDR" gebraucht wird. Dann muss ein Programm (Schnittsoftware, Farbkorrektur, Effektsoftware, usw.) nur mit diesem einem Format umgehen können, die Umwandlung von RAW nach Intermediate und von Intermediate in ein Distributionsformat kann mit spezialisierten Konvertern geschehen.

Das erlaubt meherer Vorteile: Die Kameras sind in der Wahl des RAW-Formats völlig frei. Im Konverter kann man z.B. ein geeignetes De-bayering-Verfahren wählen bzw. mit mehreren experimentieren. Das Intermediate-Format komprimiert zwar geringer, ist aber universell und sollte vor allem leicht umzusetzen sein. Anwendungsprogramme brauchen sich um die Details der RAW-Formate oder sonstiger Eingabe und Ausgabe.-Codecs (MPEG-2, H.264, H.265, ...) nicht explizit kömmern, das tun spezialisierte Konverter.



Antwort von WoWu:

@Iasi
Nennen wir es anders... sie gehen einen Kompromiss ein indem sie nicht die realen Sensortasten als RAW herausgeben sondern eine sehr flache Codierung unter der Bezeichnung RAW bedienen.
Du bekommst bei RED keinen einzigen individuellen Sensorwert zu fassen sondern nur ein komplettes Videosignal.
Aber die Bezeichnung RAW ist nicht standardisisert und daher auch nicht abgegrenzt, was es eigentlich ist und man kann jedes Signal als RAW bezeichnen, ziemlich egal, wie es aussieht.

@TheBubble

Wir brauchen nur eine Standardisierung des RAW Formates.
Die SMPTE ist da ja unter 2065-1 (ACES) dran.
Was wir definitiv nicht brauchen, ist einen neuen Intermediate, der dann nur so nach Gusto und Geschäftslage von Firmen gepflegt wird, also ADOBE, APPLE oder Grass Valley und dann womöglich pro Anwendung vom Verbraucher bezahlt wird, also SONY.



Antwort von TheBubble:

Wir brauchen nur eine Standardisierung des RAW Formates.
Die SMPTE ist da ja unter 2065-1 (ACES) dran. Wie man es dreht und wendet würde das aber immer nur den aktuellen Stand der Dinge abbilden können und Neuentwicklungen unter Umständen im Weg stehen. Auch läuft man Gefahr, dass der Aufbau des Formats schnell sehr kompliziert wird, wenn man versucht dem entgegenzuwirken.
Was wir definitiv nicht brauchen, ist einen neuen Intermediate, der dann nur so nach Gusto und Geschäftslage von Firmen gepflegt wird, also ADOBE, APPLE oder Grass Valley und dann womöglich pro Anwendung vom Verbraucher bezahlt wird, also SONY. Das Format muss natürlich frei verfügbar, robust und vergleichsweise leicht umzusetzen sein. Vom Grundgedanken ähnlich OpenEXR, nur eben nach Möglichkeit einfacher aufgebaut.



Antwort von iasi:

Eine Standardisierung des RAW Formates?

Ist die dann überhaupt möglich, wenn man eine Komprimierug vornehmen will?

Erhält man die reinen Sensordaten denn nicht nur in einem unkomprimierten Raw-Format?

Klar ist RedRaw ein Kompromiss - ich denke auch deshalb kocht Red sein eigenes Süppchen und versucht möglichst weit hinein in den Workflow die Kontrolle behalten zu wollen.
BMD hat aber wohl in Resolve einen eigenen DeBayer für RedRaw, wenn ich eine Bemerkung in reduser vom Red-Boss richtig interpretiert habe - darin lobt er eben diesen DeBayer.



Antwort von WoWu:

@The Bubble

ich weiss nicht, ob sowas wie openEXR nicht viel zu weit hinten ansetzt.
Speziell in Anbetracht dessen, dass Bilder zukünftig auf die unterschiedlichste Art und Weise entstehen, was zunächst erst einmal das nachlaufende Processing betrifft.
Daher finde ich es auch von den Chinesen ziemlich mutig, zu dieser Zeit noch mit einem weiteren RAW aufzutauchen.
Ich denke nach wie vor, dass wir einen Paradigmenwechsel im Pildprozessing erleben.
Wir werden im Hinblick auf relativ kleine Sensorflächen bei relativ stark anwachsenden Auflösungsanforderungen gar nicht umhin kommen, zukünftig mit den (wirklich) rohen Luminanzwerten der Sensoren umzugehen.
Der eigentlichen Pixelbearbeitung kommt zukünftig wesentlich mehr Bedeutung zu als es jetzt mit dem De-bayering ist.
Dem (positiv) entgegen wirkt, dass wir u.U. den ganzen Sensor gar nicht mehr auslesen werden und so die Datenmenge (ohnehin) drastisch reduziert wird, sodass sich an der Stelle die Frage nach der Notwendigkeit einer Kompression gar nicht mehr stellt.
Ich glaube, dass Bildgestehung, wie wir sie derzeit betreiben, von endlicher Dauer ist.
Nur dann kommen wir eben um eine Definition des Datenfiles nicht herum und da würde ich mich allemal besser in einem solchen normgebendem Gremium wie der SMPTE fühlen, als in einer Programmierbude, die irgend einer Firma angeschlossen ist.



Antwort von Frank Glencairn:

@ IASI

Der Sensor liefert zunächst mal ein unkomprimiertes Graustufen Bild - das kann man natürlich mit einem entsprechenden Algorythnus komprimieren (wie RAR, ZIP usw.) und wieder verlustfrei auspacken.



Antwort von TheBubble:

ich weiss nicht, ob sowas wie openEXR nicht viel zu weit hinten ansetzt. Ich muss jetzt etwas weiter ausholen, damit die Motivation für ein neues einfaches RGB-Intermediate-Format klar wird:

Die Ausgangssituation ist, dass ein Format benötigt wird, in dem einer Verarbeitungssoftware die Pixeldaten zugeführt und in welchem sie wieder ausgegeben werden können. (Um die Daten mit anderen Programmen weiter verarbeiten zu können). Es wäre gut, wenn das Format auch zunächst "illegale Farben" erlaubt und zumindest in einem angemessenen Umfang HDR-fähig ist.

Heute sind Schittprogramme meist "monolithisch", d.h. sie verstehen unzälige Eingabe- und Ausgabeformate, darunter auch viele komplizierte Formate. Große Hersteller können das derzeit bewältigen: Sie lizensieren die nötigen Programmbibliotheken und falls erforderlich auch die nötigen Patente.

Kleine spezialisierte Tools haben hier das Nachsehen.

Kommen neue Kameras mit neuen Formaten auf den Markt oder gibt es Neuentwicklungen z.B. im Bereich des De-bayerings, dann müssen die Import-Funktionen immer wieder erweitert werden.

Es macht aber wenig Sinn, wenn jedes Programm eigene Import-Funktionen für alle RAW- und sonstigen Formate mitbringen muss und alle Aufbereitungsschritte selbst umsetzen muss. Das ist nicht nur feheranfällig, sondern auch sehr aufwendig.
Der eigentlichen Pixelbearbeitung kommt zukünftig wesentlich mehr Bedeutung zu als es jetzt mit dem De-bayering ist. Das sehe ich eben auch so. Grade deswegen sehe ich inzwischen einen Nutzen in einem geeigneten Zwischenformat.

Ich würde im Prinzip die folgende Vorgehensweise favorisieren:

Spezialisierter Konverter:
{Spezialformat, RAW, YCbCr-4:2:2-irgendwas, usw.} -> Aufbereitungs-Engine -> Intermediate-RGB-4:4:4-Format.

Programme: Intermediate-RGB-4:4:4-Format -> Bearbeitungsschritte -> {Intermediate-RGB-4:4:4-Format oder Ausgabe-Formate wie H.264. MPEG-2, usw.}

Das würde die Last des Imports aus den Programmen in einen speziellen Konverter auslagern, der gerne die Optionen anbietet länger zu rechnen, aber dafür ein Optimum herauszuholen. Die anderen Programme können sich dann auf das konzentrieren, was sie eigentlich tun wollen. Es kann bei dieser Aufteilung auch Programme geben, die sich auf einen qualitativ möglichst guten Export in ein Distributionsformat spezialisieren.



Antwort von iasi:

@ IASI

Der Sensor liefert zunächst mal ein unkomprimiertes Graustufen Bild - das kann man natürlich mit einem entsprechenden Algorythnus komprimieren (wie RAR, ZIP usw.) und wieder verlustfrei auspacken. Das stimmt natürlich - nur wird doch meist nicht verlustfrei komprimiert, um höhere Komrimierungsraten erzielen zu können - visuell verlustfrei heißt es dann immer.

Die hohen Datenraten bei hoher Auflösung sind eben ein Problem und erzwingen Kompromisse.
Nach meinem Gefühl hat Red einen recht guten Kompromiss gefunden.



Antwort von WoWu:

Tja, das wäre natürlich eine konventionelle Methode, die aber (so, wie ich das im Augenblick sehe) über den ganzen Weg ziemlich viel rechnet (mit den bekannten Nachteilen).
Meine Version wäre, weil das Ziel einer optisch scharfen Projektion ohnehin an die Grenzen stösst, entweder nur noch einen geringen, unregelmässigen teil des Sensors abzutasten und dann durch Faltung das Bild zu errechnen.
Das hätte den Vorteil der geringeren Datenmenge & Speicherung und würde den Rechenprozess ganz nach hinten verlagern, wo nach Bedarf Aufwand (oder Zeit) zur Verfügung steht. Hat aber den Vorteil, dass weder Farbräume beschrieben werden müssen, in denen kodiert wurde, noch irgendwelche andern arbeitsspezifischen Parameter.
Wenn dann die Kamera in der Lage ist, SDKs abzuspeichert, also Settings für Exposure, White Balance, Tint, Contrast...usw. dann liesse sich daraus ein Vorab Bild erzeugen und wenn verändert auch ein Metadatenfile als Render-Start . Solche SDKs gemeinsam mit den Metadaten des spezifischen Sensors ergeben sämtliche Informationen für einen Proxy Weg in einem beliebigen Format als auch die Ausgangsbasis für ein Rendern bei geringsten RAW dareinmengen.
Ich glaube, die Zeit des "realen Bildes" im Arbeitsprozess ist ebenso beendet, wie die optischen Reproduktionsmöglichkeiten und damit der herkömmlichen (linearen) Bildbearbeitung.
Daher glaube ich auch, dass die Entwicklung eigentlich schon solche Normierungsverfahren (eigentlich) überholt hat.
Denn selbst wenn ACES 30 Blenden mit je 1024 Werten in einem wirklich riesigem Farbraum standardisiert, geht das eigentlich schon wieder an dem vorbei, wie demnächst Bilder gerechnet werden.
Ich befürchte, da ist die Zeit schneller als die Verfahren.
Aber auf die Art und Weise bleibt es dann wenigstens spannend.






Antwort von iasi:

Ich würde im Prinzip die folgende Vorgehensweise favorisieren:

Spezialisierter Konverter:
{Spezialformat, RAW, YCbCr-4:2:2-irgendwas, usw.} -> Aufbereitungs-Engine -> Intermediate-RGB-4:4:4-Format.

Programme: Intermediate-RGB-4:4:4-Format -> Bearbeitungsschritte -> {Intermediate-RGB-4:4:4-Format oder Ausgabe-Formate wie H.264. MPEG-2, usw.}

Das würde die Last des Imports aus den Programmen in einen speziellen Konverter auslagern, der gerne die Optionen anbietet länger zu rechnen, aber dafür ein Optimum herauszuholen. Die anderen Programme können sich dann auf das konzentrieren, was sie eigentlich tun wollen. Es kann bei dieser Aufteilung auch Programme geben, die sich auf einen qualitativ möglichst guten Export in ein Distributionsformat spezialisieren. Nun - wenn ich an Red denke, gibt es die Möglichkeit, in Redcine in ein anderes Format zu exportieren - dabei ist dann sogar ein Adv. DeBayering möglich ...
Wie soll denn dieses "Intermediate-RGB-4:4:4-Format" aussehen? Es gibt doch schon jetzt Intermediate-Formate, die von ziemlich allen Programmen verarbeitet werden können ... nur kämpft man dann eben wieder mit enormen Datenmengen.
Da erscheint es mir eigentlich leichter, wenn ich im komprimierten Raw-Format bleibe und möglichst spät in ein anderes Format wandle - eventuell gar erst bei der Ausgabe.



Antwort von iasi:

Meine Version wäre, weil das Ziel einer optisch scharfen Projektion ohnehin an die Grenzen stösst, entweder nur noch einen geringen, unregelmässigen teil des Sensors abzutasten und dann durch Faltung das Bild zu errechnen. Ist das dann nicht auch nur eine Form von Komprimierung?



Antwort von TheBubble:

Tja, das wäre natürlich eine konventionelle Methode, die aber (so, wie ich das im Augenblick sehe) über den ganzen Weg ziemlich viel rechnet (mit den bekannten Nachteilen). Der Konverter muss am meisten rechnen und nur der Konverter braucht das Wissen über die diversen Eingabeformate. Das macht aber Sinn: Alle nachfolgenden Programme und Arbeitsschritte sind davon befreit und nutzen ein schneller und einfacher zu verarbeitendes Format, das trotzdem mehr Flexibilität bietet, als viele gängige Eingabeformate.

Es wäre sicher auch möglich, im Konverter zuerst schnell und qualitativ passabel zu rechnen und die Aufnahmen später durch hochwertige Varianten zu ersetzen. (Ggf. auch nur diejenigen, welche tatsächlich benötigt werden.)
Hat aber den Vorteil, dass weder Farbräume beschrieben werden müssen, in denen kodiert wurde, noch irgendwelche andern arbeitsspezifischen Parameter. Das mit den Farbräumen könnte man im Zwischenformat ähnlich wie scRGB handhaben. Oder wie OpenEXR.
Ich glaube, die Zeit des "realen Bildes" im Arbeitsprozess ist ebenso beendet, Wenn Du mit "real" herkömliches RGB meinst, dann ganz sicher noch lange nicht. :-)



Antwort von WoWu:

Nein mit real meinte ich nicht RGB. Was Du hinterher rausrechnest ist völlig offen und ob Du im proxy mit RGB arbeitest ist auch irrelevant.
Ich glaube nur nicht mehr daran, dass wir hohe Frequenzen noch lange durch die gesamte Systemkette schleifen und darauf bestehen, sie an jedem Punkt sichtbar machen zu können.
Ich glaube, dass wir die hochfrequenten Anteile der Bilder erst im Renderprozess erstellen.
Auch, weil mittlerweile der Workflow dafür bekannt und etabliert ist.
Ich glaube an keinen Intermediate mehr auf lange Sicht.

@Iasi
Ja, wenn Du so willst ist natürlich jede Art von Unterabtastung eine Datenreduktion.
Mit dem, was wir so unter Kompression verstehen, hat das allerdings nicht wirklich was zu tun.



Antwort von iasi:

Der Konverter muss am meisten rechnen und nur der Konverter braucht das Wissen über die diversen Eingabeformate. Das macht aber Sinn: Alle nachfolgenden Programme und Arbeitsschritte sind davon befreit und nutzen ein schneller und einfacher zu verarbeitendes Format, das trotzdem mehr Flexibilität bietet, als viele gängige Eingabeformate.
was sollte eigentich so ein Universal-Konverter bringen - im Vergleich zu den speziell von den Kameraherstellern abgestimmten Lösungen, wenn dann doch wie bisher in eine aufgeblähtes Zwischenformat gewandet wird?



Antwort von TheBubble:

Ich glaube nur nicht mehr daran, dass wir hohe Frequenzen noch lange durch die gesamte Systemkette schleifen und darauf bestehen, sie an jedem Punkt sichtbar machen zu können.
Ich glaube, dass wir die hochfrequenten Anteile der Bilder erst im Renderprozess erstellen. Mein Intermediate-Format könnte natürlich auch zusätzlich Proxie-Auflösungen bereithalten.
Ich glaube an keinen Intermediate mehr auf lange Sicht. Würde ich gerne auch so sehen, aber es gibt neben technischen Erwägungen (leider) eben auch eine große Menge nicht technischer Gründe, die für ein Intermedia-Format sprechen.

Selbst dann, wenn man erstmal nur Dateien aus Comsumer-Geräten verarbeiten will.



Antwort von WoWu:

:-)
Die Einsicht erschliesst sich mir leider nicht denn das würde bedeuten, dass man das gesamte Prozession nach vorne legt und man sich jeden Vorteil eines RAW Formates beraubt.
Das wäre für mich ein stark nach Rückwärts gerichtetes Verfahren.
Und ich denke, die Erfordernisse sprechen eigentlich stark dagegen, wenn man sowohl die spatiale, als auch die qualitative und zeitliche Auflösungserweiterung in Betracht ziehen will.
Willst Du wirklich demnächst mit 120fps in 12 Bit 4:4:4 mit 4 oder 8 k in einem Intermediäre (mit kompletten Bildern) umgehen ?
Das glaube ich noch nicht. Das wird immer ein Proxy werden. Schon allein aus Kostengründen.
Die Frage ist dann eben nur, wie sieht das RAW Format dafür aus.
Aber an Intermediate glaube ich nicht.
Aber lass es uns abwarten.
Jedenfalls finde ich für den ersten Schritt das, was die SMPTE da macht schon deutlich besser als den Ansatz von ADOBE, wobei das aber auch aus der Zeit gefallen ist. Als es kam, war es noch ganz attraktiv, aber es ist nicht mehr auf dem Stand, der heute nötig wäre, weil sie es über Jahre nicht gepflegt haben.
Das ist eben der Nachteil solcher Firmen-Standards.



Antwort von iasi:

Was Adobe macht, ist der richtige Weg - nativ von Anfang bis Ende - keine Proxy und keine Intermedia sind notwendig.
Schön wäre solch eine Verknüpfung auch mit anderen Programmen - hier wäre ein umfassender Standard wichtig, der eben weiter geht, als nur XML.

De Kamerahersteller entwickeln spezielle DeBayer für ihre Kameras und können dadurch das Maximum herausholen und Adobe integriert diese.

Ein Konverter für alle klappt doch eh nicht.

Wenn man das native Material schon in vergleichsweise handlicher Form also komprimiert vorliegen hat und für die Vorschau schlicht die Qualität einstellen kann, braucht es keine fetten Zwischenformate oder Proxys.



Antwort von WoWu:

Was Adobe macht, ist der richtige Weg - nativ von Anfang bis Ende - keine Proxy und keine Intermedia sind notwendig.
Schön wäre solch eine Verknüpfung auch mit anderen Programmen - hier wäre ein umfassender Standard wichtig, der eben weiter geht, als nur XML. Leider eine Sackgasse.
Das geht für die bisher "leichte Kost". De Kamerahersteller entwickeln spezielle DeBayer für ihre Kameras und können dadurch das Maximum herausholen und Adobe integriert diese. Eben nicht. ADOBE möchte es gern integrieren, aber viele Kamerahersteller lassen sich da nicht in die karten schau'n und ADOBE mach "Nase" und fängt an zu schätzen.
Mit dem entsprechend mageren Ergebnis. Wenn man das native Material schon in vergleichsweise handlicher Form also komprimiert vorliegen hat und für die Vorschau schlicht die Qualität einstellen kann, braucht es keine fetten Zwischenformate oder Proxys. Genau das ist der Ansatz und dazu kommt dann noch, dass die Render-Tools, die die eigentliche Qualität erzeugen, nicht mal vom NLE Hersteller sein müssen sondern je nach Qualitätsanspruch, ebenso wie jetzt auch die Codecs, von den Firmen kommen können, die die besten Implementierungen machen.
Für mich, deutlich der bessere Weg.






Antwort von TheBubble:

Die Einsicht erschliesst sich mir leider nicht denn das würde bedeuten, dass man das gesamte Prozession nach vorne legt und man sich jeden Vorteil eines RAW Formates beraubt. Der größte Vorteil ist aus Sicht vieler Anwender ja ohnehin nur die Möglichkeit einer umfangreicheren Farbkorrektur. Das würde man uneingeschränkt beibehalten.
Willst Du wirklich demnächst mit 120fps in 12 Bit 4:4:4 mit 4 oder 8 k in einem Intermediäre (mit kompletten Bildern) umgehen ? Ja. Das war die Idee.
Das glaube ich noch nicht. Das wird immer ein Proxy werden. Schon allein aus Kostengründen. Das Ganze wird natürlich verlustlos oder leicht verlustbehaftet ("visuell unmerklich") komprimiert. Aber Speicherplatz wird immer günstiger und wenn ein Film fertig ist, dann kann man die Intermediate-Files ja löschen.



Antwort von WoWu:

:-)) Ja. Das war die Idee. Boaaaaa.
Ich will ja nicht unken aber hast Du mal nachgerechnet ?
Da hast Du aber eine Workstion die nur noch aus speziellen DSPs mit dedizierten Algorithmen besteht und wenn sich was ändert tauscht Du Platinen ;-(
Das Update kommt dann immer per Postpaket



Antwort von TheBubble:

Was Adobe macht, ist der richtige Weg - nativ von Anfang bis Ende - keine Proxy und keine Intermedia sind notwendig. Das ist ein geeigneter Weg für große Hersteller, bei dem ohnehin alle Anwender möglichst im Ökosystem der eigenen Software bleiben sollen.

Viele kleine Anbieter spezieller Software können da jedoch schwer mithalten, schon weil es eben nicht so einfach möglich ist, z.B. mal eben H.264 für den Im- oder Export anzubieten.
De Kamerahersteller entwickeln spezielle DeBayer für ihre Kameras und können dadurch das Maximum herausholen und Adobe integriert diese.

Ein Konverter für alle klappt doch eh nicht. Wäre über ein breit unterstütztes Intermediate-Format möglich. Wenn ein universeller Konverter (aus welchen Gründen auch immer) nicht geht, können Kamerahesteller auch einen Eigenen bereitstellen.



Antwort von TheBubble:

Ich will ja nicht unken aber hast Du mal nachgerechnet ? Ja, klar. Für UHD sind das ca. 24M Subpixel/Frame.

Aber so besonders ist das ja gar nicht, in der Filmproduktion (VFX) wird das schon lange mit Formaten wie OpenEXR oder DPX praktiziert. Ich will das quasi auf weitere Bereiche ausdehnen und dafür ein leichteres, weniger universelles Format erschaffen.



Antwort von WoWu:

Wenn ein universeller Konverter (aus welchen Gründen auch immer) nicht geht, können Kamerahesteller auch einen Eigenen bereitstellen. Aber dann sind wir genau wieder da, wo wir heute stehen. Dann kann man auch das De-Bayering in der Kamera machen und muss erst gar keine metadaten herschaufeln.
Das war ja gerade die Idee von DNG, dass Hersteller ihre Metadaten in dem Container integrieren, sodass ein einheitlicher Conferier darauf zugreifen kann.
das hat ja (bis auf ein paar Firmen) nicht geklappt.
Und wenn ich die Unterstützung von Blackmagic für das SMPTE Projekt sehe, dann geht denen das DNG Konzept auch auf den Keks, weil es nicht funktioniert und man auch keine SDKs damit für die Kamera erzeugen kann.

Schau Dir das SMPTE Projekt mal an. Das kommt Dir, ohne Intermediate, wahrscheinlich schon sehr nahe.



Antwort von iasi:

Leider eine Sackgasse.
Das geht für die bisher "leichte Kost".


Eben nicht. ADOBE möchte es gern integrieren, aber viele Kamerahersteller lassen sich da nicht in die karten schau'n und ADOBE mach "Nase" und fängt an zu schätzen.
Mit dem entsprechend mageren Ergebnis. Also mit Red klappt das wunderbar.
RedcineX-Einstellungen lassen sich direkt übernehmen und Dank der engen Kooperation zwischen Red und Adobe klappt das natlos

Wandeln des Ausgangsmaterials ist nicht nötig:
Timeline von Premiere zu Speedgrade oder AE und zurück klappt ohne Einschränkungen.

Genau das ist der Ansatz und dazu kommt dann noch, dass die Render-Tools, die die eigentliche Qualität erzeugen, nicht mal vom NLE Hersteller sein müssen sondern je nach Qualitätsanspruch, ebenso wie jetzt auch die Codecs, von den Firmen kommen können, die die besten Implementierungen machen.
Für mich, deutlich der bessere Weg. Stimmt - mit DNG ist es leider noch ein Elend bei Adobe.
Würde eine ähnliche Verknüpfng zwischen Premiere und Resolve wie bei Premiere-Speedgrade bestehen, wäre auch dies kein Problem mehr.



Antwort von TheBubble:

Aber dann sind wir genau wieder da, wo wir heute stehen. Dann kann man auch das De-Bayering in der Kamera machen und muss erst gar keine metadaten herschaufeln. Könnte man machen, wäre im Grunde egal. Die Gründe für das Zwischenformat sind ja andere und wann und wie es erzeugt wird ist aus Sicht der das Format nutzenden Software egal.

Den Weg von einem speziellen Kamera-RAW-Format über einen Software-Konverter zum Intermediate-Format zu gehen kann aber trotzdem durchaus sinnvoll sein.



Antwort von WoWu:

Den Weg von einem speziellen Kamera-RAW-Format über einen Software-Konverter zum Intermediate-Format zu gehen kann aber trotzdem durchaus sinnvoll sein. Also, wie gesagt, das kann ich nicht nachvollziehen. Schon beim einfachen proxy Verfahren hat man alle Vorteile nur ohne Intermediate und wenn die hochfrequenten Anteile er Bilder erst im Renderprozess einschliesslich aller Bearbeitungsschritte erzeugt werden, erst Recht nicht.
Bilder am Bearbeitungsende aus dem Originalmaterial RAW zu rechnen wirst Du mit keinem Intermediate schlagen können.
Aber wir werden es noch erleben, da bin ich ganz sicher.



Antwort von TheBubble:

Den Weg von einem speziellen Kamera-RAW-Format über einen Software-Konverter zum Intermediate-Format zu gehen kann aber trotzdem durchaus sinnvoll sein. Also, wie gesagt, das kann ich nicht nachvollziehen. Ich sehe da mehrere Gründe. Zuerst das Kostenargument: Die Kamera selbst ist einfacher aufgebaut, die Konverter-Software kann man noch beim Kunden ohne großen Aufwand aktualisieren.

Ein andere Grund wäre es, später neue Algorithmen hinzufügen zu können, die sonst frühestens in der nächsten Kamera-Generation verfügbar gewesen wären oder schlicht für die Echtzeit-Verarbeitung in einer Kamera zu aufwendig sind.

Und man kann das RAW-Format auch optional genau an die Gegebenhaiten der Kamera anpassen und muss nicht auf Kompatibilität mit bestehender Software achten, denn es wird ohnehin umgewandelt.
Bilder am Bearbeitungsende aus dem Originalmaterial RAW zu rechnen wirst Du mit keinem Intermediate schlagen können. Du musst Deine Betrachtungsweise etwas verändern, dann siehst Du, dass es praktisch keinen Unterschied macht: Auch wenn Du am Bearbeitungsende aus einem RAW den fertigen Film errechnest, gehst Du intern über die gleichen Zwischenschritte. Ich setze nur an einem Punkt in dieser Verarbeitungskette das Intermediate-Format in Form einer Datei dazwischen. In dieser Datei landet die Bitmap so, wie sie an diesem Punkt der Verarbeitungskette gerade im Speicher vorlag. Nur kann man sie später wieder laden und ab der Stelle einfach weiter rechnen.

Du willst z.B. machen:

RAW -> RAW (intern) -> Nach De-bayering RGB-Bitmap (intern) -> farbkorrigierte RGB-Bitmap (intern) -> Ausgabe (H.264, MPEG-2, DCP, ...)

Ich würde hingegen vorschlagen:

1) RAW -> RAW (intern) -> Nach De-bayering RGB-Bitmap (intern) -> Intermediate-Format
2) Intermediate-Format -> RGB-Bitmap (intern) -> farbkorrigierte RGB-Bitmap (intern) -> Intermediate-Format
3) Intermediate-Format -> RGB-Bitmap (intern) -> Ausgabe (H.264, MPEG-2, DCP, ...)

Im Ergebnis kommt das Gleiche raus. Nur kann man bei meiner Variante für die Teilschritte 1, 2 und 3 problemloser unterschiedliche Programme verwenden.






Antwort von WoWu:

Das kannst Du doch alles auch wenn Du im Proxy Mode arbeitest, ohne an Deinen Originalfile hin und her kodieren zu müssen.
Ich sehe einfach den Vorteil einer mehrfachen Transcodierung nicht.
(Auch nicht vom Ansatz eines schnelleren und schon gar nicht besseren Workflows).
Wenn Du so einen Intermediate gleich in der Kamera machst, dann kann ich das noch verstehen, damit Du gleich ein Bild hast - Aber das haben wir ja jetzt auch schon. Dazu muss man nix ändern.
Und wir kennen auch die Nachteile.
Aber die Transkodiererei, erst auf einen Intermeditate und dann hinterher noch auf den Zielcodec ist immer mit Einschränkungen verbunden.
Mir verschliesst sich einfach der vermeintliche Vorteil. Speziell wenn die Bilder noch gar nicht verwertbar vom Sensor kommen, also noch keine hochfrequenten Elemente enthalten, wie es bei 4K und erst recht 8K sein wird.
Das würde bedeuten, dass man einen kompletten Prozess aufsetzen müsste, der sich hinterher durch Veränderung der Frequenzanteile im Bild gar nicht mehr effektiv beeinflussen lässt, wohingegen in dem Fall, wo noch das RAW Material vorliegt, die Faltungen noch beeinflussbar sind oder andere Algorithmen aufgesetzt werden können.
das kannst Du alles vergessen, wenn Du vorne ein Nutzbild daraus macht. Alle Vorteile des RAW sind weg, weil die nachgelagerte Bearbeitung nicht mehr abgestimmt vorgenommen werden kann.



Antwort von TheBubble:

Aber die Transkodiererei, erst auf einen Intermeditate und dann hinterher noch auf den Zielcodec ist immer mit Einschränkungen verbunden. Nicht zwangsläufig.
Mir verschliesst sich einfach der vermeintliche Vorteil. Der Entwickler/Vertreiber einer spezialisierten Software braucht keine Unmengen "komplizierte" Formate zu unterstützen, für die er ggf. die Codecs gegen Geld lizenzieren müsste (sowohl die konkrete Implementierung, als auch je nach Region weitere Abgaben, teils pro Stück).

Jede Menge interessanter Algorithmen oder auch nur nützlicher GUI-Ideen für die Farbkorrektur gehen für den praktischen Einsatz verloren, da die Format-Lizenz-Hürde zu hoch ist oder abschreckend aufwendige Formatumwandlungen vom Benutzer gefordert werden müssten.

Lösung: Der Entwickler unterstützt ein Intermediate-Format. Er kann sich ansonsten auf das Wesentliche konzentrieren.

Und noch ein Beispiel, warum das auch im Consumer-Bereich nützlich sein kann:

Selbst beim Import von gängigen AVCHD-Dateien gibt es immer wieder Ärger (man erinnere sich nur an die langen Threads über blaue Farbverläufe die durch clipping türkis wurden...). Diesen kann man durch einen Konverter der sozusagen endlich mal einfach alles richtig machen darf (indem er in einen erweiterten Farbraum ausgibt) umgehen.



Antwort von WoWu:

Der Entwickler/Vertreiber einer spezialisierten Software braucht keine Unmengen "komplizierte" Formate zu unterstützen, für die er ggf. die Codecs gegen Geld lizenzieren müsste (sowohl die konkrete Implementierung, als auch je nach Region weitere Abgaben, teils pro Stück). Egal, wo Du ein fremdes Format adaptierst, musst Du Dich immer auf den Vorhersteller einstellen. Ob das jetzt die Adaption von RAW Files sind, die man konvertieren muss oder ob es ein Vorcodec ist.
Einstellen musst Du Dich immer.
Also: kein Vorteil
Was die Kosten betrifft:
Ein Codec kostet immer immens viel, weil sowas wie MPEG von über 300 Firmen entwickelt wird und etwa 1.300 Patente enthält.
Wenn Du mir sagst, das kann allein die Programmierbude eines einzigen Herstellers, dann kann ich nicht verstehen, warum ein ganzes Konsortium über 20 Jahre daran arbeitet.
Selbst Läden wie APPLE nehmen einen bestehenden MPEG Codec (oder RED den Wavelet), der schon etwas älter ist weil er dann billiger wird und peppen ihr Intermediate Zeichen drauf und erweitern die Formate aus den bisherigen Normen und schaffen so ein eigenes Produkt.
Ist so ein Codec nun unbedingt besser als eine zeitgemässe Entwicklung ?
Schau Dir nur mal die beiden DCTs an.
Also: kein qualitativer Vorteil sondern eher ein Nachteil aber billiger für den Hersteller.
das interessiert mich als Anwender aber nicht. Mir kommt es darauf an, dass meine Bildqualität maximal ist und nicht, ob der Hersteller es für sich profitabler machen kann.
Jede Menge interessanter Algorithmen oder auch nur nützlicher GUI-Ideen für die Farbkorrektur gehen für den praktischen Einsatz verloren, da die Format-Lizenz-Hürde zu hoch ist oder abschreckend aufwendige Formatumwandlungen vom Benutzer gefordert werden müssten. Das stimmt nicht denn das kann man alles auch auf den Proxy anwenden, Dir entgeht also nichts.
Es gibt ja eben KEINE Formathürde, weil Du das RAW Format erst zum Rendern wieder anfasst. Du hast also eine Riesen Palette an Proxy Auswahl. In jeder Art und jeder Güte. Und die Codecauswahl für den Workflow beeinträchtigt nicht Dein Footage.
Ergo: keine Nachteile Der Entwickler unterstützt ein Intermediate-Format. Er kann sich ansonsten auf das Wesentliche konzentrieren. Das verstehe ich nicht ... was soll das Wesentliche sein und was für ein Entwickler ? Selbst beim Import von gängigen AVCHD-Dateien gibt es immer wieder Ärger (man erinnere sich nur an die langen Threads über blaue Farbverläufe die durch clipping türkis wurden...). Es gibt einen Standard wenn sich alle Hersteller daran halten würden, wäre das Problem gelöst denn die Ursache ist nicht der Vorcodec, sonst hätte jeder, der AVCHD benutzt, türkisfarbene Himmel.
Die Probleme macht also nicht der Codec sondern die Softwarebuden, die den Signalimport implementiert hat.
Das ist eine reine Pegelangelegenheit, die mit dem Codec absolut nicht zu tun hat. Diesen kann man durch einen Konverter der sozusagen endlich mal einfach alles richtig machen darf (indem er in einen erweiterten Farbraum ausgibt) umgehen. Wenn es eine "einfache" und "alles richtige" Lösung gibt, erwarte ich das von meinem NLE Hersteller. Dazu brauche ich nicht noch einen Konverter.
Und ich brauche vor allem keinen Farbraumwechsel, nur weil der Signalimport bei einigen NLEs nicht funktioniert.

Nee, wirklich, wenn das die Argumente für einen zusätzlichen Intermediate sein sollten... ich weiss nicht.
Es stecken keine Verbesserungen darin. weder vom Workflow her noch wirtschaftlich und schon gar nicht im Interesse meiner Bildqualität.
Und ich denke auch, dass die Industrie schon sehr genau gerechnet hat, sonst hätte sie die Codecs über die letzten 20 Jahre nicht immer effizienter gemacht.
Derjenige, der also einen solchen Intermediate entwickeln soll, wird sehr schnell wieder da landen, wo wir heute schon sind. Und wenn er 5 Jahre dazu braucht, ist er immer 5 Jahre hinterher.



Antwort von TheBubble:

Egal, wo Du ein fremdes Format adaptierst, musst Du Dich immer auf den Vorhersteller einstellen. Ob das jetzt die Adaption von RAW Files sind, die man konvertieren muss oder ob es ein Vorcodec ist.
Einstellen musst Du Dich immer.
Also: kein Vorteil Ein Zwischen-Codec, der rel. einfach in einer beliebigen Programmiersprache umzusetzen ist. Gegenüber RAW, MPEG-Codecs, DV und Co. ein großer Vorteil!
Ein Codec kostet immer immens viel, weil sowas wie MPEG von über 300 Firmen entwickelt wird und etwa 1.300 Patente enthält. Das Konsortium legt nur den Bitstream fest. Leider verwenden sie bewusst Verfahren, die in einigen Märkten patentiert sind. Das ist ein großer Nachteil! (Für die Mitglieder ist es natürlich von Vorteil, da ihre Unternehmen so Geld einnehmen können.)
Ist so ein Codec nun unbedingt besser als eine zeitgemässe Entwicklung ? Es geht ja um keine Entwicklung, die toll zeitgemäß komprimiert, sondern ein Wide-Gamut-HDR-Format, dass gering bis mäßig komprimiert, keine Zukäufe fremder Programmbibliotheken erfordert und kostenfrei nutzbar ist, ähnlich OpenEXR. Nur einfacher aufgebaut.

Und im Gegensatz zu modernen Codecs sollte das Format leicht verständlich sein, d.h. die Beschreibung des Bitstrams sollte kurz und knapp bleiben und das Erzeugen der Dateien nicht unglaublich aufwendig sein.
Das stimmt nicht denn das kann man alles auch auf den Proxy anwenden, Dir entgeht also nichts.
Es gibt ja eben KEINE Formathürde, weil Du das RAW Format erst zum Rendern wieder anfasst. Du hast also eine Riesen Palette an Proxy Auswahl. In jeder Art und jeder Güte. Und die Codecauswahl für den Workflow beeinträchtigt nicht Dein Footage.
Ergo: keine Nachteile Vergiss mal die ganze RAW-Geschichte. Schon altes HDV-MPEG-2 ist eine große Hürde, wenn man aus guter Laune eine Freeware veröffentlichen möchte, die einen Videoschnipsel z.B. stabilisiert.
Der Entwickler unterstützt ein Intermediate-Format. Er kann sich ansonsten auf das Wesentliche konzentrieren. Das verstehe ich nicht ... was soll das Wesentliche sein und was für ein Entwickler ? Das Wesentliche ist das, was das Programm mit den Bitmaps tun soll. Im Gegensatz zum In- und Export der Daten. Das ist zwar notwendig, aber langweilig.
Es gibt einen Standard wenn sich alle Hersteller daran halten würden, wäre das Problem gelöst denn die Ursache ist nicht der Vorcodec, sonst hätte jeder, der AVCHD benutzt, türkisfarbene Himmel.
Die Probleme macht also nicht der Codec sondern die Softwarebuden, die den Signalimport implementiert hat. Du hast erfasst, wie es sein sollte. Nur interessiert das viele "Softwarebuden" nicht, denn es generiert keinen zusätzlichen Gewinn, wenn sie das Problem angehen. Also bleibt es, wie es ist.
Wenn es eine "einfache" und "alles richtige" Lösung gibt, erwarte ich das von meinem NLE Hersteller. Dazu brauche ich nicht noch einen Konverter. Wenn Du das erwartest, dann kannst Du wohl häufig sehr sehr lange warten ;-)
Wie gesagt: Man tut als Hersteller häufig nur das, was der Markt fordert.

Solange quasi "alle" das gleiche Problem haben, besteht kein wirtschaftlicher Druck etwas zu tun und das Problem bleibt erhalten. Manchmal liegt das Problem auch in einer zugekauften Komponetnte, auf die man selbst keinen Einfluß hat.



Antwort von WoWu:

Also, bei dem Resümee bin ich bei Dir.
Es wird sich nichts so schnell ändern.
Panasonic hat ja 2012 mal angekündigt, Anfang 2014 einen Intermediate auf der AVC Basis auf den Markt zu bringen ....

Nun, nix isses geworden.
So wie es aussieht ziehen die sich auf den Broadcast Sektor zurück und die brauchen keine Intermediate, weil ihre Rechner auch die Aquisitionscodecs packen.
(Ach übrigens auch immer mehr Semi- NLEs denn I-frame only ist ja durchaus schon etabliert.

Aber warten wir's doch einfach mal ab, wie es sich entwickelt.
Unsere Prognosen liegen auf dem Tisch.
Seh'n wir mal, wie es läuft.

Was ich in den letzten 10 Jahren so mitbekommen habe ist lediglich, dass die Hersteller alte, längst tote Pfründe erst aufgeben, wenn die Gäule wirklich am Boden liegen.
Solange altes Zeug auch nur noch einen Dollar einbringt wird kein neuer Gaul vor den Karren gespannt.
Innovation fühlt sich anders an.
Und mit so einer Innovation hat die hier beschriebene Kamera auch absolut nix am Hut.



Antwort von Frank Glencairn:

Ehrlich gesagt versteh ich euer Problem nicht so ganz.

Momentaner Stand der Dinge ist, Proxies von Raw zu schreiben und mit denen zu schneiden - dann per XML den Schnitt auf das original Material übertragen und raus rchnen. Kein Intermediate Codec nötig.

Allerdings ist es mit einem aktuellen Rechner für 4000 Euro schon möglich das alles zu verrgessen und einfach mit den raw Dateien zu schneiden.

Okay, ich verstehe, daß schneiden in Resolve nicht jedermanns Sache ist, aber ich wette es dauert nicht mehr lange bis alle NLEs (außer AVID vielleicht) arbeiten mit nativem raw unterstützen. In Premiere geht das heute schon.

Wenn man irgendwo unbedingt (für VFX z.b.) einen Intermediate Codec braucht , hat sich DPX oder TIFF mehr als bewährt.



Antwort von sgywalka:

13h 41min

meine Drehpause mit der KINE ist in 2 Minuten aus..
ich verzichte auf mein Kaff..ee

was is des Problem?

bing- tschuess.. los.



Antwort von WoWu:

Okay, ich verstehe, daß schneiden in Resolve nicht jedermanns Sache ist, aber ich wette es dauert nicht mehr lange bis alle NLEs (außer AVID vielleicht) arbeiten mit nativem raw unterstützen. In Premiere geht das heute schon. Wenn Du Dich da man nicht täuscht .... weil bis auf ein paar Kameras die RAW Meta-Informationen gar nicht rausgeben und wenn .... wohin damit ?
Du verwechselst das mit CINEMA DNG, aber das ist kein natives RAW sondern die Adobe Interpretation eines Bildes.
Schliesslich ist es nur ein Konverter und noch dazu ein schlechter.

Und wenn Du nach dem Problem fragst: Genau das ist es.
Dass ADOBE einfach ein Bild zusammenschustert statt die RAW Metadaten der Hersteller zu benutzen. (bis auf ein paar, die mitmachen).
Deswegen auch meine Erwartung, dass eine RAW Standardisierung da weitaus dringender ist, als ein Intermediate, zumal ich zwar nicht der Meinung bin, dass wir demnächst alle mit 14 Bit Originalmaterial arbeiten (Frank, hast Du den Monitor dafür schon ?) aber denke, dass RAW Material immer wichtiger für die Produktion wird. Da geh ich absolut konform.
Wenn aber das Bildprozessing so weiter geht, wie es in 4K angefangen hat, wirst Du von einem vorentwickelten Bild sehr schnell die Finger lassen und froh sein, wenn Du die relevanten Parameter erst im Renderprozess setzen kannst.



Antwort von Frank Glencairn:

Womöglich hab ich ja was falsch verstanden, aber soweit ich weiß, ist CinemaDNG nur ein Container für DNG (was technisch gesehen ein TIFF mit Metadaten ist), Audio und noch mehr Metadaten.

Letztendlich steckt darin aber das Raw (in Form eines "besseren Tiff" - vereinfacht gesagt)

Das kann ich in Premiere werfen und sehe eine (zugegeben lausige) Interpretation, die mir zum schneiden völlig reicht.

Da niemand ernsthaft Colorgrading in Premiere macht ist das aber okay, weil man danach sowieso in Resolve muß, und da gibt's dann die volle Packung mit allem drum und dran.






Antwort von WoWu:

Mit dem Container hast Du Recht aber mit dem TIFF nicht, denn das ist kein Datenfile mehr sondern die Interpretation des Datenfiles, also ein Videofile mit allen dazugehörigen Nachberechnungen.
Das ist ja das "Leiden", dass ADOBE seine Interpretation auf Huffmann uncompressed Codecs festgelegt hat.

Es besteht allerdings die Möglichkeit, das Original-RAW File mit in den Container zu packen. (also wirklich nur die Daten) So machen wir das immer. Dann benutzen wir den Container quasi nur als Synchronisation zu dem ebenfalls im Container liegenden Proxy, mit dem wir arbeiten.

Da niemand ernsthaft Colorgrading in Premiere macht ist das aber okay, weil man danach sowieso in Resolve muß, und da gibt's dann die volle Packung mit allem drum und dran. Aber leider auch nur auf der Basis des TIFF oder lädst Du da die original Kameradaten ein, also ohne cinemaDNG ?
Ich denke doch nicht ? Dann ist nämlich Dein Endprodukt nur maximal so gut, wie die Interpretation zum TIFF.
Bei der BM geht das ja noch, weil BM ja DNG unterstützt und die Metadaten hergibt aber bei CANON (?) z.B. steht DNG ziemlich im Dunkeln.

Aber das ist eben schon wieder Ansicht, weil nicht normiert, : was ist RAW und was ist bereits ein Video.
Ich halte nur die Kameradaten für RAW, weil alle spezifischen Metadaten korrekt abgefeiert werden können.
Aber, wie gesagt, kein Streit darüber. Es gibt da keine Festlegung.



Antwort von Frank Glencairn:

Aber das "Tiff" im CinemaDNG Container ist doch noch nicht debayert oder?



Antwort von srone:

doch. tif ist ein "fertiges" format wie jpg, png, bmp.

edit: wohl doch nicht, siehe hier, wurde das tif format erweitert:

http://www.adobe.com/devnet/cinemadng/c ... ormat.html

lg

srone



Antwort von Frank Glencairn:

Wieso muß ich es dann in Resolve oder sonstwo debayern, damit ich was sehe?

Das "Tiff" im CinemaDNG Container ist IMHO ein undebayertes Graustufenbild, sprich raw. Sonst wäre ja die ganze DNG/raw Nummer ein Witz.



Antwort von TheBubble:

Das "Tiff" im CinemaDNG Container ist IMHO ein undebayertes Graustufenbild, sprich raw. Sonst wäre ja die ganze DNG/raw Nummer ein Witz. So ist es. Es das TIFF-Format wird als Container benutzt. (TIFF ist da sehr flexibel.)



Antwort von WoWu:

Dann ist es auch kein TIFF sondern die Übernahme der RAW Daten.
Wie ich oben schon sagte. Einige Firmen unterstützen CinemaDNG, da gehört BMD zu. In dem Fall bereitet BMD die Daten so auf, dass CinemaDNG sie lesen und speichern kann.
Aber, wie gesagt, das ist dann kein TIFF (oder falsch benannt).
Sobald Du es sehen kannst, ist es kein RAW mehr.
Denn zum RAW gehören alle metadaten, die die u.A. auch die kameraumgebung beschreiben, also z.B. die genauen Farbwerte der Bayermaske, die Überlappungen, die Pixeleigenschaften usw.usw. ein ganzer Satz unterschiedlicher Daten.
Alles Werte, die erst hinterher ein Bild ergeben und sichtbar machen.
Dazu kommt noch, dass alle Pixelwerte übertragen werden, also nicht nur für ein bestimmtes Zielformat.
Was Du da hast ist eine Rastergrafik, die aus dem RAW Format erstellt worden ist.
Du kannst damit z.b. auch nix in 14 Bit werden. Insofern ist es, -streng genommen- bereits der nächste Verarbeitungsschritt bzw. ein Zwischenprodukt.



Antwort von srone:

Dann ist es auch kein TIFF sondern die Übernahme der RAW Daten.
Wie ich oben schon sagte. Einige Firmen unterstützen CinemaDNG, da gehört BMD zu. In dem Fall bereitet BMD die Daten so auf, dass CinemaDNG sie lesen und speichern kann.
Aber, wie gesagt, das ist dann kein TIFF (oder falsch benannt).
Sobald Du es sehen kannst, ist es kein RAW mehr.
Denn zum RAW gehören alle metadaten, die die u.A. auch die kameraumgebung beschreiben, also z.B. die genauen Farbwerte der Bayermaske, die Überlappungen, die Pixeleigenschaften usw.usw. ein ganzer Satz unterschiedlicher Daten.
Alles Werte, die erst hinterher ein Bild ergeben und sichtbar machen.
Dazu kommt noch, dass alle Pixelwerte übertragen werden, also nicht nur für ein bestimmtes Zielformat. wowu schau dir den obigen link an, da steht was von tif spec erweiterung.

lg

srone



Antwort von WoWu:

Danke srone.
Aber da steht nichts Neues drin, da beschreiben sie nur, was ich oben schon erwähnt habe, dass das Original RAW Kamerafile auch in dem Container mitgeführt werden kann, aber das bedeutet nicht, dass sie es in ihrer Verarbeitung nicht (für) die Verarbeitung verändern.
So machen wir das. Wir lassen das Original File drin-unverändert- und nehmen das für das final Rendering.

Aber hier liegt die Sache ja anders. Adobe macht daraus ein eigene Rastergrafik in einem "Hausformat" mit festgeschriebener Codierung.
Das ist der Hauptgrund, der den meisten Firmen nicht passt und weswegen sie nicht mitmachen.
Man hat es also mit dem ADOBE-eigenen Format zu tun.
Da kann der Container so "offen" sein, wie er will.
Insofern mag TIFF ja da datentolerant sein, aber TIFF ist selbst das Problem.
Wenn eine Firma, wie BMD das unterstützen, ist das sicher alles noch tragbar und die Programme greifen an vertretbaren Punkten ineinander. Du kommst nur eben nie mehr an die originären RAW Daten sondern nur noch an eine aufbereitete, maximal 12 Bit breite Ratergrafik, also eine Bilddatei.
Mich würde bei dem teil z.B. mal interessieren, was passiert, wenn Du auf die Konvertierung mit einem 14Bit sensor los gehst. (Also kein embaddet singnal)



Antwort von TheBubble:

Nun übertreibt es mal nicht mit den Details. DNG basiert im Aufbau auf TIFF. Das ist für den Anwender aber völlig uninteressant.






Antwort von WoWu:

Deswegen machen auch sowenig mit.
Sag ich doch.
Für den Anwender wird es spätestens interessant, wenn er 4kRAW Daten wegspeichern möchte und sie hinterher für REC 2020 neu verwerten will.
In den Farbraum kommt er mit dem DNG File nie mehr rein.
Es sei denn, er benutzt den DNG Container nur als Transport für die original, nicht konvertierten Daten, sofern alle metadaten übernommen werden kann.

So ein Container ist ja nichts schlechtes. Es muss nur gewährleistet sein, dass die Daten nicht so konvertiert werden, wie man sie heute braucht und nicht weiter.
Und das ist bei DNG nicht der Fall.
Einer der Vorteile von RAW ist ja gerade, die uneingeschränkte Nachverarbeitung. Betonung liegt auf "uneingeschränkt".



Antwort von iasi:

Letztlich sind wir wieder beim Ausgangspunkt:

Sofern Kinefinity eng mit den Softwareherstellern kooperiert und eine Lösung herbeiführt, wie bei CinemaDNG und Resolve oder bei Redcode und Adobe/Resolve, dann sehe ich kein Problem.
Wenn dies aber erst mal so läuft wie bei CinemaDNG und Adobe, dann wird es problematisch.
Kamerabau hört eben nicht bei der Hardware und dem Codec auf.

Was Adobe aber eben zeigt, ist die Verknüpfung verschiedener Programme, wie ich sie mir z.B. auch zwischen Premiere und Resolve wünschen würde - XML ist z.B. noch ziemlich grobschlächtig.



Antwort von TheBubble:

Was Adobe aber eben zeigt, ist die Verknüpfung verschiedener Programme, wie ich sie mir z.B. auch zwischen Premiere und Resolve wünschen würde - XML ist z.B. noch ziemlich grobschlächtig. Was Deiner Wünsche prinzipiell erfüllen könnte, ist ein geeignetes Zwischen-Dateiformat, dass Du erst mit einem Schnittprogramm Schneidest und dann mit einer beliebigen anderen Software farblich bearbeitest.

Eine direkte Kopplung/Integration von Programmen unterschiedlicher Hersteller halte ich aufgrund der Konkurrenzsituation für vergleichsweise schwierig.



Antwort von WoWu:

Das ist ja eben genau der Punkt, wo die SMPTE einhakt indem sie einen Standard schaffen, der frei von irgendwelchen Firmeneigenen Formaten ist und gleichzeitig geeignet, einen so grossen Farbraum abzubilden, der noch deutlich den x,y,z übersteigt. Und vor allen Dingen nicht bei der Codierung irgendwelche Einschränkungen auferlegt, die heute vielleicht noch gut sind, morgen aber schon hinderlich.
Übrigens implementiert BMD das auch. (Jedenfalls gehörten sie zu den aktiven Teilnehmern)
Stellt sich also die frage, ob das DNG Format von endlichem Charakter bei BMD ist.