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.
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.
iasi hat geschrieben: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.
da es ja sowieso so aussieht, dass Kinefinity Red kopiert, könnten sie ja vielleicht ebenfalls den Softwareherstellern zuarbeiten - sinnvoll wäre dies allemal ...
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.
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.
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?
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.
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.
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.
WoWu hat geschrieben:
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.
@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.
WoWu hat geschrieben:
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.
WoWu hat geschrieben:
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.
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.
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.
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.
WoWu hat geschrieben: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.
WoWu hat geschrieben:
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:
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.
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.
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.
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.
WoWu hat geschrieben:
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?
WoWu hat geschrieben: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.)
WoWu hat geschrieben:
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.
WoWu hat geschrieben:
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. :-)
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.
TheBubble hat geschrieben:
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?
WoWu hat geschrieben:
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.
WoWu hat geschrieben:
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.
:-)
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.
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.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
