Frage von micha2305:Hier im Forum war einmal die rede davon, dass Z-Cam Kameras wie die E2 nach dem letzten Update kein wirkliches ZRaw mehr aufzeichnen können.
Stimmt das ? Was nimmt die Kamera denn jetzt, nach dem letzten Update, auf ?
Antwort von rush:
Und vor allen Dingen stellt sich die Frage: Was, wenn man das Update (bei bereits vorhandener Kamera) nicht aufspielt?
Antwort von Frank Glencairn:
Nix passiert, und die Kamera macht weiterhin das selbe wie vorher auch.
Wenn einem sowas aus irgendeinem Grund wichtig ist, muß man das mit den Updates ab einem gewissen Zeitpunkt halt lassen.
Deshalb hab ich immer noch BM Kameras die DNGs schreiben können (auch unkomprimiert),
und ne DJI Drohne mit der ich fliegen kann wo ich will - wenn's sein muß auch auf der Startbahn des Münchener Flughafens :-)
Antwort von roki100:
"Frank Glencairn" hat geschrieben:
Deshalb hab ich immer noch BM Kameras die DNGs schreiben können (auch unkomprimiert),
Gib es zu, Du findest den Fairchild Sensor, dreifach besser als ich... ;)
Antwort von Frank Glencairn:
Sagen wir mal so, die ersten Sensoren haben tatsächlich ein gewisses - schwer zu beschreibendes - "etwas", daß ich tatsächlich sehr schätze :-)
Antwort von micha2305:
"Frank Glencairn" hat geschrieben:
Nix passiert, und die Kamera macht weiterhin das selbe wie vorher auch.
Wenn einem sowas aus irgendeinem Grund wichtig ist, muß man das mit den Updates ab einem gewissen Zeitpunkt halt lassen.
Deshalb hab ich immer noch BM Kameras die DNGs schreiben können (auch unkomprimiert),
und ne DJI Drohne mit der ich fliegen kann wo ich will - wenn's sein muß auch auf der Startbahn des Münchener Flughafens :-)
Aber hier wurde doch mal geschrieben, nach dem Update sei es kein echtes RAW mehr oder nur H265 oder so was ?
Antwort von roki100:
micha2305 hat geschrieben:
Aber hier wurde doch mal geschrieben, nach dem Update sei es kein echtes RAW mehr oder nur H265 oder so was ?
Das hat irgendwer mal verbreitet und von da aus dann weiter... Wie soll bitte H265 in ZRAW RAW möglich sein? Dann müsste die ZRAW Datei nach dem angeblichen Update um mindestens 90% kleiner sein - ist das der Fall?
Antwort von rush:
Er meint das man dann eben kein Update mehr vollziehen darf um die RAW Funktionalität zu behalten.
Hat auf der anderen Seite den Nachteil daß man sonstige Optimierungen und Erweiterungen die per Software kommen nicht verwenden kann.
Muss dann eben individuell abgewogen werden. Wer RAW bei der ZCam will sollte beim aktuellen SoftwareStand bleiben.
Vielleicht kommt RAW in anderer Form ja eines Tages wieder...
Antwort von prime:
Laut
dem Hacker sind die Dateien aus neuer Firmware verschlüsselt.
Ich denke mal ZRAW Dateien enthalten immer noch die gleichen RAW Daten wie bisher (je nach dem wen man glaubt), denn es ist höchst unwahrscheinlich dass sie so schnell einen neuen Codec entwickelt haben. Für alle die ZRAW Dateien mit der ZCAM Windows/macOS Software entwickeln ändert sich nicht viel (vielleicht etwas langsamer).
Siehe auch:
viewtopic.php?f=2&t=151330
Antwort von roki100:
prime hat geschrieben:
Laut dem Hacker sind die Dateien aus neuer Firmware verschlüsselt.
HIER wurde das auch geschrieben, mit einem Unterschied:
ZRAW is not RAW anymore.
After firmware v0.94.1 it's an AES-encrypted MOV-container-corrupted overXORred shit, that contains only HEVC bitstream.
Deal with it.
Woher kommt die Behauptung, dass ZRAW kein RAW mehr ist? Das stimmt doch nicht. Es ist immer noch das, was es von Anfang an war (diesmal auch verschlüsselt); ein chinesisches BRAW ;))
Antwort von micha2305:
roki100 hat geschrieben:
prime hat geschrieben:
Laut dem Hacker sind die Dateien aus neuer Firmware verschlüsselt.
HIER wurde das auch geschrieben, mit einem Unterschied:
ZRAW is not RAW anymore.
After firmware v0.94.1 it's an AES-encrypted MOV-container-corrupted overXORred shit, that contains only HEVC bitstream.
Deal with it.
Woher kommt die Behauptung, dass ZRAW kein RAW mehr ist? Das stimmt doch nicht. Es ist immer noch das, was es von Anfang an war (diesmal auch verschlüsselt); ein chinesisches BRAW ;))
Stimmt das denn ?
Wenn dem so wäre, wie da beschrieben, würde es dann überhaupt groß Unterschied oder Vorteile bewirken, ZRAW zu verwenden ?
Antwort von roki100:
der einzige Nachteil bei ZRAW ist doch das bereits bekannte, dass man vorher umwandeln muss... das hat sich mit der neuen Firmware nicht geändert, hab zumindest nichts darüber gefunden, dass ZRAW plötzlich anders aussieht, weil es nun verschlüsselt ist... Wie User prime bereits angemerkt hat, es könnte sein, dass die Bearbeitungsprozesse vll. etwas langsamer sind...und da kommt es auch auf die Verschlüsselung an... es wird höchstwahrscheinlich einmalig beim laden entschlüsselt, um gelesen zu werden und das wars und nicht bei jede einzelne Frame; entschlüsseln, lesen, schreiben, nächste Frame usw. das glaube ich nicht.
Antwort von mash_gh4:
prinzipiell ist es nicht unbedingt ein widerspruch, von einem "MOV-container-corrupted overXORred shit, that contains only HEVC bitstream" zu sprechen, der in wahrheit aber tatsächlich RAW daten enthält!
wenn man die verlustfreien kompressionsvarianten nutzt, die ja bekanntlich in all diesen neueren codecs vorgesehen bzw. spezifiziert sind, auch wenn sie in die praxis nur sehr selten genutzt werden, kann man darin fast beliebige bilddaten-sequenzen übergeben, u.a. eben durchaus auch jederzeit 12bit log codierte RAW daten.
damit ist natürlich nicht gesagt, dass es sich tatsächlich so verhält, aber zumindest kann man alleine aus dem auffinden eines HVEC headers nicht unbedingt gleich auf das gegenteil schließen.
Antwort von roki100:
eben. In BRAW wurde angeblich auch
JPEG Komprimierung(?) gefunden.
Antwort von cantsin:
HEVC-komprimiertes RAW ist zwar möglich, aber sehr unwahrscheinlich, weil der Codec-Wechsel direkt nach dem russischen reverse engineering von ZRaw erfolgte, bei dem sich herausstellte, dass das Format aus komprimierten undebayerten Sensordaten bestand und damit das RED-Patent verletzte.
- Man kann RAW-Daten auch JPEG-kompromieren. Es handelt sich ja um normale RGB-Daten, nur eben undebayert. Dann speichert man eben ein Bayer-Muster als JPEG; bei JPEG 2000 geht das auch mit mehr als 8bit Farbtiefe.
Antwort von mash_gh4:
bei der verlustfreien kompressionsvariante, die in der DNG spezifikation vorgesehen ist, handelt es sich ja in wahrheit auch um eine eher selten genutzte lossless JPEG92 variante. derartiges recycling von bereits existierenden technischen lösungen ist eigentlich ganz normal und vernünftig.
https://thndl.com/how-dng-compresses-ra ... peg92.html
interessant ist übrigens die art und weise, wie die pixel dabei verschoben bzw. umgruppiert werden, damit ähnlichfarbige sensel-daten wieder nebeneinander zu liegen kommen und damit die kompressionsrate erhöht wird.
Antwort von Frank Glencairn:
cantsin hat geschrieben:
Es handelt sich ja um normale RGB-Daten, nur eben undebayert.
Nicht ganz, raw ist immer schwarz/weiß, die Farbe entsteht erst im Rechner.
Antwort von cantsin:
"Frank Glencairn" hat geschrieben:
cantsin hat geschrieben:
Es handelt sich ja um normale RGB-Daten, nur eben undebayert.
Nicht ganz, raw ist immer schwarz/weiß, die Farbe entsteht erst im Rechner.
Jein/Ansichtssache. Man könnte auch argumentieren, dass RAW eigentlich "noch mehr" RGB ist als debayerte Daten, weil in RAW die RGB-Kanäle getrennt erfasst und gespeichert sind. (Eigentlich wie 3-Strip zu analogen Filmzeiten.) Und dass die RGB-Kanaltrennung bei debayerten Daten Fake-RGB ist.
Antwort von Frank Glencairn:
Jeder Sensor ist zunächst mal nur eine Ansammlung von vielen kleinen "Solar Panels", die bei dem Kontakt mit Licht, - abhängig von der Helligkeit - Strom produzieren (vereinfacht gesagt). Dieser Strom wird gemessen, und der Wert abgespeichert - zusammen mit der Information, welcher Filter vor der Zelle war.
Das ist das roheste raw in a nutshell. Raw Daten sind also nur eine Tabelle mit Volt Angaben, einer X/Y Koordinate und einem Filter Hinweis.
RGB im herkömmlichen Sinne ist da noch gar nix. Das wird es genau genommen erst am Bildschirm, wenn es wieder analogisiert ist - also die entsprechende Spannung an dem Bildschirm Pixel angelegt wird, damit du die darunterliegenden Zahlen auch tatsächlich wahrnehmen kannst.
Wenn man darüber nachdenkt, ist die ganze Nummer - vom Sensor zum Bildschirm eigentlich nicht mal wirklich digital - selbst der Moment wo die Spannung in Einsen und Nullen übersetzt wird (und später wieder zurück), ist letztendlich nur analoges ""Strom/kein Strom".
Daß ein nicht erheblicher Teil der Farbwerte am Ende geraten (interpoliert) ist, stimmt natürlich.
Antwort von cantsin:
"Frank Glencairn" hat geschrieben:
Jeder Sensor ist zunächst mal nur eine Ansammlung von vielen kleinen "Solar Panels", die bei dem Kontakt mit Licht, - abhängig von der Helligkeit - Strom produzieren (vereinfacht gesagt). Dieser Strom wird gemessen, und der Wert abgespeichert - zusammen mit der Information, welcher Filter vor der Zelle war.
Das ist das roheste raw in a nutshell. Raw Daten sind also nur eine Tabelle mit Volt Angaben, einer X/Y Koordinate und einem Filter Hinweis.
Schon klar.
RGB im herkömmlichen Sinne ist da noch gar nix.
Aber im Wortsinne. Die Tabelle mit den Volt-Angaben bezieht sich jeweils auf gefilterte Rot-, Grün- und Blau-Werte.
Also: Bei der RAW-Aufnahme werden R, (2x) G und B werden getrennt gespeichert, um anschließend im Debayering zu Mischfarben interpoliert zu werden. Wenn man dann dieses Mischfarben-Bild als JPEG, PNG oder TIFF speichert, werden die Farbkanäle wieder getrennt, aber eben auf Basis der interpolierten Werte und damit eigentlich als Pseudo-RGB (bzw. - wenn man so will - mit Pseudo-Volt-Angaben pro Farbkanal).
Bzw., anders ausgedrückt: Die R/G/B-Kanaltrennung ist in RAW sauberer als im debayerten JPEG/PNG/TIFF. Weshalb ja auch Dinge wie WB-Korrektur auf Basis der RAW-Werte (z.B. im Raw-Tab von Resolve) besser/sauberer gehen als auf Basis der debayerten RGB-Werte (z.B. im Color-Wheel-Tab von Resolve), selbst wenn die debayerten Werte in 12bit oder mehr Farbtiefe vorliegen.
Antwort von mash_gh4:
cantsin hat geschrieben:
"Frank Glencairn" hat geschrieben:
Nicht ganz, raw ist immer schwarz/weiß, die Farbe entsteht erst im Rechner.
Jein/Ansichtssache. Man könnte auch argumentieren, dass RAW eigentlich "noch mehr" RGB ist als debayerte Daten, weil in RAW die RGB-Kanäle getrennt erfasst und gespeichert sind. (Eigentlich wie 3-Strip zu analogen Filmzeiten.) Und dass die RGB-Kanaltrennung bei debayerten Daten Fake-RGB ist.
nein -- die sache ist vor allem deshalb noch ein bisserl kompliziert, weil die üblichen device referred RGB werte deiner zweiten kategorie -- also z.b. sRGB/rec.709 od. bildaten -- sich nur auf die erzeugung eines farbeindrucks mit hilfe der additiven mischung dreier verschiedenfärbiger künstlicher lichtquellen beziehen, also von anfang an festgelegt ist, dass das damit vorgegebene gamut-dreieck bzw. der darstellbare farbraum nicht verlassen werden kann, während es sich damit auf der anderen seite, also den RBG werten der kamerasensoren bzw. deren colormetrischen beziehung zum gesamtbereich der wahrnehmbaren realen farben, ein klein wenig anderes verhält. dort spielt vielmehr die sensibilität der einzelnen farbrezeptoren im bezug auf gesamte lichtspektrum die entscheidende rolle.
in der praxis wirkt sich das so aus, das man manche dinge mit jenen einfachen regleren in color grading programmen, die sich nur mehr auf jene darstellungsbezogenen farbwerrte beziehen, einfach nicht mehr sauber korrigieren bzw. rückgängig machen kann, während colormetrisch korrekt erfasst sensordaten, die hinsichtlich ihrer farbwiedergabe das luther- bzw. maxwell-ives-kriterium erfüllen, mit relativ einfachen mathematischen operationen an verschiedene farbräume anpassen bzw. befriedigender korrigieren kann.
das verhältnis lichtintensität bzw. lineare od. log-codierter helligkeitswerte, wie man sie gerne mit diesen etwas advancteren herangehensweisen an die bild- und farbverarbeitung verbindet, ist also nur ein wichtiger diesbezüglicher unterschied zwischen den beiden werteangaben, die unterschiedliche beziehung der farbangaben zum colormetrischen gesamtgefüge aber nicht weniger bedeutsam.
Antwort von cantsin:
mash_gh4 hat geschrieben:
cantsin hat geschrieben:
Jein/Ansichtssache. Man könnte auch argumentieren, dass RAW eigentlich "noch mehr" RGB ist als debayerte Daten, weil in RAW die RGB-Kanäle getrennt erfasst und gespeichert sind. (Eigentlich wie 3-Strip zu analogen Filmzeiten.) Und dass die RGB-Kanaltrennung bei debayerten Daten Fake-RGB ist.
nein -- die sache ist vor allem deshalb noch ein bisserl kompliziert, weil die üblichen device referred RGB werte deiner zweiten kategorie -- also z.b. sRGB/rec.709 od. bildaten -- sich nur auf die erzeugung eines farbeindrucks mit hilfe der additiven mischung dreier verschiedenfärbiger künstlicher lichtquellen beziehen, also von anfang an festgelegt ist, dass das damit vorgegebene gamut-dreieck bzw. der darstellbare farbraum nicht verlassen werden kann, während es sich damit auf der anderen seite, also den RBG werten der kamerasensoren bzw. deren colormetrischen beziehung zum gesamtbereich der wahrnehmbaren realen farben, ein klein wenig anderes verhält.
Okay, ich nehme "fake" zurück bzw. relativiere es dahingehend, dass es sich auf perzeptive RGB-Werte bezieht. Also, wir haben es - wie Du ja auch schreibst - auf der einen Seite mit getrennten (bzw. monochromen) Rot-, Grün- und Blauwerten zu tun, wie sie der Sensor 'sieht', und auf der anderen Seite mit RGB-Werten, die der menschlichen Farbwahrnehmung angenähert sind.
Dass man aber letzteres RGB nennt und ersteres nicht, ist vielleicht eine technisch-wissenschaftliche Konvention, aber im sprachlichen bzw. Wortsinne nicht wirklich logisch oder stimmig.
 |
Antwort von micha2305:
Noch mal allgemein gefragt: Bei der aktuellen Firmware, der Version 98.0, ist da noch ZRAW uneingeschränkt vorhanden ?
Antwort von Clemens Schiesko:
micha2305 hat geschrieben:
Noch mal allgemein gefragt: Bei der aktuellen Firmware, der Version 98.0, ist da noch ZRAW uneingeschränkt vorhanden ?
Ja.
Antwort von micha2305:
Auch bei der letzten neuen Firmware 0.98.2 ?
Antwort von cantsin:
Das Problem ist ja nicht das Vorhandensein von ZRAW, sondern dass das Format von ZCam (wegen der RED-Patente) so verändert wurde, dass es faktisch kein Raw mehr ist. Bzw.: Es steht zwar immer noch RAW drauf, ist aber keins mehr drin.
Antwort von micha2305:
cantsin hat geschrieben:
Das Problem ist ja nicht das Vorhandensein von ZRAW, sondern dass das Format von ZCam (wegen der RED-Patente) so verändert wurde, dass es faktisch kein Raw mehr ist. Bzw.: Es steht zwar immer noch RAW drauf, ist aber keins mehr drin.
Ab welcher Firmware Version ist es denn kein echtes RAW mehr ?
Antwort von cantsin:
micha2305 hat geschrieben:
cantsin hat geschrieben:
Das Problem ist ja nicht das Vorhandensein von ZRAW, sondern dass das Format von ZCam (wegen der RED-Patente) so verändert wurde, dass es faktisch kein Raw mehr ist. Bzw.: Es steht zwar immer noch RAW drauf, ist aber keins mehr drin.
Ab welcher Firmware Version ist es denn kein echtes RAW mehr ?
Angeblich ab Firmware 0.94:
https://www.personal-view.com/talks/dis ... aw-anymore
Antwort von micha2305:
cantsin hat geschrieben:
micha2305 hat geschrieben:
Ab welcher Firmware Version ist es denn kein echtes RAW mehr ?
Angeblich ab Firmware 0.94:
https://www.personal-view.com/talks/dis ... aw-anymore
Hätte dann ZRAW überhaupt noch signifikante Vorteile gegenüber Prores422HQ etc. ?
Antwort von cantsin:
micha2305 hat geschrieben:
Hätte dann ZRAW überhaupt noch signifikante Vorteile gegenüber Prores422HQ etc. ?
Die Frage ist, ob es überhaupt jemals Vorteile ggü. einem ProRes-Log-Workflow hatte, da es ja nie Software-Unterstützung dafür gab außer in einem ZCam-eigenen, nicht gerade Nutzer-/Workflow-freundlichem Konverterprogramm...
Ich bin jedenfalls noch niemandem begegnet, der mit ZCams ZRaw dreht. Aber es gibt ja mittlerweile einen ProRes Raw-Workflow mit dem Atomos Ninja.
Antwort von Clemens Schiesko:
cantsin hat geschrieben:
micha2305 hat geschrieben:
Hätte dann ZRAW überhaupt noch signifikante Vorteile gegenüber Prores422HQ etc. ?
Die Frage ist, ob es überhaupt jemals Vorteile ggü. einem ProRes-Log-Workflow hatte, da es ja nie Software-Unterstützung dafür gab außer in einem ZCam-eigenen, nicht gerade Nutzer-/Workflow-freundlichem Konverterprogramm...
Ich bin jedenfalls noch niemandem begegnet, der mit ZCams ZRaw dreht. Aber es gibt ja mittlerweile einen ProRes Raw-Workflow mit dem Atomos Ninja.
Premiere unterstützt es aber auch. Und ich denke, es kommt ganz auf den Anwendungsbereich an. Manchmal sind 12 bit schon von Vorteil und gegenüber der 10 bit Log Variante kann man noch ein klein wenig mehr aus dem Dynamic Range herauskitzeln. Die Möglichkeit des nachträglichen ISO- und Weißabgleichs kann auch noch Vorteile bringen - gerade für den Workflow bei kurzen Werbeclips. ProRes RAW hat in Zukunft aber womöglich mehr Aussichten auf größere Unterstützung in den hiesigen Softwareschmieden, auch wenn es bei Resolve noch ungewiss ist. Eine interne Aufzeichnung bleibt aber trotzdem eine nützliche Funktion - gegenüber einem zusätzlich 600 Euro teuren, externen Monitor mit Lüftergeräuschen.
Antwort von micha2305:
"Clemens Schiesko" hat geschrieben:
cantsin hat geschrieben:
Die Frage ist, ob es überhaupt jemals Vorteile ggü. einem ProRes-Log-Workflow hatte, da es ja nie Software-Unterstützung dafür gab außer in einem ZCam-eigenen, nicht gerade Nutzer-/Workflow-freundlichem Konverterprogramm...
Ich bin jedenfalls noch niemandem begegnet, der mit ZCams ZRaw dreht. Aber es gibt ja mittlerweile einen ProRes Raw-Workflow mit dem Atomos Ninja.
Premiere unterstützt es aber auch. Und ich denke, es kommt ganz auf den Anwendungsbereich an. Manchmal sind 12 bit schon von Vorteil und gegenüber der 10 bit Log Variante kann man noch ein klein wenig mehr aus dem Dynamic Range herauskitzeln. Die Möglichkeit des nachträglichen ISO- und Weißabgleichs kann auch noch Vorteile bringen - gerade für den Workflow bei kurzen Werbeclips. ProRes RAW hat in Zukunft aber womöglich mehr Aussichten auf größere Unterstützung in den hiesigen Softwareschmieden, auch wenn es bei Resolve noch ungewiss ist. Eine interne Aufzeichnung bleibt aber trotzdem eine nützliche Funktion - gegenüber einem zusätzlich 600 Euro teuren, externen Monitor mit Lüftergeräuschen.
Mal unabhängig vom Handling (Workflow, Unterstützung Schnittsoftware etc ) :
Welchen Vorteil hinsichtlich Bildqualität hätte ProresRaw gegenüber ZRAW ?
Gibt es hier mehr Möglichkeiten? Wäre ProresRaw mehr "echtes Raw" als ZRAW ?
|
Antwort von Clemens Schiesko:
micha2305 hat geschrieben:
Mal unabhängig vom Handling (Workflow, Unterstützung Schnittsoftware etc ) :
Welchen Vorteil hinsichtlich Bildqualität hätte ProresRaw gegenüber ZRAW ?
Gibt es hier mehr Möglichkeiten? Wäre ProresRaw mehr "echtes Raw" als ZRAW ?
Unabhängig vom Handling sehe ich keinen Vorteil. Folgender User empfindet ZRAW sogar besser in der Farbbearbeitung.
Bei Gelegenheit muss ich beides auch mal ausgiebig testen. Neben mir liegt zwar ein Ninja V, aber ich kam bisher zeitlich noch nicht zum Vergleichen.
Antwort von cantsin:
micha2305 hat geschrieben:
Welchen Vorteil hinsichtlich Bildqualität hätte ProresRaw gegenüber ZRAW ?
Gibt es hier mehr Möglichkeiten? Wäre ProresRaw mehr "echtes Raw" als ZRAW ?
Es ist ziemlich schwierig, hierüber etwas zu sagen, weil beide Formate nicht offen dokumentiert sind.
Auch fassen Hersteller die Definition von "Raw" ziemlich weit. Normalerweise versteht man darunter nicht-debayertes Material, in dem die Helligkeitswerte der RGGB-Sensorpixel ungefiltert, aber ggfs. datenkomprimiert gespeichert werden. Aber bei praktisch allen Kameraherstellern finden bereits vor der Raw-Speicherung Filterungen bzw. Bildverbesserungen statt, um z.B. "Black Sun"-Effekte (überbelichtete Pixel, die im Bild schwarz erscheinen) zu verhinden. Bei Blackmagic Raw (Braw) werden selbst rauschgefilterte, teilweise debayerte Daten gespeichert.
RED hält ein Patent auf Kameras bzw. Aufzeichnungsgeräte, die datenkomprimiertes Video-RAW aufnehmen. Atomos hat dieses Patent für seine ProRes-Raw-Recorder wie den Ninja V lizenziert. Auch vom Verhalten bzw. visuellen EIndruck des ProRes Raw-Materials kann man davon ausgehen, dass es sich um "echtes" Raw (ohne Teildebayering, Rauschfilterungen etc.) handelt.
Bei ZRaw gab es einen reverse engineering-Hack, um das Format nach CinemaDNG zu übersetzen. Der Hacker stellte damals bei seiner Analyse fest, dass ZRaw aus datenkomprimierten rohen Sensor-RGGB-Werten bestand. Dadurch wurde klar bzw. öffentlich, dass ZRaw das RED-Patent verletzt. ZCam änderte daraufhin das ZRaw-Format per Kamera-Firmwareupdate so, dass laut denselben Hackerkreisen jetzt ein konventionelles h265-komprimiertes 12bit-Log-Video-Format ist.
"Bildqualität" ist im Zusammenhang mit Raw IMHO nicht ganz einfach zu beantworten. Raw-Material enthält zwar immer mehr Bildinformation als prozessiertes Bildmaterial, aber man könnte auch argumentieren, dass seine visuelle Qualität schlechter ist, weil es stärker rauscht, Objektiv- und Sensorfehler darin nicht korrigiert sind, etc.etc.
Antwort von roki100:
also ich habe irgendwo mal gelesen dass PRRAW - anders als ZRAW - ein echtes RAW ist. Über die sichtbare unterschiede im Bild, das weiß ich leider nicht. Bisher habe ich nur ein unterschied zu BRAW gesehen und da ist ZRAW schärfer, was aber bekanntlich an BRAW internal spatial noise reduction liegt (ich sehe das ein wenig eher vorteilhafter bei Sensoren ohne OLPF).
Antwort von Darth Schneider:
Jetzt kommt wieder mal der liebe roki mit seinem echten RAW, ich denke er vergisst dabei das das echte RAW doch auch nur digitale Daten sind….genau so wie das unechte RAW auch.
Ich meine gerade dir als Programmierer, das sollte dir doch bewusst sein…Das sind doch alles nur digitale Daten, genau so wie die die du selber programmierst.
Theoretisch, könntest du dir doch sicher mit etwas Zeit dein ganz eigenes RAW Format programmieren, nenne es dann RRaw..D
Warum auch nicht ?
Gruss Boris
Antwort von roki100:
Ja. Roki hat nicht geschrieben dass das andere schlechter ist....
Antwort von Darth Schneider:
Ich auch nicht, lies es bitte nochmal, hab noch etwas dazu geschrieben…
Gruss Boris
Antwort von roki100:
Ja aber was soll ich dazu schreiben... Ich habe nichts vergessen, sondern nur das genannt wie es ist.
Antwort von Darth Schneider:
Hä?
Nein, du hast doch nix vergessen, hab ich auch nirgendwo geschrieben…
Nochmal:
Nur eine Idee, von mir.
Gaaanz langsam..,
du könntest dir doch dein eigens Raw Video Format versuchen selber zu programmieren…natürlich müsstest du dann noch irgend eine Kamera hacken…oder es versuchen irgend einem Kamerahersteller zu verkaufen…
Dazu könntest du was schreiben, theoretisch…wenn du magst.
PS:
Schlechter und besser gibt es eigentlich nicht bei RAW, nur verschiedene Ansichten, denke ich.
Gruss Boris
Antwort von roki100:
Du schreibst, "er vergisst dabei..." und alles nur Digital etc.
RAW bedeutet in der digitale Foto&Video Welt aber, dass die Kamerainterne Bildmanipulationen deaktiviert sind...
Hast Du deine Bücher immer noch nicht gelesen? ;) Ansonsten siehe: https://de.wikipedia.org/wiki/Rohdatenformat
Antwort von micha2305:
Stellt man bei der Z-Cam Raw über HDMI ein, was gibt die Kamera dann raus ?
Antwort von cantsin:
micha2305 hat geschrieben:
Stellt man bei der Z-Cam Raw über HDMI ein, was gibt die Kamera dann raus ?
ProRes Raw, wenn ein Atomos Ninja V dranhängt.
Antwort von mash_gh4:
cantsin hat geschrieben:
micha2305 hat geschrieben:
Stellt man bei der Z-Cam Raw über HDMI ein, was gibt die Kamera dann raus ?
ProRes Raw, wenn ein Atomos Ninja V dranhängt.
nein -- ganz so einfach ist es nicht.
ProRes Raw ist im wesentlichen ein Dateiformat, während bei der Kommunikation über das HDMI-signal vielmehr ein spezielles "Protokoll" zur Anwendung kommen dürfte, dass die entsprechenden Roh-Daten verpackt bzw. encodiert anstelle der normalen Bilddaten über die Leitung schickt.
Genaueres darüber ist ja leider nirgends öffentlich dokumentiert, aber ein ähnliches vorgehen kennt man z.b. vom Axiom projekt u.a.
Antwort von cantsin:
mash_gh4 hat geschrieben:
cantsin hat geschrieben:
ProRes Raw, wenn ein Atomos Ninja V dranhängt.
nein -- ganz so einfach ist es nicht.
ProRes Raw ist im wesentlichen ein Dateiformat, während bei der Kommunikation über das HDMI-signal vielmehr ein spezielles "Protokoll" zur Anwendung kommen dürfte, dass die entsprechenden Roh-Daten verpackt bzw. encodiert anstelle der normalen Bilddaten über die Leitung schickt.
Das war mir schon klar. Aber während andere Kameras, die Raw über HDMI ausgeben, wahlweise ProRes Raw mit Atomos-Recordern oder Braw mit Blackmagic-Recordern ausgeben, unterstützt ZCam bisher nur ProRes Raw. Oder anders ausgedrückt: Ausser ProRes-Raw-Aufnahme ist mit ZCams HDMI-Raw-Ausgabe bisher nichts möglich.
Antwort von mash_gh4:
cantsin hat geschrieben:
Das war mir schon klar. Aber während andere Kameras, die Raw über HDMI ausgeben, wahlweise ProRes Raw mit Atomos-Recordern oder Braw mit Blackmagic-Recordern ausgeben, unterstützt ZCam bisher nur ProRes Raw. Oder anders ausgedrückt: Ausser ProRes-Raw-Aufnahme ist mit ZCams HDMI-Raw-Ausgabe bisher nichts möglich.
theoretisch wäre es ja möglich, dass die übertragung zw. kamera und rekordern in beiden fällen -- also bei ProRes Raw und BRAW -- genau die selben daten übermittelt und die eigentliche anpassung an die jeweiligen aufzeichnungsformate erst dort erfolgt. so ungefähr würde man das vermutlich auch sinnvollerweise handhaben, wenn es einen einheitlichen od. zumindest offengelegten industriestandard dafür geben würde. aber da sich beide entsprechenden urheber alle mühe geben, ein möglichst großes geheimnis aus ihrer jeweiligen umsetzung zu machen, ist das wohl eher unwahrscheinlich, obwohl vermutlich in beiden fällen gar nicht sonderlich viel aufregendes dahinterstecken dürfte.
Antwort von roki100:
es hat sich bisher für RAW intern noch kein Standard etabliert, geschweige denn für extern...
Antwort von mash_gh4:
roki100 hat geschrieben:
es hat sich bisher für RAW intern noch kein Standard etabliert, geschweige denn für extern...
doch! -- adobes DNG format war in vielerlei hinsicht mehr als vorbildlich, auch wenn es natürlich für nutzung im film- und videoumfeld sinnvoll gewesen wäre, die bildsequenzen längerfristig auch noch in irgendwelche andere container zu packen, um sie einfacher und effizienter benutzten zu können. aber prinzipell wäre das ja jederzeit recht einfach möglich gewesen, ohne im kern die kompatibilität bzw. einen etablierten standard aufgeben zu müssen.
aber natürlich ist ein derartige einzelbildaufzeichnung auch im falle von RAW-video-daten trickreicheren formen der sequentiellen codierung -- also GOP bzw. interframe-kompression -- im bandbreitenbedarf deutlich unterlegen.
Antwort von roki100:
mash_gh4 hat geschrieben:
roki100 hat geschrieben:
es hat sich bisher für RAW intern noch kein Standard etabliert, geschweige denn für extern...
doch adobes DNG format war in vielerlei hinsicht mehr als vorbildlich
Ja. Es gibt trotzdem kein Standard an dem sich irgendwelche Hersteller halten muss.... finde ich auch irgendwie schade.
auch wenn es natürlich für nutzung im film- und videoumfeld sinnvoll gewesen wäre, die bildsequenzen längerfristig auch noch in irgendwelche andere container zu packen, um sie einfacher und effizienter benutzten zu können.
Das ist schon gut so, weil sich das ganze auch mit RawTherapee usw. besser oder sauberer bearbeiten lässt.
Antwort von mash_gh4:
roki100 hat geschrieben:
auch wenn es natürlich für nutzung im film- und videoumfeld sinnvoll gewesen wäre, die bildsequenzen längerfristig auch noch in irgendwelche andere container zu packen, um sie einfacher und effizienter benutzten zu können.
Das ist schon gut so, weil sich das ganze auch mit RawTherapee usw. besser oder sauberer bearbeiten lässt.
naja -- das ein-und-auspacken in derartigen umgebenden containern ist ja in der regel keine große hexerei.
ganz viele formate benutzen in wahrheit ganz einfache tar od. zip-bündel, um komplexere strukturen in einzelnes file zu packen bzw. sie handlicher zu transportieren.
Antwort von micha2305:
Ich finde CDNG ganz gut.
Ob mir z.B. Prores RAW etwas bringt - ich weiß es nicht.
Mal ganz blöd gefragt: Bietet ProresRAW in der Praxis signifikante Vorteile gegenüber den anderen Prores Formaten ?
Antwort von cantsin:
micha2305 hat geschrieben:
Mal ganz blöd gefragt: Bietet ProresRAW in der Praxis signifikante Vorteile gegenüber den anderen Prores Formaten ?
Erst einmal ist die Frage, ob die Software, die Du nutzt, ProRes Raw überhaupt lesen und bearbeiten kann. Resolve scheidet da schon mal aus. Am besten ist die Unterstützung in Assimilate Scratch und FCPX.
Ansonsten ist der Praxisvorteil vor allem 12 ggü. 10bit Farbtiefe mit nachträglich einstellbarem Weißabgleich sowie das Fehlen festeingebackener Rauschfilterung (und, je nach Kamera, auch künstlicher Nachschärfung) Deines Materials; so wie auch bei CinemaDNG.
Antwort von pillepalle:
cantsin hat geschrieben:
micha2305 hat geschrieben:
Mal ganz blöd gefragt: Bietet ProresRAW in der Praxis signifikante Vorteile gegenüber den anderen Prores Formaten ?
Erst einmal ist die Frage, ob die Software, die Du nutzt, ProRes Raw überhaupt lesen und bearbeiten kann. Resolve scheidet da schon mal aus. Am besten ist die Unterstützung in Assimilate Scratch und FCPX.
Na ja, sagen wir mal so... mittlerweile ist Resolve eigentlich die einzige große NLE die ProRes RAW nicht unterstützt, denn alle anderen (FCPX, Premiere Pro, Avid Media Composer, Edius, Assimilate Scratch, Filmlight Baselight) tun es ja mittlerweile. Für Resolve User natürlich nervig (weil es keine technischen Gründe sind) aber ich habe mich mittlerweile damit abgefunden, dass es sich so bald nicht ändern wird.
VG
Antwort von micha2305:
In welchen Kameras wird ProresRaw eigentlich überwiegend verwendet ?
Welche Hersteller verwenden ProresRaw als internes RAW ?
Antwort von MrMeeseeks:
Komm schon Micha, ein wenig Mühe kannst du dir aber auch geben.
Das waren nun genau 2 Klicks. Da wird eine riesige und schöne Liste mit allen Kameras angezeigt.
https://www.atomos.com/compatible-camer ... ct=ninja-v
Deine zweite Frage ergibt natürlich wenig Sinn weil es ein reines externes Format ist um das dämliche Red Patent zu umgehen.
Antwort von cantsin:
MrMeeseeks hat geschrieben:
Deine zweite Frage ergibt natürlich wenig Sinn weil es ein reines externes Format ist um das dämliche Red Patent zu umgehen.
Die DJI Zenmuse X7 nimmt ProRes Raw intern auf. Das RED-Patent hat tatsächlich nichts mit interner oder externer Aufzeichnung zu tun, sondern betrifft jegliches Gerät, das datenkompromiertes, undebayertes Raw-Video aufzeichnet.
Nur hat Atomos (und hat auch DJI) eine Lizenz von RED - und haben alle Kamerahersteller, die ProRes Raw nur mit Atomos-Recordern aufzeichnen können, diese Lizenz nicht.
Antwort von mash_gh4:
MrMeeseeks hat geschrieben:
Deine zweite Frage ergibt natürlich wenig Sinn weil es ein reines externes Format ist um das dämliche Red Patent zu umgehen.
das Red patent bezieht sich in wahrheit nur auf die interne komprimierte aufzeichnung. extern dürfte man ohne bedenken beliebiges verwenden. ;)
Antwort von MrMeeseeks:
cantsin hat geschrieben:
MrMeeseeks hat geschrieben:
Deine zweite Frage ergibt natürlich wenig Sinn weil es ein reines externes Format ist um das dämliche Red Patent zu umgehen.
Die DJI Zenmuse X7 nimmt ProRes Raw intern auf. Das RED-Patent hat tatsächlich nichts mit interner oder externer Aufzeichnung zu tun, sondern betrifft jegliches Gerät, das datenkompromiertes, undebayertes Raw-Video aufzeichnet.
Nur hat Atomos (und hat auch DJI) eine Lizenz von RED - und haben alle Kamerahersteller, die ProRes Raw nur mit Atomos-Recordern aufzeichnen können, diese Lizenz nicht.
Die Tatsache dass es eine Kamera gibt die intern ProresRaw aufnimmt wusste ich tatsächlich nicht. Das Atomos hier als Bindeglied fungiert muss sich Red ja fürstlich bezahlen lassen.
Antwort von cantsin:
MrMeeseeks hat geschrieben:
Das Atomos hier als Bindeglied fungiert muss sich Red ja fürstlich bezahlen lassen.
Ja, tatsächlich so fürstlich, dass RED und Atomos die Zahlungen zur "business partnership" erklärten:
https://ymcinema.com/2019/01/24/atomos- ... s-patents/
...und Atomos vor dieser Einigung, und kurz vor seinem Börsengang, REDs Patentklage eine Bedrohung für den Geschäftserfolg der gesamten Firma nannte.
Antwort von cantsin:
Neuigkeiten zum Thema ZRAW:
"ZRAW decoder clone source code is now published and can be used anywhere you want.
It supports new ZRAW versions (extracts pure HEVC bitstream without reencoding) and old ZRAW versions (reconstructs Bayer CFA).
Code is very draft, but it works.
https://github.com/storyboardcreativity/ZRAW-Parser "
Quelle: http://personal-view.com/talks/discussi ... -published
Damit bestätigt sich die bisherige Vermutung, dass ZRAW in ZCams aktuellen Firmware-Versionen kein Bayer-Raw mehr ist (sehr wahrscheinlich wegen der Verletzung von REDs Patent auf komprimiertes, undebayertes Raw-Video).
Antwort von cantsin:
Und noch ein paar interessante Analysen des ZRAW-Hackers:
"Even more, I've researched that they prepared changing ZRAW to HEVC at the very beginning (I've found this code in v0.88, but it was disabled). This means, they knew that some day they would have to do it.
And this made me to search more info about old ZRAW codec. In leaked HiSilicon documents for Hi3559A I've found info that this chip supports hardware line-compression for RAW. Than I've checked - yes, Z CAM did not make ZRAW (it's just a label). ZRAW was just HiSilicon's line-compressor. That's why it's so primitive. Z CAM had no chance to make any other RAW implementation on E2 flagship, because they are bound by their not very good SoC choise (maybe at start they did not have plans to make cameras with 8K resolution and high framerates)."
https://personal-view.com/talks/discuss ... hed#Item_7
- HiSilicon ist eine Tochterfirma von Huawei, die die SoCs für Huawei-Geräte entwickelt, und wegen der politisch-wirtschaftlichen Spannungen mit den USA ihre ARM-Lizenz verlor.
Antwort von mash_gh4:
ich hab jetzt den code nur überflogen, aber so weit ich es sehen kann, wird zwar nun offenbar eine andere kompressionsmethode -- eben HEVC -- zusammen mit einer sehr einfache verschlüsselungsvariante genutzt, aber darin noch immer RAW daten verpackt bzw. diese in gleicher weise wie vorher von dieser software als PGM exportiert.
wenn ich mich darin nicht irre, sehe ich keinen grund, warum sich darüber sonderlich aufregen sollte. HVEC würde/wird im verlustfreien arbeitsmodus vermutlich weiterhin die gleichen vorteile wie völlig unkomprimiertes RAW zeigen, trotzdem aber zumindest eine bescheidene kompression ermöglichen. aber natürlich gibt es für RAW-bild-daten optimalere kompressionslösungen -- sowohl verlustbehaftete als auch lossless varianten.
Antwort von roki100:
also im Prinzip ist ZRAW nur ein gutes 12 Bit Codec, der sich wie RAW verhält... und wo ist dann der unterschied zum echten RAW?
Antwort von mash_gh4:
ZRAW ist einfach nur eine ziemlich beliebige bezeichnung für ein bisserl hokuspokus.
früher hat sich dahinter halt die sehe einfache verlustfreie RAW-komprimierung des verwendeten bildverarbeitsungsprozessors versteckt, und jetzt wird halt statt dessen HEVC und ein wenig XOR tarnung verwendet, um den rohen bitdatentstrom zu verpacken.
was diese HEVC umstellung betrifft, ist allerdings nirgends klar zu entnehmen, ob es sich dabei um den verlustfreien arbeitsmodus handelt und was sonst noch genau mit den daten passiert (stichwort: prebayering).
prinzipiell muss es aber nicht unbedingt eine gravierende verschlechterung darstellen, so wie das gerne kommuniziert wird, sondern vielmehr nur eine veränderte und möglicherweise sogar vorteilhafte technik der kompression. grundsätzlich könnten darüber weiterhin exakt die gleichen unveränderten RAW-ausgangsdaten zugänglich sein.
Antwort von cantsin:
mash_gh4 hat geschrieben:
prinzipiell muss es aber nicht unbedingt eine gravierende verschlechterung darstellen, so wie das gerne kommuniziert wird, sondern vielmehr nur eine veränderte und möglicherweise sogar vorteilhafte technik der kompression. grundsätzlich könnten darüber weiterhin exakt die gleichen unveränderten RAW-ausgangsdaten zugänglich sein.
Wenn ich den ZRaw-Hacker richtig verstehe, dann ist das aber nicht der Fall, denn laut ihm ist nur bei den "old ZRAW versions (reconstructs Bayer CFA" , während der HEVC-Bitstream keine undebayerten Daten mehr enthält. Er zieht auch als sein Resümee: "Z CAM just were lazy and did not try to do anything with RAW at all".
Antwort von mash_gh4:
cantsin hat geschrieben:
...während der HEVC-Bitstream keine undebayerten Daten mehr enthält. ...
genau das behaupte er aber auffälligerweise nicht bzw. nirgends! ;)
er nutzt statt dessen vielmehr die etwas ungewöhnliche sprechweise: "pure HEVC bitstream without reencoding"
wie immer bei infos auf personal-view, wird hier wiedereinmal viel wind um relativ triviale technische einsichten und hacks gemacht.
auf mich wirkt das ganz so, als könnte durchaus auch jemand aus dem zcam-entwicklungsumfeld hinter diesen veröffentlichungen stecken, um einerseits von juristisch bedenklichen verdächtigungen abzulenken, gleichzeitig aber interessierte nur weiter heranzulocken und die unterstützung in div. freier software voranzutreiben. ;)
