Infoseite // Blackmagic RAW

Frage von RedWineMogul:


Wie es aussieht hat Blackmagic einen eigenen Datensparenden RAW Codec vorgestellt:
https://www.blackmagicdesign.com/de/pro ... ckmagicraw



Antwort von Axel:

Wow! Seeeeehr cool.



Antwort von pillepalle:

Das klingt wirklich nach einem Hit! Soll später auch in die BMPCC4k implementiert werden... RAW für alle, die geben echt gas :)

VG



Antwort von Axel:

Scheint in Resolve 15 bisher nicht unterstützt zu werden? Oder liegt‘s an MacOS? Hab den ersten Download zu importieren versucht, sehe aber nur zwei exec-Dateien. Hab allerdings nicht alles gelesen & bin jetzt unterwegs ...



Antwort von pillepalle:

Ich glaube irgendwo gelesen zu haben es sei verfügbar ab Version 15.1, aber muss selber noch mal nachschauen.

VG



Antwort von dienstag_01:

Unabhängig davon, wie gut oder schlecht der Codec ist, frage ich mich, ob man ihm wirklich die Bezeichnung RAW verpassen musste. Führt nur zu weiterer Verwirrung.



Antwort von Axel:

Ja, ich sehe gerade, ab 15.1. BM ist zuzutrauen, dass sie es wenigstens so gut machen wie Apple/Atomos. Ich persönlich hoffe, dass auch Apple den Codec freundlicherweise für FCP übernimmt und nicht wegen PRR rumzickt.



Antwort von mash_gh4:

aus anwendersicht ist es wirklich eine tolle lösung, die wesentlich transparenter als ProResRaw wirkt. gemessen an den deutlich anspruchsvolleren maßstäben, wie man sie im freien softwareumfeld kennt, ist das ganze aber trozdem eher eine ziemlich dunkle und undurchsichtige schachtel, die sich nur sehr schlecht in wirklich freie lösungen einbinden lässt. alleine schon die lizenbestimmungen bzw. der zugriff auf das SDK schließen es praktisch aus, dass man das zeug unter linux in den freieren distribution mitausliefern od. nutzen kann...



Antwort von cantsin:

Das Versprechen ist also, dass 3:1-Kompression ungefähr die Qualität der bisherigen Lossless-Kompression bringt und 5:1-Kompression ungefähr die Qualität der bisherigen 3:1-Kompression. Das würde bedeuten, dass sich bei der Aufnahme der Platzbedarf der Kameradateien auf ca. 60% der heutigen Dateigrößen reduziert.

Aber eben auch, dass Blackmagic jetzt einen komplett proprietären RAW-Workflow aufzieht und den eventuell als Mittel verwendet, um Resolve am Markt durchzudrücken.

Die Frage ist, ob der Codec an Dritte lizenziert (oder sogar offen standardisiert) wird.






Antwort von Sammy D:

cantsin hat geschrieben:
...

Die Frage ist, ob der Codec an Dritte lizenziert (oder sogar offen standardisiert) wird. Offener Standard, lizenzfrei steht auf der BMD-Seite.



Antwort von pillepalle:

Natürlich muss man erst mal abwarten was da wirklich kommt, aber die Aussicht auf einen leichteren RAW Codec, nicht nur vom Datenvolumen sondern vor allem von der benötigten Prozessorleistung, ist für mich der interessante Punkt. Wenn ein Teil der rechenintensiveren Operationen bereits von der Kamera übernommen werden sind die Hardwareanforderungen des Rechners in der Post geringer und man muss sich nicht zwangsläufig mit Cinema DNG herum quälen, wenn man die Vorteile guter Dynamik und Farbtiefe nutzen möchte.

VG



Antwort von Darth Schneider:

Datensparender, leichter RAW Codec ? Tönt ja schon super, ist aber dann ja eigentlich nicht mehr RAW, sondern in irgend einer Form komprimiert und verkleinert, Das geht nicht ohne Datenverlust.
Gruss Boris



Antwort von DV_Chris:

Wie zu erwarten springt Blackmagic NICHT auf den ProRes RAW Zug auf. Auch sehe ich keine Kameras, die ProRes RAW aufzeichnen würde. Tut mir persönlich für Atomos leid, aber da hat man wohl aufs falsche Pferd gesetzt.



Antwort von iasi:

Ich musste gleich an RedRaw denken.

Wobei Q0 und Q5 mit variablen Bitraten doch neu sind.

Jedenfalls eine feine Sache.
Und in der Pocket 4k natürlich gern gesehen.



Antwort von Axel:

DV_Chris hat geschrieben:
Wie zu erwarten springt Blackmagic NICHT auf den ProRes RAW Zug auf. Auch sehe ich keine Kameras, die ProRes RAW aufzeichnen würde. Tut mir persönlich für Atomos leid, aber da hat man wohl aufs falsche Pferd gesetzt. Keine große Tragödie für Atomos. Brauchen nur noch BM Raw als FW-Update hinzufügen. Oder irre ich mich? Ein großer Coup dagegen für BM. Jetzt muss, wie gesagt, nur noch Apple seinen Stolz runterschlucken und BM Raw im Oktober in FCP10.5 parat haben.



Antwort von Onkel Danny:

Wieder mal köstlich zu sehen, wie einige hier schon losfeuern, ohne sich genauer informiert zu haben.
Obwohl alle Infos vorhanden sind. Stichworte:"geht nicht in Resolve... " oder "Lizenz..."

Die Idee ist sehr gut und bietet folgende Vorteile:
-Geringerer Hardware Hunger in beiden Varianten. Ist natürlich für alle Anwender gut.
-Constant Bitrate: Höhere Kompression(kleinere Dateien), bei noch immer guter Qualität. Gut für alle Heulsusen, die sich wegen der Filesize beschweren.
-Constant Quality: genau das richtige für mich, variable Bitrate für gleich bleibende Qualität, je nach aufgenommenen Motiv.

Beide Varianten kommen dann jetzt auch in einem Container und keine Einzeldateien mehr.
Die Lookfiles(sidecar) sind auch nett. Der Player erstmal nur für Mac, ist natürlich völliger Unsinn.

Wird es erstmal nur als Beta für die Mini Pro geben. Dann aber nach und nach für andere Kameras von BM nachgereicht werden, inklusive der Pocket 4k.

Das heißt wohl kein Proresraw ;) Aber Dank des SDK, kann es in alle anderen NLE's implementiert werden.
Mal sehen, wer es im Laufe der Zeit, alles übernehmen wird.

greetz



Antwort von slashCAM:


Jetzt wird es interessant: Blackmagic bringt ein eigenes RAW-Format, welches auf eine neue Verarbeitung der Sensordaten setzen soll. Dafür wurde ein Codec entwickelt, wel...



Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Blackmagic RAW vorgestellt -- das beste aus zwei Welten? // IBC 2018



Antwort von filmkamera.ch:

Wir haben mal eben kurz ein paar Clips in BRAW mit unterschiedlicher Kompression gedreht:

Lässt sich auf einem MacBook Pro (mid 2016) mit 16GB Ram alles ruckelfrei abspielen.

Und auch 60 f/sec. bei 4,6k auf einer Speicherkarte sind kein Problem.






Antwort von wolfgang:

DV_Chris hat geschrieben:
Wie zu erwarten springt Blackmagic NICHT auf den ProRes RAW Zug auf. Auch sehe ich keine Kameras, die ProRes RAW aufzeichnen würde. Tut mir persönlich für Atomos leid, aber da hat man wohl aufs falsche Pferd gesetzt. Tja, das kommt davon wenn man das eigene System nur abschotten will. Ist halt Pech - vor allem wenn dann die Konkurrenz das System offen für alle Plattformen anbietet.



Antwort von freezer:

Es scheint, als hätten sie die Idee von Cineform RAW und Firstlight weitergeführt. Damit kann man nun am Set auch bequem den Look vorbereiten, die Änderungen stehen dann in der sidecar Datei bereits für die Weiterverarbeitung in allen anderen Plattformen zur Verfügung. Und dann auch noch schön ressourcenschonend. Wenn sie bei der Lizenzierung auch noch alles richtig machen, dann könnte das auch außerhalb der Softwarewelt eine weite Verbreitung finden und ein weit verbreiteter Standard werden.



Antwort von Axel:

Habe mir das Blackmagic Raw SDK heruntergeladen und für MacOS installiert. Ergebnis: Quicklook zeigt nun eine Thumbnail-Vorschau. Dritt-Hersteller hätten "womöglich" eigene Lizenzvorschriften, die beachtet werden müssten, schreibt ein unglaublich langes Lizenz-Readme. Liest sich für mich als Software-Laien wie eine indirekte Aufforderung zum Hacken. Wäre schön, wenn ich gar nicht auf die offizielle Unterstützung durch FCP warten müsste.



Antwort von j.t.jefferson:

"Darth Schneider" hat geschrieben:
Datensparender, leichter RAW Codec ? Tönt ja schon super, ist aber dann ja eigentlich nicht mehr RAW, sondern in irgend einer Form komprimiert und verkleinert, Das geht nicht ohne Datenverlust.
Gruss Boris Bei Red gehts schon sein 2007. 8K geht sogar bei 14:1 und sieht noch super aus. Hab mich eh gewundert warum das bis jetzt noch keiner von Red nachgemacht hat. Hab auch mal nen Vergleich gemacht zu weniger komprimierten Material und man sieht eigentlich keinen/wenig Unterschied....müsste man schon stark ranzoomen.



Antwort von Jost:

freezer hat geschrieben:
Es scheint, als hätten sie die Idee von Cineform RAW und Firstlight weitergeführt. Damit kann man nun am Set auch bequem den Look vorbereiten, die Änderungen stehen dann in der sidecar Datei bereits für die Weiterverarbeitung in allen anderen Plattformen zur Verfügung. Und dann auch noch schön ressourcenschonend. Wenn sie bei der Lizenzierung auch noch alles richtig machen, dann könnte das auch außerhalb der Softwarewelt eine weite Verbreitung finden und ein weit verbreiteter Standard werden. Das sehe ich auch so. Auf jeden Fall ist man nicht mehr von CinemaDNG abhängig, was ein Adobe-Standard ist.
BM hat jetzt alles allein in eigener Hand: Hardware, Codec, Bearbeitungsprogramm.

Seltsam ist freilich die Grafik:




"Uncompressed" kann man bislang mit der BM Ursa nicht aufnehmen. Nur in CDNG - ein 4,6K Bild hat eine Größe von rund 13 MB, sprich 390 MB die Sekunde bei 30fps. Wie BM jetzt plötzlich auf 548 MB/s kommt, ist mir absolut schleierhaft. Ein fiktiver Wert wohl, um BRAW in einem besseren Licht erscheinen zu lassen.
Zumal in der reinen Aufnahme-Praxis der Unterschied zwischen CDNG und BRAW unerheblich ist: Beides kann man in 4,6k und 30Fps mit einer einzigen CFast aufnehmen.

Ich nehme mal an, BRAW wird für die neue Pocket benötigt, um irgendwie noch UHD 60p auf eine CFast zu quetschen. Mit CDNG wäre das nicht gegangen. Ein Bild hat rund 8 MB, also 480 MB/s. Das schreibt dauerhaft keine CFast und auch nicht eine externe T5. Es würde auch nur mit ausgewählten SSDs funktionieren.

Kleine Schmankerl am Rande. In den Pocket-4K-Specs ist von Raw die Rede, aber nicht von CDNG. Im neuen Ursa-Manual fehlt urplötzlich die bislang obligatorische Auflistung, für welchen Codec man wie viele CFast-Karten benötigt. Das wird wohl überarbeitet.



Antwort von motiongroup:

wolfgang hat geschrieben:
DV_Chris hat geschrieben:
Wie zu erwarten springt Blackmagic NICHT auf den ProRes RAW Zug auf. Auch sehe ich keine Kameras, die ProRes RAW aufzeichnen würde. Tut mir persönlich für Atomos leid, aber da hat man wohl aufs falsche Pferd gesetzt. Tja, das kommt davon wenn man das eigene System nur abschotten will. Ist halt Pech - vor allem wenn dann die Konkurrenz das System offen für alle Plattformen anbietet.
ist es ja nicht, muss ja nur ne Lizenz gelöst werden.. Kopfschütteln



Antwort von cantsin:

motiongroup hat geschrieben:
ist es ja nicht, muss ja nur ne Lizenz gelöst werden.. Wo kann man das denn?



Antwort von Axel:

cantsin hat geschrieben:
motiongroup hat geschrieben:
ist es ja nicht, muss ja nur ne Lizenz gelöst werden.. Wo kann man das denn? So, wie es aussieht, öffnet Grant Petty ein Hack-Hintertürchen, das es "erlaubt" (technisch gesehen), BRAW in FCP X zu integrieren. Würde Apple gerne die Lizenz für ProRes Raw an andere verkaufen? Oder nicht, um FCP X als einzige Software anzupreisen, die das kann? Die Frage könnte bald akademisch werden, nämlich dann, wenn sich herausstellt, dass BRAW eine gute, wenn nicht bessere Alternative ist. Nicht wegen ein paar Kröten.



Antwort von wolfgang:

cantsin hat geschrieben:
motiongroup hat geschrieben:
ist es ja nicht, muss ja nur ne Lizenz gelöst werden.. Wo kann man das denn? Ja wo bitte kann man für PRR für eine Windows App eine Lizenz lösen?

Wenn du schon den Kopf schüttelst, dann doch bitte mal in der Frage wo die Windowsuser künstlich eingeschränkt worden sind.






Antwort von motiongroup:

Das werden die Anbieter der jeweiligen Software für den Kunden erledigen so sie den Codec integrieren wollen..

Stellt sich eben die Frage ob das die Hersteller wollen..

Als Beispiel ProX von Magix
DVCPRO und AVC-Intra erfordern eine kostenpflichtige Erstaktivierung.



Antwort von mash_gh4:

Jost hat geschrieben:
Auf jeden Fall ist man nicht mehr von CinemaDNG abhängig, was ein Adobe-Standard ist.
BM hat jetzt alles allein in eigener Hand: Hardware, Codec, Bearbeitungsprogramm. was bitte soll daran besser sein, das man jetzt nicht mehr von Adobe und Apple abhängig ist, sondern auch BMD uns ein ganz ähnliches, vermutlich aber sogar noch deutlich problematischeres, theater aufzuzwingen versucht?

wie gesagt, ich sehe durchaus ein paar vorzüge dieses neuen ansatzes die aus endanwendersicht recht erfreulich wirken -- schließlich ist es ja wirklich ein unhaltbarer zustand, dass man bisher mit RAW ansäzten in verschiedenen anwendeungen kaum auch nur ein einigermaßen ähnliche resultate im bezug auf gegebenes ausgansmaterial erzielen könnte --, trotzdem sind auch die nachteile und bedenken, die sich einem im zusammenhang mit diesem vorstoß aufdrängen, ziemlich gewichtig.

es ist zwar toll, dass das betreffende SDK gleich von anfang an z.b. auch linux unterstützt, trotzdem ist das ganze nur in form von fertig kompilierten binaries zugänglich und die dahinter verborgene technische spezifikation völlig unzugänglich -- von damit verbundenen lizenz- und patentfragen einmal ganz abgesehen.

in der hinsicht ist/war adobes DNG schon eine wesentlich vorbildlichere lösung. dort hat man sich zwar nicht darum gekümmert, fertige libraries bereitzustellen, um das ganze möglichst einfach in unterschiedlicher software nutzten zu können, aber dafür hat man die technische funktionsweise bzw. notwendigen rahmenvorgaben in einer weise offen gelegt, die von anfang an auch völlig freie und unabhängige implementierungen erlaubt haben.

BMD hat sich allerdings noch nie so recht an derartige offene standards gehalten, geschweige denn vorbildlich an deren entstehung und offenlegung mitgewirkt. auch schon im falle von DNG haben sie die betreffenden spezifikationen völlig ignoriert und einfach irgendwelche propritären kompressionverfahren in die betreffenden container reingepackt, die niemand außer ihnen öffnen konnte. mit dem aktuellen ansatz wird diese vorgehensweise nur noch weiter auf die spitze getrieben.

in diesem sinne halte ich es für wirklich angebracht, dass man in diesem speziellen fall nicht nur die oberflächlichen praktischen vorzüge und werbeversprechen auf ihre praktisch tauglichkeit hinterfragt, sondern auch mitbedenkt, welche folgen derartige undokumentierten und herstellerdominierte fileformate mit sich bringen. speziell apple hat uns diesbezüglich ja ohnehin einiges lernen bzw. ganz praktisch erfahren lassen. was uns BMD hier serviert, dürfte aber in wahrheit noch deutlich einengender und unoffener sein als z.b. prores. am ehesten würde ich es mit div. red-lösungen vergleichen, die halt nur niemanden außerhalb dieses relativ kleinen anwenderkreises interessiert haben. im falle eines produkts für die massen, wie es bei BMD der fall ist, ist das dann aber doch wieder eine ganz andere geschichte,



Antwort von Jott:

Konkurrenz belebt das Geschäft. BM hat wohl eingesehen, dass deren bisheriges Einzelbild-RAW-Gewurstel - obwohl immer gern schöngeredet - Quark war.

Jetzt bitte aber noch mal der bekannte Shitstorm à la „ist doch gar kein richtiges Raw“ oder „ist physikalisch gar nicht möglich“. Das muss schon sein! :-)



Antwort von DV_Chris:

Raw Gewurstel? Vielleicht auf veralteter Mac Pro Hardware.

BMD setzt hier einen neuen Industriestandard, auch wenn der vfxhansi in Bezug auf Prores Raw schon die Weltherrschaft herbeiphantasiert hat.

Wie bereits erwähnt: für Atomos tut es mir leid.



Antwort von Jott:

Cinema DNG war kein Gewurstel? Also bitte.



Antwort von Axel:

CEO Petty sagt in seiner BRAW-Ansprache auf Youtube: "Das Problem ist, dass dieses Format eine Art von Alptraum ist, aus Einzelbildern gemacht ist und eine Art dummer Eimer mit Pixeln drin ist."



Antwort von motiongroup:

BMD setzt hier einen neuen Industriestandard, auch wenn der vfxhansi in Bezug auf Prores Raw schon die Weltherrschaft herbeiphantasiert hat. Der steht bei mir in der Ignore Liste oder warum sehe ich keinen Beitrag von vfxhansi...

Wird spannend.. ProResRaw ist aktuell wie auch der BRaw nur in den Eigenen Anwendungen verfügbar und somit ein Spezialfall eines Codecs wie 100 andere auch... die ProResRaw implementation in Fcpx ist auch noch nicht so umgesetzt wie sie es von den Features her möglich wäre und somit nicht zu bewerten..

Die neuen Versionen werden sicher neue Features bereitstellen und aus die Maus.. in der Summe ist es doch so das hier wieder mal ein Fass aufgemacht wird für eine neue Technologie die erstens die wenigsten nutzen und nutzen werden ebenso wie bei ProResRaw und die die nutzen werden besorgen sich die Infrastruktur so oder so..

Jeder verwendet das was er braucht und fertig, das das gebashe von gewissen Leuten bei solchen News immer wieder aufs neue Hervorspült ist doch wirklich nichts mehr Neues und generiert nach Jahren nur noch Kopfschütteln ebenso wie Copypast Fraktion die dies Geschwurbel in ihre eigenen Foren und Blogs einfließen lassen mit der dümmsten aller Angewohnheiten“ kindliche Schadenfreude“



Antwort von Jost:

mash_gh4 hat geschrieben:
Jost hat geschrieben:
Auf jeden Fall ist man nicht mehr von CinemaDNG abhängig, was ein Adobe-Standard ist.
BM hat jetzt alles allein in eigener Hand: Hardware, Codec, Bearbeitungsprogramm. was bitte soll daran besser sein, das man jetzt nicht mehr von Adobe und Apple abhängig ist, sondern auch BMD uns ein ganz ähnliches, vermutlich aber sogar noch deutlich problematischeres, theater aufzuzwingen versucht? Weil man Zugriff auf die komplette Wertschöpfungskette hat und somit die Entwicklungsgeschwindigkeit selbst bestimmen kann.
Grundsätzlich muss BM - anders als Adobe oder Apple - nicht Bittebitte bei Anderen machen, wenn ein neuer Codec auf den Markt geworfen wird.
Hardware und Bearbeitungssoftware sind schließlich vorhanden und kommen aus dem eigenen Haus. Adobe und Apple fehlt die Hardware. Das ist eine eingeschränkte Konkurrenzfähigkeit und ein Wettbewerbsnachteil.

Was das CDNG-Gewusel angeht, hast Du natürlich Recht. Man kann trefflich darüber streiten, ob es an CDNG liegt, dass bei 4,6/60p zwei Clips auf zwei Datenträger entstehen, die dann mühsam händisch zusammengeführt werden müssen.
Oder ob BM eine falsche Entscheidung getroffen hat, als auf CFast oder SSD gesetzt wurde, obwohl eine M2 als Speichermedium schnell genug gewesen wäre, 4,6/60p als einen Clip zu schreiben.

Ob man das CDNG-Gewusel jetzt los ist, ist eine ganz andere Frage. Das wäre nur der Fall, wenn sich BRAW 4,6/60p auf einem einzelnen Speichermedium schreiben lässt. Wenn die Angabe von BM stimmen, liegt man mit BRAW 4,6K/60p in bester Qualität allerdings bei 550 MB/s. Das ist knapp unterhalb dessen, was Sata überträgt und was SSDs dauerhaft schreiben könnten. Eine einzelne CFast ist dafür bereits zu langsam.
Wir werden ja bald hören, was man mit einer Ursa Mini Pro anstellen muss, um BRAW 4,6/60p in bester Qualität aufnehmen zu können.
Wer sagt denn, dass unter BRAW nicht wieder zwei Clips entstehen, die händisch zusammengeführt werden müssen?



Antwort von DV_Chris:

Vfxhansi = RSK.

BRAW wird in Kameras implementiert. Damit auf einen Schlag weit höhere Verbreitung, damit schnellere Adaptierung durch NLE Hersteller.






Antwort von Rick SSon:

wohoo,

endlich noch ein Grund mehr für mich komplett auf BM und Resolve umzusteigen. Wahrscheinlich steht jetzt BRAW in Sachen Moire endlich nicht mehr ProRes nach. Und diese beschissenen Arschbackenprogrammierer von Adobe lasse ich gerne hinter mir. Das hat BM tatsächlich noch gefehlt und wenn ich den chart richtig deute, müsste 4k50p sogar auf SD Karte möglich sein. Wohooo :-)



Antwort von mash_gh4:

Jost hat geschrieben:
Weil man Zugriff auf die komplette Wertschöpfungskette hat und somit die Entwicklungsgeschwindigkeit selbst bestimmen kann.
Grundsätzlich muss BM - anders als Adobe oder Apple - nicht Bittebitte bei Anderen machen, wenn ein neuer Codec auf den Markt geworfen wird. das BMD damit berechtigte interessen verbindet ist mir ohnehin klar.

das ändert aber nichts daran, dass wir als anwender die dinge aus einer völlig anderen perspektive heraus sehen sollten/müssen. da sind dann offene standards und die möglichkeit, ganz nach belieben verschiedene programme und hardwarelösungen nutzen zu dürfen, durchaus ein ziemlich wichtiger wert.

ich persönlich mach einen großen bogen um all die hersteller, die einem gegeteiliges aufzwingen wollen.

was die frage image sequences vs. streaming container betrifft, halt ich natürlich auch letzteres für techn. deutlich effizienter bzw. einen einschneidenden fortschritt.



Antwort von motiongroup:

Vfxhansi = RSK. never ever wie kommst Du darauf.. wobei selbst wenns so wäre Wayne kümmerts außer dich wie es scheint..
BRAW wird in Kameras implementiert. Damit auf einen Schlag weit höhere Verbreitung, damit schnellere Adaptierung durch NLE Hersteller. wo und wer?..BM na das ist klar wer sonst ?? Wenns kommt kommts..
Wers braucht wirds verwenden..
ich brauchs nicht ergo ists mir wurst wers implementiert..



Antwort von Funless:

Ich versteh‘ ehrlich gesagt auch nicht weshalb gleich nach solchen News immer wieder irgendwelche Grabenkriege gestartet werden. Und zwar von erwachsenen Menschen die urplötzlich zu präputertären Blagen auf dem Schulhof mutieren.

Die Zeit wird‘s zeigen ob es sich durchsetzen wird und diejenigen die richtig Geld verdienen die werden ihren Workflow entsprechend ändern wenn es für sie einen Benefit bringt oder wenn kein Benefit dann lassen es links liegen und kümmern sich weiterhin um ihr Daily Business mit dem was sie haben. Jedenfalls jammern sich nicht in irgendwelchen Foren rum.



Antwort von roki100:





Antwort von roki100:

"Sammy D" hat geschrieben:
Offener Standard, lizenzfrei steht auf der BMD-Seite. Super! Ob der Codec in der OpenSource Cinema Cameras auch aufgenommen wird? https://www.apertus.org



Antwort von mash_gh4:

roki100 hat geschrieben:
"Sammy D" hat geschrieben:
Offener Standard, lizenzfrei steht auf der BMD-Seite. Super! Ob der Codec in der OpenSource Cinema Cameras auch aufgenommen wird? https://www.apertus.org das mag zwar auf der webpage stehen, aber zumindest zum gegenwärtigen zeitpunkt hat das mit der wirklichkeit genauso wenig zu tun wie die lustig bunten studio-illustrationen auf der resolve homepage.

momentan findet man also praktisch überhaupt keine infos über techn. interna dieser lösung geschweige denn irgendwelchen offenen quellcode, der über die fertig kompilierten binaries hinausgehen würde.

im übrigen steht der anwendung im freien umfeld vermutlich nicht nur die relativ restriktiven lizenzbedingungen entgegen, die man schon beim download des SDKs akzeptieren muss, sondern vermutlich auch jene patente, von denen in obigem video die rede ist.



Antwort von motiongroup:

Ich versteh‘ ehrlich gesagt auch nicht weshalb gleich nach solchen News immer wieder irgendwelche Grabenkriege gestartet werden. Und zwar von erwachsenen Menschen die urplötzlich zu präputertären Blagen auf dem Schulhof mutieren. ich auch nicht, sind vermutlich die denen sie in der Schulzeit die Pausenbrote und die Schulmilch geklaut haben..;)



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:

Super! Ob der Codec in der OpenSource Cinema Cameras auch aufgenommen wird? https://www.apertus.org das mag zwar auf der webpage stehen, aber zumindest zum gegenwärtigen zeitpunkt hat das mit der wirklichkeit genauso wenig zu tun wie die lustig bunten studio-illustrationen auf der resolve homepage. kann sein dass Du recht hast was BMRAW angeht, doch das die "lustig bunten studio-illustrationen" mit der Wirklichkeit wenig zu tun haben, da täuschst Du dich. :) Bei einigen (z.B.) Coloristen, sieht es tatsächlich so aus.

Siehe z.B.


Dennoch, vielleicht hier in DE wenig, weil die meisten Adobe Infiziert sind (Aufgrund vielen Tutorials? )... ;) Ich kenne z.B. kaum welche, die BM Fusion benutzen, stattdessen wird AfterEffects monatlich bezahlt, weil der AE-Experte es leichter hat, passendes YouTube-Video Tutorial zu finden? Und DAS (!) hat sehr wohl was mit der Wirklichkeit zu tun. ;)






Antwort von WoWu:

Mit mehreren neuen Technologien, wie einem ausgefeilten Demosaicing-Algorithmus, liefert Blackmagic RAW .... Also doch kein RAW sondern nur „look-a-like“

Und was ist nun mit ProResRAW ?
War wohl nix ?



Antwort von mash_gh4:

WoWu hat geschrieben:
Also doch kein RAW sondern nur „look-a-like“ wer richtiges RAW will, nimmt also wohl besser auch weiterhin das, was du für TIFF od. gar JPEG hältst. ;)



Antwort von Jott:

Atomos trommelt auf der IBC für fcp x mit ProRes RAW, da ist viel los, eben auch wegen der Big Names im Boot. Für Blackmagic-Kameras interessiert sich das Messepublikum (Broadcaster-Szene) nicht so.

https://www.film-tv-video.de/event/2018 ... w-theater/

Da BM, wie ich es verstanden habe, Teile des raw-Processings schon mal in der Kamera macht, wird das wohl kameraseitig proprietär bleiben müssen. Oder nicht?



Antwort von WoWu:

mash_gh4 hat geschrieben:
WoWu hat geschrieben:
Also doch kein RAW sondern nur „look-a-like“ wer richtiges RAW will, nimmt also wohl besser auch weiterhin das, was du für TIFF od. gar JPEG hältst. ;) Nee, wer richtig RAW will, nimmt die Luminanzsignale des Sensors.



Antwort von nic:

Jott hat geschrieben:
Atomos trommelt auf der IBC für fcp x mit ProRes RAW, da ist viel los, eben auch wegen der Big Names im Boot. Für Blackmagic-Kameras interessiert sich das Messepublikum (Broadcaster-Szene) nicht so.

https://www.film-tv-video.de/event/2018 ... w-theater/

Da BM, wie ich es verstanden habe, Teile des raw-Processings schon mal in der Kamera macht, wird das wohl kameraseitig proprietär bleiben müssen. Oder nicht? Keine Ahnung was das bedeutet. Es war bisher der kleinste gemeinsame Nenner der Rawformate, zumindest nicht in der Kamera zu debayern. Ich hätte da gerne mehr Informationen.



Antwort von cantsin:

7nic hat geschrieben:
Keine Ahnung was das bedeutet. Es war bisher der kleinste gemeinsame Nenner der Rawformate, zumindest nicht in der Kamera zu debayern. Ich hätte da gerne mehr Informationen. Frag mich auch, was es konkret bedeutet, dass das Debayering in zwei Schritte aufgeteilt wird, einen in der Kamera und einen in der Post - und wie das funktioniert.



Antwort von DV_Chris:

Dass Atomos getrommelt hätte wäre mir nicht aufgefallen. Und der Besuch der Sessions hielt sich in Grenzen.



Antwort von cantsin:

DV_Chris hat geschrieben:
Dass Atomos getrommelt hätte wäre mir nicht aufgefallen. Und der Besuch der Sessions hielt sich in Grenzen. Gibt's denn irgendwelche Ankündigungen, dass ProRes RAW in andere Software (als nur FCPX) und Kameras einzieht?

Aus meiner Sicht wäre es ja gut, wenn sich ein Wettbewerb der Formate entwickeln würde. BM hat nun mit seinem SDK vorgelegt - und auch wenn das keine offene Spezifikation ist, wird das sicher dafür sorgen, dass das Format in vieler anderer Software unterstützt wird. Auch die programmübergreifende Metadaten-/Parameter-Unterstützung mit Sidecar-Dateien und der Möglichkeit, BRAW auch als Renderformat zu verwenden, sind eine ziemliche Ansage ggü. ProRes Raw.

Sollten Apple und Atomos nicht mehr dafür tun, dass andere Hersteller ihr Format verwenden, endet ProRes Raw wie Cineform RAW.



Antwort von DV_Chris:

Was man so hört halten sich alle NLE Hersteller bedeckt. "We're looking into it". Apple scheint nicht der beliebteste Verhandlungspartner zu sein ;-)






Antwort von wolfgang:

DV_Chris hat geschrieben:
Was man so hört halten sich alle NLE Hersteller bedeckt. "We're looking into it". Apple scheint nicht der beliebteste Verhandlungspartner zu sein ;-) Wie war das mit der Sperrfrist von einem Jahr nach dem Launch von PRR? Bloß ein Gerücht?

Die Anderen starten zumindest gleich offen, und zumindest eine Enteicklungsabteilung einer NLE findet das neue raw mal interessant.

Und nein, ich wünsche mir da keine Konkurrenz. Denn da kommen immer Anwender unter die Räder. Bis die Windows Apps PRR können sind meine EVA1 + Shogun Inferno veraltet. :(



Antwort von Jott:

„As you can see on the user voice platform, support for ProRes RAW is under review.
Sorry, I don't have a better answer as to when it will be added. But I'm sure it will be added in a future release.

Best,
Rameez“

Adobe-Mann in deren Forum, wo alle drum betteln.

Wir werden sehen.



Antwort von prime:

Jott hat geschrieben:
Atomos trommelt auf der IBC für fcp x mit ProRes RAW, da ist viel los, eben auch wegen der Big Names im Boot. Für Blackmagic-Kameras interessiert sich das Messepublikum (Broadcaster-Szene) nicht so. Es würde mich wundern wenn es so viel Begeisterung bei Broadcastern geben würde für irgendein RAW Format (egal ob von Apple, Red oder BMD etc.).

4:2:2 / 8 oder 10 bit? Ja? Super - mehr haben wir nicht, brauchen wir nicht ;-)



Antwort von WoWu:

Ich bin mal gespannt, wie viele andere Hersteller da wirklich mitziehen, denn durch diese Prozessaufspaltung würde ja tatsächlich ein Teil ins NLE wandern und das Signal damit ziemlich proprietäre machen und was die Metadaten angeht, erst recht.
Ich tippe mal drauf, dass die das ganze De-Mosaicing in der Kamera machen und nur noch die farbbezogenen Filterungen im NLE.
Also drei Luminanzwerte pro Pixel, die erst im NLE gefiltert und bearbeitet werden.
Einwenig deutet auch die Vorführung darauf hin, dass man ein flaches Videosignal bekommt, sobald man es aus dem Metadatenordner zieht.
Wenn da mal nicht wieder der Berg kreist.
Die Frage ist eben nur, warum sie, nach der vollmundigen Ankündigung, so stillschweigend wieder von Apple abgerückt sind.
Wenn das mal nicht nur ein Derivat - angereichert mit Metadaten- ist.

Nun ja. Wir wissen bis heute noch nicht, was aus PRR eigentlich rauskommt, mal sehn, ob wir mehr über dieses Format erfahren.
Die Vollmundigkeit, nun das Non-plus-ultra gefunden zu haben, hatten wir schon bei der PRR Ankündigung.
Überraschend, dass es nun doch noch eine Steigerung gibt.



Antwort von cantsin:

Tja, ob echtes RAW oder nicht - das 4.6K-Beispielmaterial von Blackmagics Website läuft hier flüssig auf nicht mehr ganz taufrischer Hardware (Haswell-i7-Sechskerner + GTX970).

Was aber auffällt: Im Raw-Tab lassen sich nur noch Weissabgleich, Belichtung und Gamma (einschließlich Sättigung, Kontrast, Midpoint, Highlight Rolloff und Shadow Rolloff) regeln, wobei jeder Eingriff in die letztgenannten Gamma-Parameter automatisch bedeutet, dass man Blackmagics Standard-Gammas (Film/Video/Extended Video) hinter sich lässt.

Die für CinemaDNG verfügbaren RAW-Parameter Sharpness, Highlights, Shadows, Color Boost, Midtone Detail, Lift und Gain fallen weg. (Natürlich können Lift, Gain, Sättigung etc. auch über die reguläre Farbkorrektur geregelt werden.) Schätze daher, dass diese Parameter bereits beim Debayering in der Kamera festgelegt werden.



Antwort von mash_gh4:

WoWu hat geschrieben:
Ich bin mal gespannt, wie viele andere Hersteller da wirklich mitziehen, denn durch diese Prozessaufspaltung würde ja tatsächlich ein Teil ins NLE wandern und das Signal damit ziemlich proprietäre machen und was die Metadaten angeht, erst recht.
Ich tippe mal drauf, dass die das ganze De-Mosaicing in der Kamera machen und nur noch die farbbezogenen Filterungen im NLE.
Also drei Luminanzwerte pro Pixel, die erst im NLE gefiltert und bearbeitet werden. ich glaube der springende punkt an der ganzen sache ist die konzentration auf scene referred farbinformation.

das sollte man zwar in der tat nicht unbedingt gleich mit RAW-verarbeitung in einen topf werfen, weil hier viele verarbeitungsschritte und eingriffsmöglichkeiten, die sich aus dem physikalischen aufbau von sensoren mit bayer pattern ergeben, bereits erledigt sind bzw. ausgeklammert werden, trotzdem erhält mn damit einen ziemlich effektiven zugriff auf jenen elementaren farbinformationen, wie sie der sensor tatsäch liefert.

das muss auch nicht unbedingt in proprietärer weise umgesetzt werden, weil ja ACES genau für diese form prozessierung bzw. farbeingriffe mittlerweile ganz wunderbare technische rahmenstandards, umsetzungsempfehlungen und austauschformate bereitstellt. wenn man in diesem zusammenhang die daten in etwas benutzerfreundlichere container packt, vernünftiger komprimiert usw., mag das zwar im hinblick auf die praktische nutzung bzw. anwenderfreundlichkeit eine eine große rolle spielen, aus technischer sicht bleibt es aber eher unbedeutendes beiwerk.
Was aber auffällt: Im Raw-Tab lassen sich nur noch Weissabgleich, Belichtung und Gamma (einschließlich Sättigung, Kontrast, Midpoint, Highlight Rolloff und Shadow Rolloff) regeln, wobei jeder Eingriff in die letztgenannten Gamma-Parameter automatisch bedeutet, dass man Blackmagics Standard-Gammas (Film/Video/Extended Video) hinter sich lässt.
Die für CinemaDNG verfügbaren RAW-Parameter Sharpness, Highlights, Shadows, Color Boost, Midtone Detail, Lift und Gain fallen weg. (Natürlich können Lift, Gain, Sättigung etc. auch über die reguläre Farbkorrektur geregelt werden.) Schätze daher, dass diese Parameter bereits beim Debayering in der Kamera festgelegt werden. das sollte eigentlich nicht weiter verwundern. die eingriffsmöglichkeiten, die sich hinter diesem RAW bedienungsfeld verbergen, fallen ganz grundsätzlich in zwei kategorien auseinander:

diejenigen, die sich nur auf fertig debayerte farbinformation stützen (also z.b. exposure-korrrektur, weißabgleich -- dinge also, die sich im grunde auch schon mit LOG-material sauber umsetzten lassen),

und solche, die tatsächlich einen rückgriff auf die ausgangsdaten bzw. ihren bezug zur räumlichen anordnung der sensel benötigen (bspw. auswahl der debayer algorithmen, highlight color reconstruction...).

welchen stellenwert man zweiterer gruppe zugesteht, ist nicht ganz so einfach zu beantworten. wenn es bereits in der kamera sauber bzw. auf die gegeben technischen umstände hin angepasst optimal umgesetzt wird, gibt's im normalfall nicht viel grund, warum man das unbedingt nachträglich anders machen wollen soll. im übrigen muss man wohl auch einsehen, dass es hier ja nicht nur um diese paar operationen geht, für die wie in guten photo-RAW-entwicklern hübsche knöpfe und einstellungsmöglichkeiten vorfinden, sondern vor allen dingen auch eine ganze menge übler probleme abgehandelt werden müssen (dead pixel eliminierung, korrektur von störmustern, die sich abweichung in den verstärkern bzw. AD-wandlern ergeben...), die man als endanwender auch schon in den bisherigen RAW-lösungen nie zu gesicht bekommen hat und von denen man auch lieber gar nichts wissen will.

wenn man schon aus irgendwelchen ganz grundsätzlichen erwägungen heraus von 'richtigem' RAW verlangt, dass auch dieser low level zugriff auf die ursprünglichen sensor daten erhalten bleiben sollte, geht's dabei meiner meinung nach gar nicht so sehr nur darum, genau das selbe, was die kamera ohnehin vernünftig umzusetzten versteht, auf den rechner auszulagern, sondern vielmehr eingriffsmöglichkeiten offen zu halten, die nur an dieser stelle der verarbeitungskette vernünftig möglich sind (bspw. irgendwelchen rechnerischen objektivkorrekturen vorzunehmen, die man mit glas auch mit größtem aufwand und hohen kosten oft nicht umsetzten könnte). in dem bereich eröffnen sich zusehends möglichkeiten, die mit konventionellen zugangsweisen und verarbeitungsketten einfach nicht umsetzbar sind (siehe z.b.: , ). es ist zwar unbedingt notwendig, dass die sensel daten dazu unverfäscht gespeichter und nachträglich zugänglich gemacht werden -- z.b. wäre es ja auch denkbar, dass man entsprechende sensordaten-aufbereitungs-kernels mit benutzerspezifischen modifikation auf die kamera hoch läd, so wie man das heute oft mit LUTs macht --, aber trotzdem sollte man auch diese ebene bzw. entsprechende eingriffsmöglichkeiten nicht völlig ausklammern, wenn es um RAW processing geht.



Antwort von Jott:

Fakt ist, dass so ziemlich die komplette gehobene Filmbranche ProRes lizensiert hat (Kamera- wie Softwarehersteller). JVC fehlt noch, die Liste ist gar nicht mal ganz aktuell:

https://support.apple.com/de-de/HT200321

Deswegen gilt der Codec auch als Industriestandard.

Was ich nicht weiß, und wahrscheinlich auch sonst niemand außerhalb des Donut-Raumschiffs in Cupertino, wie ProRes Raw da reinspielt. Müssten die alle dafür noch mal zahlen oder zumindest einen komplizierten Audit durchlaufen? Und falls ja, führt die BRAW-Ankündigung vielleicht zu einem Umdenken, und es kommt doch noch über Nacht die „Weltherrschaft“? Niemand weiß irgendwas.

Die Integration in Kameras scheint ja kein Problem zu sein, wenn DJI das in einer Drohne hinkriegt.

Wenn Blackmagic hier den träge gewordenen Apfeldampfer etwas anschubst, kann das nur gut sein.



Antwort von nic:

Jott hat geschrieben:
Wenn Blackmagic hier den träge gewordenen Apfeldampfer etwas anschubst, kann das nur gut sein. Ich finde so agil wie im letzten Jahr, hat sich der Dampfer schon sehr lange nicht mehr angefühlt. Zwar nicht immer hoch innovativ, aber durchaus bemüht.



Antwort von freezer:

7nic hat geschrieben:
Jott hat geschrieben:
Wenn Blackmagic hier den träge gewordenen Apfeldampfer etwas anschubst, kann das nur gut sein. Ich finde so agil wie im letzten Jahr, hat sich der Dampfer schon sehr lange nicht mehr angefühlt. Zwar nicht immer hoch innovativ, aber durchaus bemüht. Mag sein, aber mich als Kunden hat Apple mit den Preisen bei den neuen MacBook Pros verloren (stattdessen wurde es ein Lenovo Thinkpad P51 mit Xeon und ECC-Ram), die weiter gestiegenen Preise für die neuen iPhones machen mir auch nicht gerade Lust auf Apple (nach 11 Jahren iPhone).

Blackmagic macht vieles richtig und man sieht halt auch den Unterschied zwischen einem Unternehmen im Privateigentum und einem Unternehmen im Besitz von Börsenspekulanten.






Antwort von mash_gh4:

freezer hat geschrieben:
Blackmagic macht vieles richtig und man sieht halt auch den Unterschied zwischen einem Unternehmen im Privateigentum und einem Unternehmen im Besitz von Börsenspekulanten. zja -- da hab ich vermutlich als unerschütterlicher liebhaber eines im volkseigenen kollektiv entwickelten betriebssystems evtl. doch noch ein stufe höhere ansprüche an die damit einhergehende software qualität und innovation. :)



Antwort von WoWu:

das muss auch nicht unbedingt in proprietärer weise umgesetzt werden, weil ja ACES genau für diese form prozessierung bzw. farbeingriffe mittlerweile ganz wunderbare technische rahmenstandards,

Ist aber leider proprietär umgesetzt worden.
Attraktiver wäre es sicher gewesen, hätten sie ACES unterstützt.
Nur dann wäre die Zwangsbindung an ihr NLE nicht gegeben gewesen.

Insofern unterscheidet sich BM da nicht von Apple.
Beide wollen, dass man möglichst nur noch ihre Produkte nutzen kann.
Dass BM da vieles richtig macht -zumindest in der Preisgestaltung- ist wohl wahr.
Mal abwarten, ob das so bleibt, wenn man sich dann irgendwann im BM walled-garden befindet.



Antwort von mash_gh4:

WoWu hat geschrieben:
Ist aber leider proprietär umgesetzt worden.
Attraktiver wäre es sicher gewesen, hätten sie ACES unterstützt. wer weiß das? es kann ja gut sein, dass sie intern durchaus ACES und alle dafür bereits verfügbaren fertigen software-komponeneten nutzen. ähnliches vermute ich auch im hinblick auf die tatsächliche umsetzung der RAW aufbereitung, weil es ja nicht so viele werkzeuge bzw. software-lösungen gibt, mit denen man derart schnell all die unterstützten plattformen, prozessor befehlssatzerweiterungen und GPUs in jener weise abdecken kann, wie es die vorgestellte lösung der ankündigung nach kann.

aber natürlich bin ich ganz bei dir, wenn es darum geht, dass eine offene und standardkompatible umsetzung auch auf mich deutlich attraktiver wirken würde.



Antwort von Axel:

WoWu hat geschrieben:
Ist aber leider proprietär umgesetzt worden.
Attraktiver wäre es sicher gewesen, hätten sie ACES unterstützt.
Nur dann wäre die Zwangsbindung an ihr NLE nicht gegeben gewesen.

Insofern unterscheidet sich BM da nicht von Apple.
Beide wollen, dass man möglichst nur noch ihre Produkte nutzen kann. Wieso denn? Ich sehe genau das Gegenteil. Durch das Software Developer Kit (lizenzfrei) kann doch jeder Hersteller BRAW integrieren. Es steht auch bisher nirgends, dass Kamera- oder Fieldrecorder-Hersteller es nicht ebenfalls integrieren könnten. Hier wäre höchstens ein Vorsprung von BM zu vermuten. Und die Sidecar-Metadaten? Was ist daran verkehrt oder "proprietär"? Schließt das einen ACES-Workflow denn aus? Wohl eher im Gegenteil.

In FCP X bleiben bisher die Metadaten für ProRes Raw recht dürftig. Wysiwyg. Darüber hinaus wird PRR als reiner Aufnahmecodec beschrieben, währen Petty über BRAW sagt, es sei auch ein exzellenter Mastercodec. Die Vor- und Nachteile müsste man erstmal in der Praxis sehen.

Ich könnte mir vorstellen, dass eines dieser Raw-Formate sich etabliert als Alternative zu - natürlich - hochkomprimierten Consumercodecs, aber auch zu ProRes. Vergessen wir nicht, dass sich weder Datenraten noch Performanz dramatisch unterscheiden. Wenn ich praktisch Dasselbe in besserer Qualität haben kann, sehe ich wenig Gründe, darauf verzichten zu wollen.



Antwort von mash_gh4:

Axel hat geschrieben:
Wieso denn? Ich sehe genau das Gegenteil. Durch das Software Developer Kit (lizenzfrei) kann doch jeder Hersteller BRAW integrieren. nein -- das geht mit dem bisher veröffentlichten SDK definitiv nicht. die dort enthaltenen fertig kompilierten libraries kannst du nur auf mac os, windows und linux intel plattformen verwenden. das sind nicht umbedingt die basis, die kameras verwenden.
leider ist darüber hinaus überhupt nichts an technischer dokumenation od. code veröffentlicht wurden, dass irgendwelche realen perspektiven in diese richtung eröffenen würde od. auch nur ein bisschen mehr licht auf die tatsächliche techn. umsetzung bzw. deren praktische leistungsfähigkeit werfen würde.



Antwort von WoWu:

.... außerdem war ADOBE mit ihrem DNG Ansatz schon ein Stück weiter denn Metadaten waren da auch kein Problem.
Zusätzlich (zu der eigenen Kodierung) kann man dann noch das originäre RAW, also, sofern es die Kamera hergibt, die tatsächlichen Sensorwerte übertragen, was der BM Ansatz gar nicht vorsieht.
Und trotzdem ist es von vielen Herstellern nicht angenommen worden, geschweige denn zu einem Industriestandard mutiert.

Der BM Ansatz ist ein reines Trimmen auf NLE Performanz, von dem andere Hersteller kaum profitieren werden. Dazu kommt noch, dass solche Verfahren nirgend festgeschrieben werden (z.B. in der SMPTE).
Jede willkürliche Modifizierung seitens BM müsste also von den Herstellern gemonitort und bearbeitet werden. (das betrifft übrigens auch die freien Versionen).
Die Vergangenheit hat nun lange genug gezeigt, dass Hersteller das nicht machen.
Daher wäre ein neutrales, aber stabiles Verfahren, wie ACES, die deutlich bessere Entscheidung, speziell im Hinblick auf die Anwender gewesen.
Aber dann müssten sie natürlich, vor dem Hintergrund zunehmender Datenmengen, ihrem NLE Beine machen.
währen Petty über BRAW sagt, es sei auch ein exzellenter Mastercodec. Das ist sein Job, soetwas zu erzählen.
Wunschdenken der Werbefritzen.
Hat er nicht soetwas ähnliches auch über PRR gesagt ?



Antwort von -paleface-:

cantsin hat geschrieben:
Die für CinemaDNG verfügbaren RAW-Parameter Sharpness, Highlights, Shadows, Color Boost, Midtone Detail, Lift und Gain fallen weg. Dabei finde ich den Highlites Parameter neben WB eigentlich am wichtigsten...ohne den kann ich auch Prores aufnehmen.
Bin gespannt was beim

BRAW(L)

der Kamera RAW Codecs so rauskommt ;-)



Antwort von Starshine Pictures:

https://youtu.be/EpLo6i81_3I



Antwort von WoWu:

Na ja ... viel Geschwafel und so gut wie kein Inhalt.






Antwort von Jost:

WoWu hat geschrieben:
Aber dann müssten sie natürlich, vor dem Hintergrund zunehmender Datenmengen, ihrem NLE Beine machen. Genau da war ich mir von Anfang an unsicher. 8-Kern-CPUs kauft man für einen Spottpreis. Und wer mit BM-Produkten und/oder CDNG arbeitet, der hat bereits einen leistungsstarken PC.

Ich kann mir nur vorstellen, dass man den neuen Codec nutzt, um Pocket-4k-Kunden das Leben zu erleichtern. Unter diesem Aspekt betrachtet, tritt der Wunsch nach absoluter Codec-Qualität in den Hintergrund.

Und dass man den Codec so einfach in ein bestehendes System integrieren kann, davon bin ich auch nicht überzeugt.
BRAW-Beta gibt es nur für die 4,6 Pro, aber nicht für die normale 4,6.
Wenn es BM nicht schafft, BRAW in ihre aktuellen Produkte zu integrieren, warum sollen das andere besser können?



Antwort von WoWu:

Die Hauptprobleme sehe ich darin, für die Kameras Firmen zu finden, die so ein „halbes“ De-Mosaiking einfügen, um dann nicht sicher zu sein, ob der Kunde die andere Hälfte auch im NLE hat.
Aber wir sollten erst mal abwarten, was da überhaupt für ein Bild aus der Kamera raus kommt und ob es tatsächlich nur ein Luminanzsignal pro Pixel enthält, was dann ja ein echtes RAW wäre.
Jedenfalls wird das noch ein langer Weg bis Kameras umsteigen werden.
Wenn man bedenkt, dass viele Kameras auch erst ProRes implementiert hatten, kurz bevor Appel es eigentlich wieder durch PRR ersetzt hat.
Die müssen sich doch auch ziemlich verschaukelt vorkommen.
Und BM hat dagegen bestimmt kein besseres „Standing“ bei den Firmen, zumal sie sowohl in Kameras, als auch in NLEs auch noch Konkurrenten sind.
Da gibt es bestimmt keine „fliegenden Fahnen“ bei den Herstellern.
Schaun wir mal, was ende nächsten Jahres von den Versprechen so alles umgesetzt ist und warten wir erst mal das Format ab, was überhaupt dabei rauskommt.
Bisher gibt es ja nur Ankündigungen und viel Marketingspektakel.



Antwort von pillepalle:

Bei RAW kocht doch eh jeder Hersteller sein eigenes Süppchen und das wird sich auch nicht mit Blackmagic RAW ändern. Warum sollte Canon, Arri, Red, oder Sony plötzlich Blackmagic Raw in ihre Kameras integrieren? Jeder wird sich was einfallen lassen warum sein RAW Format das Beste überhaupt ist.

Die Idee von Blackmagic finde ich jedenfalls recht gut, sofern die wesentlichen Vorteile und Funktionalitäten von echten RAW Formaten erhalten bleiben. Bei irgendwann drohendem 8K hätte man mit dem alten Cinema DNG RAW selbst mit leistungsstarken Rechnern vermutlich wenig Spaß in der Postproduktion. Ein moderner und effizienter Codec macht das gesamte Blackmagic Universum attraktiver. Je mehr Nutzer darauf umsteigen, desto eher müssen sich auch andere Softwarehersteller überlegen, ob sie die Codec Option in ihre NLEs integrieren, damit ihnen keine Kunden abwandern. Mit der BMPCC4K haben sie jedenfalls schon mal gut vorgelegt. Und wenn sie auch noch neue und bessere größere Kameras raus bringen, haben sie recht gute Aussichten damit erfolgreich zu sein.

VG



Antwort von WoWu:

Das DNG Raw war nur deshalb so aufgeblasen, weil pro Pixel drei Werte übertragen wurden denn das, was da herauskam waren keine individuellen Luminanzwerte der Pixels.
Bleibt es aber bei nur einem Wert pro Pixel, sieht die Rechnung schon ganz anders aus.
Reduziert man die Menge der abgetasteten Pixels auf das, was das Objektiv effektiv an Auflösung hergibt und nicht eine aufgeblasene Pixelmatrix, die gar keine unterschiedlichen Inhalte führt, dann explodieren auch nicht die Filegrössen sondern bleiben im überschaubaren Bereich.
BM sagt ja, sie haben primär die superbilligen Speicherkarten im Fokus, also eher die wirtschaftliche Seite der Anwender, als die Qualitätsbelange und 12:1 spricht ja auch nicht eben dafür.
Solange also solche Ansätze bei Herstellern unterschiedlich sind, ergibt es für so manchen Hersteller überhaupt keinen Grund, umzustellen, es sei denn, er will auch das Amateur- und Semisegment bewerben.

Noch wissen wir aber gar nicht, was BM da eigentlich macht, aber die Beschreibung im o.a. Link, in Bezug auf die Übertragung der Abweichungen pro Bild und pro Bildgruppe, kommt mir irgendwie bekannt vor.
Damals hat man das nur Inter- und Intra- frame genannt.
Na, wir werden sehen, was rauskommt, wenn der Marketingnebel sich aufgelöst hat.
Aber das gerade BM genügend Druck ausüben kann, um die bekannten Marken, wie ARRI oder RED zu bewegen, mag ich noch nicht so richtig glauben.



Antwort von Jott:

WoWu hat geschrieben:

Wenn man bedenkt, dass viele Kameras auch erst ProRes implementiert hatten, kurz bevor Appel es eigentlich wieder durch PRR ersetzt hat.
Die müssen sich doch auch ziemlich verschaukelt vorkommen.
wowu mal wieder im Schwurbelmodus! :-)



Antwort von nic:

Die Alexa unterstützt ProRes seit 2010. DSMC2 seit 2016 (wenn ich mich recht erinnere). Red wird kein Interesse an PRR haben, bei Arri weiß ich es nicht, wäre aber durchaus praktisch im Vergleich zu Arriraw.

Und CDNG speichert bei BMD keine RGB-Daten. Das kannst du noch 100 mal behaupten, es stimmt nicht.



Antwort von WoWu:

Lies die CDNG Specs.
Wobei CDNG durchaus nicht das „Gelbe von Ei“ ist, was ich immer gesagt habe.
Bleibt also abzuwarten, inwieweit BMRAW nun eine Verbesserung darstellt.



Antwort von nic:

WoWu hat geschrieben:
Lies die CDNG Specs.
Wobei CDNG durchaus nicht das „Gelbe von Ei“ ist, was ich immer gesagt habe.
Bleibt also abzuwarten, inwieweit BMRAW nun eine Verbesserung darstellt. Die CDNG specs kenne ich. Und es ist durchaus dafür ausgelegt reine Sensordaten mit CFA-Informationen zu speichern.



Antwort von WoWu:

.....Ja, aber als Kamera-eigenes RAW Format. (So haben wir CDNG auch benutzt)
Das geschieht aber in einem embedded File und CDNG wirkt dann als reiner Container benutzt und hat mit dem, was Du unter CDNG RAW verstehst absolut nichts zu tun.
Das, was Du für ein RAW Format hältst ist eine Signalinterpretation, ein JPEG und das ist nun mal ein Videoformat und kein RAW.
Aber das kann man alles in den Specs nachlesen.
Aber glaub ruhig weiter an Dein RAW.






Antwort von nic:

WoWu hat geschrieben:
.....Ja, aber als Kamera-eigenes RAW Format. (So haben wir CDNG auch benutzt)
Das geschieht aber in einem embedded File und CDNG wirkt dann als reiner Container benutzt und hat mit dem, was Du unter CDNG RAW verstehst absolut nichts zu tun.
Das, was Du für ein RAW Format hältst ist eine Signalinterpretation, ein JPEG und das ist nun mal ein Videoformat und kein RAW.
Aber das kann man alles in den Specs nachlesen. Das was du für einen Frosch hältst, ist in Wirklichkeit ein Stück Brot. Was soll dieses despektierliche Geschreibe?

Ich weiß was CDNG ist. Da kannst du behaupten was du willst. Vor allem, wenn du vor ein paar Monaten noch behauptet hast, dass DNG gar keine Rawdaten speichern könnte...



Antwort von wolfgang:

Kindergartengeschrei. Kenne ich von meinem Einjährigen.

Als Alternativ zu ProRes RAW kommt das Blackmagic RAW wie gerufen. Denn dass man wie in meinem Fall zwischen den Stühlen als Kunde verhungert (die EVA1 gibt ihr hübsches 5.7K raw aus, aber - ätsch - leider gibt's nur den Atomos Rekorder zu ProRes Raw, für Windows ungeeignet) sollte es ja nicht sein. Da gehört mehr Wettbewerb rein und der ist jetzt hoffentlich da.

Wenn die neue Pocket endlich mal verfügbar ist, wird man ja sehen wie das funktioniert.



Antwort von WoWu:

@7nic
Das zeugt davon, dass Du nicht richtig gelesen hast.
Lies den Thread nochmal nach, dann wirst Du es sehen.



Antwort von nic:

WoWu hat geschrieben:
@7nic
Das zeugt davon, dass Du nicht richtig gelesen hast.
Lies den Thread nochmal nach, dann wirst Du es sehen. @WoWu
Das zeugt davon, dass du einfach nur hier bist, um den Anschein zu erwecken recht zu haben. Auf diese Diskussion habe ich keine Lust.

Fakt ist: CDNG bei BMD-Kameras speichert einen Wert pro Pixel und nicht drei. Egal was du behauptest.

Was BRAW macht, das weiß ich noch nicht, ich bin aber dabei mich zu informieren und möchte hier nicht unnötig spekulieren.



Antwort von WoWu:

Wie gut, dass Du Deine eigenen Fakten hast.
Ist ja populär geworden.

Lies die Specs ... da stehen die (ADOBE) Fakten drin.



Antwort von nic:

WoWu hat geschrieben:
Wie gut, dass Du Deine eigenen Fakten hast.
Ist ja populär geworden.

Lies die Specs ... da stehen die (ADOBE) Fakten drin. Ähnlich populär wie Verschwörungstheorien gegen mittelgroße amerikanische Unternehmen, die statt ein simples Luminanzsignal zu speichern, um das ganze dann Raw zu nennen lieber in der Kamera debayern, drei Kanäle pro Pixel übertragen, aber um mit der Datenrate hinzukommen und um nicht aufzufallen das erstmal als 3:1 komprimiertes 444 speichern, um es dann Raw zu nennen und im Bedarfsfall erneut zu komprimieren?

Hast du überhaupt schon mit BM-Kameras gearbeitet?



Antwort von WoWu:

Muss ich in einem Flugzeug fliegen, um Aerodynamik zu verstehen ?
Oder in einem Atomkraftwerk arbeiten, um Kernspaltung zu verstehen ?
Ich wette, viele, die bei einer BM Kamera wissen, wo der Aufnahmeknopf ist, wissen herzlich wenig über die Funktionsweise des betreffenden Codecs.
Wozu auch ?

Außerdem ist CDNG kein BM sondern ein ADOBE Produkt.
Und die ADOBE Specs gelten dafür.



Antwort von nic:

WoWu hat geschrieben:
Muss ich in einem Flugzeug fliegen, um Aerodynamik zu verstehen ?
Oder in einem Atomkraftwerk arbeiten, um Kernspaltung zu verstehen ?
Ich wette, viele, die bei einer BM Kamera wissen, wo der Aufnahmeknopf ist, wissen herzlich wenig über die Funktionsweise des betreffenden Codecs.
Wozu auch ?

Außerdem ist CDNG kein BM sondern ein ADOBE Produkt.
Und die ADOBE Specs gelten dafür. Nein. Aber du musst Aerodynamik verstehen, um Aerodynamik zu verstehen. Und es hilft auch, die eigene Theorie mit der Realität abzugleichen. Sowohl BMD, als auch DJI und Magic Lantern nutzen CDNG-Container um undebayerte Sensordaten (manchmal komprimiert, manchmal unkomprimiert) zu speichern.



Antwort von Jott:

7nic hat geschrieben:
die eigene Theorie mit der Realität abzugleichen Hätte schon viele verrückte Threads verhindert.



Antwort von WoWu:

@7nic

Nein. Aber du musst Aerodynamik verstehen, um Aerodynamik zu verstehen. Die Logik, die sich dahinter verbirgt, verstehst Du wahrscheinlich nur selbst.
Ich muss also, um bei Deinem Beispiel zu bleiben ... eine BM Kamera verstehen, um sie zu verstehen ... hm.... nun gut.

Irgendwie liest Du aber nicht wirklich, was ich schreibe.

Also nochmal:
Du kannst unterschiedliche Formate im DNG Container übertragen.
Entweder eine konvertierte Version, bei der DNG aus einem zugeführten Format die Bildinterpretation vornimmt und als TIF oder JPEG ausgibt

oder

ein zugeführtes Kamera-Raw ( as-it-is ) im Container einbetten, um es hinterher mit dem herstellerspezifischen „Entwickler“ zu bearbeiten.
Wenn es sich dabei um ein 1-wert/pixel-RAW Format handelt, bleibt das erhalten, hat dann aber nichts mit „DNG-RAW“ zu tun, weil DNG lediglich der Transportcontainer ist.
Metadaten der Kamera können ebenfalls eingefügt werden.

DNG stellt aber kein eigenes RAW Format da, bestenfalls sind die interpretierten Daten in der Konvertierung lossless.

So haben wir DNG jahrelang selbst betrieben. Der Umgang damit ist also weder neu, noch BM spezifisch.

Wie gesagt ... lies die Specs.



Antwort von nic:

WoWu hat geschrieben:
@7nic

Irgendwie liest Du nicht wirklich, was ich schreibe.

Du kannst unterschiedliche Formate im DNG Container übertragen.
Entweder eine konvertierte Version, bei der DNG aus einem zugeführten Format die Bildinterpretation vornimmt und als TIF oder JPEG ausgibt

oder

ein zugeführtes Kamera-Raw ( as-it-is ) im Container einbetten, um es hinterher mit dem herstellerspezifischen „Entwickler“ zu bearbeiten.
Wenn es sich dabei um ein 1-wert/pixel-RAW Format handelt, bleibt das erhalten, hat dann aber nichts mit „DNG-RAW“ zu tun, weil DNG lediglich der Transportcontainer ist.
Metadaten der Kamera können ebenfalls eingefügt werden.
So haben wir DNG jahrelang selbst betrieben. Der Umgang damit ist also weder neu, noch BM spezifisch.

Wie gesagt ... lies die Specs. Nichts anderes schreibe ich die ganze Zeit.



Antwort von WoWu:

Nein, Du schreibst, dass es ein DNG-Raw Format gibt.
Das gibt es nicht.

Das würde aber eben auch bedeuten, dass BM Kameras in keinem andern NLE (außer dem firmeneigenen) gelesen werden können, sofern sie noch zuvor mit der dazugehörigen BM Doftware entwickelt worden sind.
Komischerweise kommen die Files aber als TIFF oder JPEG aus dem DNG container raus, also als Videoformate.

.



Antwort von nic:

A DNG file always contains data for one main image, plus metadata, and optionally contains at least one JPEG preview. It normally has the extension "dng" or "DNG".

DNG conforms to TIFF/EP and is structured according to TIFF. DNG supports various formats of metadata, (including Exif metadata, XMP metadata, IPTC metadata), and specifies a set of mandated metadata.

DNG is both a raw image format and a format that supports "non-raw", or partly processed, images. The latter (non-raw) format is known as "Linear DNG". Linear DNG is still scene-referred and can still benefit from many of the operations typically performed by a raw converter, such as white balance, the application of a camera color profile, HDR compositing, etc. All images that can be supported as raw images can also be supported as Linear DNG. Images from the Foveon X3 sensor or similar, hence especially Sigma cameras, can only be supported as Linear DNG.

DNG can contain raw image data from sensors with various configurations of color filter array (CFA). These include: conventional Bayer filters, using three colors and rectangular pixels; four-color CFAs, for example the RGBE filter used in the Sony Cyber-shot DSC-F828; rectangular (non-square) pixels, for example as used in the Nikon D1X; and offset sensors (for example with octagonal pixels) such as Super CCD sensors of various types, as used in various Fujifilm cameras. (Or combinations of these if necessary). DNG specifies metadata describing these individual parameters; this is one significant extension to TIFF/EP.



Antwort von mash_gh4:

WoWu hat geschrieben:
Nein, Du schreibst, dass es ein DNG-Raw Format gibt. bitte wirf einfach einmal einen blick auf die entsprechende spezifikation:

https://www.adobe.com/content/dam/acom/ ... .4.0.0.pdf

dort ist das alles einigermaßen verständlich erklärt.

u.a. eben auch, dass sich DNG jeder menge älterer bildformate und kompressionstechniken bedient, die es davor schon gab, aber ganz spezifisch erweitert wurden, um ein format für den RAW datenaustauch zu schaffen -- eben: DNG!



Antwort von WoWu:

RAW DATENAUSTAUSCH


DNG can contain raw image data from sensors with various configurations of color filter array (CFA). Siehe obige Beschreibung

Das kann doch nicht so schwer zu verstehen sein. Seit 2011 arbeiten wir mit CDNG und übertragen echte RAW Daten der Kameta damit, ohne das DNG sie generier im ursprünglichen Kamersformat. Wobei DNG der Container ist.
Es gibt kein eigenständiges DNG-Raw.



Antwort von Sammy D:

Ganz allgemein, woran kann man erkennen, ob in einem DNG echtes RAW oder non-RAW transportiert wird?



Antwort von WoWu:

Am Entwicklerprogramm denn spätestens da müsste man Parameter finden, welcher De-Mosaikalgorithmus (von 9 derzeit gebräuchlichen) gewählt werden soll und in welche Teile des Algorithmus man eingreifen will.


Auch wenn Du das File sehen kannst, ohne das es vorher die Entwicklungssoftware durchlaufen hat ( auch wenn es noch so schäbig aussieht ) ist es ein Videosignal und kein Raw.



Antwort von Sammy D:

WoWu hat geschrieben:
Am Entwicklerprogramm denn spätestens da müsste man Parameter finden, welcher De-Mosaikalgorithmus (von 9 derzeit gebräuchlichen) gewählt werden soll und in welche Teile des Algorithmus man eingreifen will.


Auch wenn Du das File sehen kannst, ohne das es vorher die Entwicklungssoftware durchlaufen hat ( auch wenn es noch so schäbig aussieht ) ist es ein Videosignal und kein Raw.
- Sind in die modernen Betriebssysteme nicht schon "RAW-Converter" eingebaut, die die Vorschau ermoeglichen? Wenn neue Formate kommen, kann man sich diese z.B. auf dem Mac laden.

- DNGs von Leica-Kameras waeren, deiner These folgend, auch kein RAW, da ich diese ohne weiteres (ohne Entwicklerprogramm) anschauen kann.

- Oeffnet man DNGs von Blackmagic in RAWTherapee kann man z.B. verschiedene Demosaicing-Methode waehlen. Muesste doch mit non-RAW nicht funktionieren?

Ich folge einfach mal einer gewissen Logik und frage naiv. Von den technischen Implikationen habe ich wenig Ahnung.



Antwort von mash_gh4:

"Sammy D" hat geschrieben:
Ganz allgemein, woran kann man erkennen, ob in einem DNG echtes RAW oder non-RAW transportiert wird? wenn ich mir den WoWu so anhöre, scheint das im wesentlich ohnehin nur eine glaubensfrage zu sein.. ;)

annhänger WWschen geschmacksrichtung werden hier also zur bestätigung ihrer unerschütterlichen vorurteile vermutlich mediainfo heranziehen:
local@bonsai:~/Projects/mxnet$ mediainfo /tmp/A08_2016-01-27_2203_C0019_000270.dng General Complete name : /tmp/A08_2016-01-27_2203_C0019_000270.dng Format : TIFF File size : 10.5 MiB FileExtension_Invalid : tiff tif Image Width : 4 656 pixels Height : 2 624 pixels Bit depth : 12 bits aufgeklärtere zeitgenossen werden dagegen lieber auf exiftool schwören:
local@bonsai:~/Projects/mxnet$ exiftool /tmp/A08_2016-01-27_2203_C0019_000270.dng ExifTool Version Number : 11.10 File Name : A08_2016-01-27_2203_C0019_000270.dng Directory : /tmp File Size : 10 MB File Modification Date/Time : 2016:01:27 21:03:46+01:00 File Access Date/Time : 2018:09:17 18:24:09+02:00 File Inode Change Date/Time : 2018:09:17 18:23:51+02:00 File Permissions : rw-r--r-- File Type : DNG File Type Extension : dng MIME Type : image/x-adobe-dng Exif Byte Order : Little-endian (Intel, II) Subfile Type : Full-resolution Image Image Width : 4656 Image Height : 2624 Bits Per Sample : 12 Compression : JPEG Photometric Interpretation : Color Filter Array Orientation : Horizontal (normal) Samples Per Pixel : 1 Planar Configuration : Chunky Tile Width : 776 Tile Length : 2624 Tile Offsets : (Binary data 44 bytes, use -b option to extract) Tile Byte Counts : (Binary data 47 bytes, use -b option to extract) CFA Repeat Pattern Dim : 2 2 CFA Pattern 2 : 1 2 0 1 TIFF-EP Standard ID : 0 0 0 1 DNG Version : 1.2.0.0 Unique Camera Model : Blackmagic URSA Mini 4.6K Linearization Table : (Binary data 20799 bytes, use -b option to extract) Black Level Repeat Dim : 1 1 Black Level : 256 White Level : 53960 Default Crop Origin : 16 16 Default Crop Size : 4608 2592 Color Matrix 1 : 1.322 -0.595 0.0183 -0.313 1.2775 0.1865 0.1034 0.132 0.6928 Color Matrix 2 : 0.9527 -0.3 -0.0793 -0.3802 1.1972 0.1507 0.0203 0.1979 0.5441 Camera Calibration 1 : 1 0 0 0 1 0 0 0 1 Camera Calibration 2 : 1 0 0 0 1 0 0 0 1 As Shot Neutral : 0.7214 1 0.5739 Baseline Exposure : 3.09 Camera Serial Number : 4936BF254EE6487D8A3DE753FD2802A6 Calibration Illuminant 1 : Standard Light A Calibration Illuminant 2 : D65 Time Codes : 22:03:58.06 Frame Rate : 24 CFA Pattern : Image Size : 4656x2624 Megapixels : 12.2 letzterem kann ganz klar entnehmen, dass es sich hier tatsächlich um RAW handelt.

für ein bissen zusätzlicher verwirrung könnte natürlich auch das toll "raw2dng" von adobe sorgen, das aber in wahrheit keineswegs raw informationen in irgendwas profaneres umwandelt, sonder die entsprechenden daten praktisch nur unverändert bzw. um eine paar metainfornmationen angereichert von einem (meist noch properitärerem) RAW container in einen anderen (eiheitlicheren und offen spezifizierten) verschiebt.



Antwort von Sammy D:

mash_gh4 hat geschrieben:
...

letzterem kann ganz klar entnehmen, dass es sich hier tatsächlich um RAW handelt.

für ein bissen zusätzlicher verwirrung könnte natürlich auch das toll "raw2dng" von adobe sorgen, das aber in wahrheit keineswegs raw informationen in irgendwas profaneres umwandelt, sonder die entsprechenden daten parktisch nur unverändert von einem (meist noch properitärerem) RAW container in einen anderen (eiheitlicheren und offen spezifizierten) verschiebt. Wo genau erkennt man das? Sry, hab davon keine Ahnung. Ein paar Pointers waeren nett.



Antwort von mash_gh4:

"Sammy D" hat geschrieben:
Wo genau erkennt man das? Sry, hab davon keine Ahnung. Ein paar Pointers waeren nett. z.b. an den einträgen:
... Photometric Interpretation : Color Filter Array ... CFA Repeat Pattern Dim : 2 2 CFA Pattern 2 : 1 2 0 1 ... CFA Pattern : die angeben dass es sich dabei eben tatsächlich um rohe CFA sensel daten handelt, und darüber hinaus auch noch genau beschreiben, in welcher weise die verschiedenfarbigen sensel in der kamera bzw. in den RAW daten angeordnet sind...



Antwort von WoWu:

"Sammy D" hat geschrieben:
WoWu hat geschrieben:
Am Entwicklerprogramm denn spätestens da müsste man Parameter finden, welcher De-Mosaikalgorithmus (von 9 derzeit gebräuchlichen) gewählt werden soll und in welche Teile des Algorithmus man eingreifen will.


Auch wenn Du das File sehen kannst, ohne das es vorher die Entwicklungssoftware durchlaufen hat ( auch wenn es noch so schäbig aussieht ) ist es ein Videosignal und kein Raw.
- Sind in die modernen Betriebssysteme nicht schon "RAW-Converter" eingebaut, die die Vorschau ermoeglichen? Wenn neue Formate kommen, kann man sich diese z.B. auf dem Mac laden.

- DNGs von Leica-Kameras waeren, deiner These folgend, auch kein RAW, da ich diese ohne weiteres (ohne Entwicklerprogramm) anschauen kann.

- Oeffnet man DNGs von Blackmagic in RAWTherapee kann man z.B. verschiedene Demosaicing-Methode waehlen. Muesste doch mit non-RAW nicht funktionieren?

Ich folge einfach mal einer gewissen Logik und frage naiv. Von den technischen Implikationen habe ich wenig Ahnung.
Es ist in der Tat eine Glaubensfrage denn jeder Hersteller kann sein Signal RAW nennen und darauf hoffen, dass seine Kundschaft das dann „glaubt“.

Aber jeder Fotograf weiß - und definiert- sein RAW als ein einziges Luminanzsignal eines Pixels der Sensormatrix und wenn Media-Info das bereits lesen kann, ist es schon ein Videoformat, aus dem MI ausliest, was die Entwicklungssoftware in den Header geschrieben hat. Und da kann jede Firma das reinschreiben, was sie will denn MI ist kein Analysetool sondern lediglich die Sichtbarmachung der Header und Flags.

Was die Entwicklungssoftware betrifft, muss sie zunächst einmal wissen, welche Art der Mosaikfilter benutzt worden sind und lässt dann die Wahl der Schemata zu, nach denen verfahren werden soll.
Die gängigste Auswahl sind derzeit die
Kantenadaptive Demosaicing-Methoden
Gradientenbasierte Methoden
Komponentenkonsistente Demosaicing
Template Matching-basierte Methoden
Adpative Weighted-Edge-Methode
oder die
Lokale Kovarianz-basierte Methoden.
Es gibt dann noch ein paar weniger gebräuchliche Methoden, die u.A. Demosaicing durch gemeinsame Frequenz- und räumliche Analysen vornehmen, aber das sin Exoten.

So eine Auswahl stellen kommerzielle NLEs bzw. Entwicklungsprogramme für RAW zur verfügung. Danach richten sich auch die jeweils anfassbaren Parameter innerhalb des Demosaicing. Verfahren und Tools wird man entlang der Beschaffenheit des eigenen Contents auswählen, um Bildveränderungen sehr gezielt vornehmen zu können.
Oder, sofern es sich um ein Entwicklungsprogramm eines bestimmten Herstellers handelt, ist die Auswahl bereits eingeschränkt und relativ genau auf die spezifische Kamera ausgerichtet.

Fehlen solche Möglichkeiten gänzlich, ist die Wahrscheinlichkeit groß, dass es sich bereits um ein (sichtbares) Videoformat handelt, bei dem zwar auch in die Parameter eingegriffen werden kann, aber mit RAW hat das Ganze dann nichts mehr zu tun.
Also ... RAW kann jeder draufschreiben, das ist nicht definiert und wenn die Kunden es glauben wollen, dann ist das eben RAW.
Geht man aber von dem aus, was RAW ursprünglich war und woraus sich eben auch die zahlreichen Vorzüge ableiten, dann wird man den Großteil des Prozessings erst noch durchführen müssen.

Was RAWTherapee angeht, weiß ich nicht, ob sie nur den Header auslesen. Man müsste mal sehn, was die Methoden anschließend bewirken.
Außerdem ... wie oben beschrieben, lässt sich in DNG ein originalRAW embedden. Frage ist eben nur, ob es sich dabei um einen Wert/Pixel oder schon um 3 Werte handelt.
Das bedeutet aber eben nicht, dass das ein DNG-Raw ist sondern immer ein „Fremdraw“, das DNG dann nur noch transportiert.



Antwort von nic:

Schön, dass uns hier jemand belehrt, der offensichtlich seit einigen Jahren nicht mehr mit gängigen Rawformaten gearbeitet hat. Falls er es überhaupt mal getan hat und nicht nur Informationen aus Wikipedia oder anderen Quellen zusammenhangslos zusammenschreibt...



Antwort von WoWu:

Wenn Du ein paar Fakten statt Polemik hättest, wäre das deutlich hilfreicher.

Welche „neuen“ De-Mosaicing Schemata (außer den genannten) sind denn seit 2014 dazu gekommen ?
Ich lerne gern dazu.
Nenn doch mal Ross&Reiter oder reichte es nicht zu mehr als Polemik.
seit einigen Jahren nicht mehr mit gängigen Rawformaten gearbeitet hat Da lässt mal wieder jemand den „Praktiker“ raushängen.



Antwort von Frank Glencairn:

"Rick SSon" hat geschrieben:


Wahrscheinlich steht jetzt BRAW in Sachen Moire endlich nicht mehr ProRes nach. Na ja - der Grund, warum ProRes "cleaner" war was Moire und Rauschen betrifft ist der, daß feine Bildinformation durch die Komprimierung das erste war, was aus dem Fenster geworfen wurde.



Antwort von nic:

WoWu hat geschrieben:
Wenn Du ein paar Fakten statt Polemik hättest, wäre das deutlich hilfreicher.

Welche „neuen“ De-Mosaicing Schemata (außer den genannten) sind denn seit 2014 dazu gekommen ?
Ich lerne gern dazu.
Nenn doch mal Ross&Reiter oder reichte es nicht zu mehr als Polemik.
seit einigen Jahren nicht mehr mit gängigen Rawformaten gearbeitet hat Da lässt mal wieder jemand den „Praktiker“ raushängen. Das ist ehrliche Frustration, keine Polemik. Ich finde es ja gut, dass du immer wieder Quellen zusammenträgst und viele Diskussionen damit voranbringst. Aber manchmal ist es einfach nur anstrengend, vor allem wenn es sich dann im Kreise dreht.

Dass man zB den demosaicing-Algorithmus auswählen muss, ist bei den gängigen Rawformaten schon längst nicht mehr notwendig. Das erledigen die NLEs und/oder die Hersteller-SDKs für dich, für den Anwender ändern sich nur die möglichen Funktionen (Raw-Einstellungen) und die Renderzeit, bzw. die Echtzeitfähigkeit, je nach Ausgangsmaterial. Ob du jetzt mit Redraw, CDNG, PRR oder Arriraw arbeitest, mit dem debayering an sich hast du gar nichts zu tun. Das ist also keinerlei Kriterium um zu erkennen, ob du mit „echtem Raw“ arbeitest oder nicht. Auch kenne ich keinen Hersteller, der darum einen Hehl machen würde, ob es sich nun um ein Rawformat oder einen guten Akquisitionscodec handelt. Apple hat mit PR einen guten 444/422-Codec an der Hand, den fast alle Kamerahersteller lizensiert haben, wieso sollten sie uns mit PRR betrügen? Wieso sollte BM mit CDNG betrügen? Panasonic bietet tolle 10bit 422 log Codecs - und kommunizieren das so. Und bietet zusätzlich Raw. Sony bietet auch tolle herkömmliche Codecs. Aber eben auch uncompressed Raw oder compressed als X-OCN. Was treibt dich um an jeder Ecke Betrug zu wittern? Raw hat gewisse Vorteile. Herkömmliche Akquisitionscodecs wiederum andere. Hinterlistig einen Codec als Rawformat auszugeben wäre einfach nur unsinnig.



Antwort von Jott:

wowu hatte sich im Verschwörungsthread selbst als Truther positioniert. Er geht in der Tat davon aus, dass wir alle belogen und betrogen werden. Muss man akzeptieren.



Antwort von dienstag_01:

7nic hat geschrieben:
WoWu hat geschrieben:
Wenn Du ein paar Fakten statt Polemik hättest, wäre das deutlich hilfreicher.

Welche „neuen“ De-Mosaicing Schemata (außer den genannten) sind denn seit 2014 dazu gekommen ?
Ich lerne gern dazu.
Nenn doch mal Ross&Reiter oder reichte es nicht zu mehr als Polemik.

Da lässt mal wieder jemand den „Praktiker“ raushängen. Das ist ehrliche Frustration, keine Polemik. Ich finde es ja gut, dass du immer wieder Quellen zusammenträgst und viele Diskussionen damit voranbringst. Aber manchmal ist es einfach nur anstrengend, vor allem wenn es sich dann im Kreise dreht.

Dass man zB den demosaicing-Algorithmus auswählen muss, ist bei den gängigen Rawformaten schon längst nicht mehr notwendig. Das erledigen die NLEs und/oder die Hersteller-SDKs für dich, für den Anwender ändern sich nur die möglichen Funktionen (Raw-Einstellungen) und die Renderzeit, bzw. die Echtzeitfähigkeit, je nach Ausgangsmaterial. Ob du jetzt mit Redraw, CDNG, PRR oder Arriraw arbeitest, mit dem debayering an sich hast du gar nichts zu tun. Das ist also keinerlei Kriterium um zu erkennen, ob du mit „echtem Raw“ arbeitest oder nicht. Auch kenne ich keinen Hersteller, der darum einen Hehl machen würde, ob es sich nun um ein Rawformat oder einen guten Akquisitionscodec handelt. Apple hat mit PR einen guten 444/422-Codec an der Hand, den fast alle Kamerahersteller lizensiert haben, wieso sollten sie uns mit PRR betrügen? Wieso sollte BM mit CDNG betrügen? Panasonic bietet tolle 10bit 422 log Codecs - und kommunizieren das so. Und bietet zusätzlich Raw. Sony bietet auch tolle herkömmliche Codecs. Aber eben auch uncompressed Raw oder compressed als X-OCN. Was treibt dich um an jeder Ecke Betrug zu wittern? Raw hat gewisse Vorteile. Herkömmliche Akquisitionscodecs wiederum andere. Hinterlistig einen Codec als Rawformat auszugeben wäre einfach nur unsinnig. Aber das BM einen Codec, der das Demosaicing *teilweise* (was immer das heisst) in-Camera erledigt, dann RAW nennt, lässt dich nicht an deinen eigenen Einschätzungen zweifeln?



Antwort von WoWu:

Ich habe ja auch nichts dagegen, wenn Anwender scheiss Codecs benutzen, dann sollen sie aber nicht die vom Hersteller selbsternannten RAWs mit dem Vergleichen, was als RAW in die Fotographie eingegangen ist.
Da schmückt sich so mancher Hersteller mit Federn, die ihm gar nicht zustehen.
Was ProRes angeht, können die Meinungen auch auseinander gehen.
Aber jedem steht eben nur die Qualität zu, die er in der Lage ist, zu erzeugen.

Was die (automatische) Auswahl der Demosaicing Schemata angeht, wäre ich nicht so sicher, wie Du, denn ein gutes Demosaicing ist vom Content abhängig und den Zielen, die man in der Produktion mit den Algorithmen erreichen will.
Ein „quick&dirty“ Eingeitsalgorithmus ist dasselbe, als wenn Du die Kamera permanent im Automatikmodus betreibst.
Und, ganz ehrlich gesprochen .... die meisten RAWs sind sowieso nur flache Videos. Die Anwender hinterfragen das nur genauso wenig, wie die Frage der spatiale Auflösung, die auch nur nach der Nummer auf dem Karton entschieden wird.
Spätestens, wenn Du dabei bist, premium Content zu machen, für den der Abnehmer hohe Lizenzkosten zahlen soll, fängst Du an, mal über solche Parameter nachzudenken.
Aber für den meisten Content, mal ne DVD oder ein Imagefilmchen, wenn nich sowieso für ne kurze Youtube-Nummer, hast Du Du Recht. Da reicht auch Fake-Raw.
Und was die Frage angeht, warum die Firmen einen betrügen sollten ?
Warum schreiben sie irgendwo 8K drauf, wenn nicht mal vernünftiges 4K dabei heraus kommt?
Die Antwort ist ganz einfach ... Marketing, weil es immer Kaufvolk gibt, die jeden Mist glauben weil sie nichts hinterfragen.
Aber das BM einen Codec, der das Demosaicing *teilweise* (was immer das heisst) in-Camera erledigt, dann RAW nennt, lässt dich nicht an deinen eigenen Einschätzungen zweifeln? Nein, ganz im Gegenteil.
Wenn man sich die Verzahnung in hochwertigen Schemata der De-mosaicing Verfahren mal ansieht, macht das umso weniger Sinn.
Kann natürlich sein, dass sie bilineare Interpolation machen, das ist einfach zu implementieren und erfordert so gut wie keine Verarbeitungszeit, erzeugt aber sichtbare Artefakte. Die könnte man dann auch gleich und komplett in der Kamera lassen. Denn deren Auslagerung lohnt sich wirklich nicht.
Mich irritieren auch die Aussagen in dem Interview, das Stefan verlinkt hat, die passen irgendwie gar nicht mit RAW zusammen.
Aber das ist alles Glaskugel ... mal sehn, was hinterher dabei herauskommt.



Antwort von nic:

dienstag_01 hat geschrieben:
7nic hat geschrieben:


Das ist ehrliche Frustration, keine Polemik. Ich finde es ja gut, dass du immer wieder Quellen zusammenträgst und viele Diskussionen damit voranbringst. Aber manchmal ist es einfach nur anstrengend, vor allem wenn es sich dann im Kreise dreht.

Dass man zB den demosaicing-Algorithmus auswählen muss, ist bei den gängigen Rawformaten schon längst nicht mehr notwendig. Das erledigen die NLEs und/oder die Hersteller-SDKs für dich, für den Anwender ändern sich nur die möglichen Funktionen (Raw-Einstellungen) und die Renderzeit, bzw. die Echtzeitfähigkeit, je nach Ausgangsmaterial. Ob du jetzt mit Redraw, CDNG, PRR oder Arriraw arbeitest, mit dem debayering an sich hast du gar nichts zu tun. Das ist also keinerlei Kriterium um zu erkennen, ob du mit „echtem Raw“ arbeitest oder nicht. Auch kenne ich keinen Hersteller, der darum einen Hehl machen würde, ob es sich nun um ein Rawformat oder einen guten Akquisitionscodec handelt. Apple hat mit PR einen guten 444/422-Codec an der Hand, den fast alle Kamerahersteller lizensiert haben, wieso sollten sie uns mit PRR betrügen? Wieso sollte BM mit CDNG betrügen? Panasonic bietet tolle 10bit 422 log Codecs - und kommunizieren das so. Und bietet zusätzlich Raw. Sony bietet auch tolle herkömmliche Codecs. Aber eben auch uncompressed Raw oder compressed als X-OCN. Was treibt dich um an jeder Ecke Betrug zu wittern? Raw hat gewisse Vorteile. Herkömmliche Akquisitionscodecs wiederum andere. Hinterlistig einen Codec als Rawformat auszugeben wäre einfach nur unsinnig. Aber das BM einen Codec, der das Demosaicing *teilweise* (was immer das heisst) in-Camera erledigt, dann RAW nennt, lässt dich nicht an deinen eigenen Einschätzungen zweifeln? Naja, BM gibt ja immerhin zu, dass zum Teil in der Kamera debayert wird. Die Frage für mich ist: speichern sie die Rohdaten und daneben Informationen zum schnelleren demosaicing in der Post oder verändern sie die Rohdaten selbst? Dass es sich um einen klassischen 444 oder 422 Codec handelt, bezweifle ich, kann es aber nicht ausschließen. Also: Natürlich interessiert mich was es mit BRAW auf sich hat. Und ich versuche momentan auch über diverse Kontakte ein paar ‚Insights‘ zu erhaschen. Aber bis ich zumindest halbwegs verlässliche Informationen habe, werde ich nicht öffentlich spekulieren.



Antwort von nic:

WoWu hat geschrieben:
Ich habe ja auch nichts dagegen, wenn Anwender scheiss Codecs benutzen, dann sollen sie aber nicht die vom Hersteller selbsternannten RAWs mit dem Vergleichen, was als RAW in die Fotographie eingegangen ist.
Da schmückt sich so mancher Hersteller mit Federn, die ihm gar nicht zustehen.
Was ProRes angeht, können die Meinungen auch auseinander gehen.
Aber jedem steht eben nur die Qualität zu, die er in der Lage ist, zu erzeugen.

Was die (automatische) Auswahl der Demosaicing Schemata angeht, wäre ich nicht so sicher, wie Du, denn ein gutes Demosaicing ist vom Content abhängig und den Zielen, die man in der Produktion mit den Algorithmen erreichen will.
Ein „quick&dirty“ Eingeitsalgorithmus ist dasselbe, als wenn Du die Kamera permanent im Automatikmodus betreibst.
Und, ganz ehrlich gesprochen .... die meisten RAWs sind sowieso nur flache Videos. Die Anwender hinterfragen das nur genauso wenig, wie die Frage der spatiale Auflösung, die auch nur nach der Nummer auf dem Karton entschieden wird.
Spätestens, wenn Du dabei bist, premium Content zu machen, für den der Abnehmer hohe Lizenzkosten zahlen soll, fängst Du an, mal über solche Parameter nachzudenken.
Aber für den meisten Content, mal ne DVD oder ein Imagefilmchen, wenn nich sowieso für ne kurze Youtube-Nummer, hast Du Du Recht. Da reicht auch Fake-Raw.
Und was die Frage angeht, warum die Firmen einen betrügen sollten ?
Warum schreiben sie irgendwo 8K drauf, wenn nicht mal vernünftiges 4K dabei heraus kommt?
Die Antwort ist ganz einfach ... Marketing, weil es immer Kaufvolk gibt, die jeden Mist glauben weil sie nichts hinterfragen.
Aber das BM einen Codec, der das Demosaicing *teilweise* (was immer das heisst) in-Camera erledigt, dann RAW nennt, lässt dich nicht an deinen eigenen Einschätzungen zweifeln? Nein, ganz im Gegenteil.
Wenn man sich die Verzahnung in hochwertigen Schemata der De-mosaicing Verfahren mal ansieht, macht das umso weniger Sinn.
Kann natürlich sein, dass sie bilineare Interpolation machen, das ist einfach zu implementieren und erfordert so gut wie keine Verarbeitungszeit, erzeugt aber sichtbare Artefakte. Die könnte man dann auch gleich und komplett in der Kamera lassen. Denn deren Auslagerung lohnt sich wirklich nicht.
Mich irritieren auch die Aussagen in dem Interview, das Stefan verlinkt hat, die passen irgendwie gar nicht mit RAW zusammen.
Aber das ist alles Glaskugel ... mal sehn, was hinterher dabei herauskommt. Bring‘ nur einen Beweis für deine Flache-Video-Hypothese und ich lass‘ dich für immer in Ruhe. Im Volksmund nennt man das log-Video, ist in der Regel in einem 10- oder 12-bit 422-Codec verpackt und wird genau als das vermarktet.



Antwort von cantsin:

In dem Slashcam-Videointerview entgleiten dem BM-Vertreter einmal die Worte - und er spricht von BRaw als Video ggü. CinemaDNG als Raw.

Frage mich schon, ob hier BM einfach 12bit Log als Raw vermarktet.



Antwort von WoWu:

Ich glaube auch nicht, dass es da vorab belastbare Informationen gibt.
Einfach abwarten und schaun, was kommt.
Wenn es ihnen gelingt, ein gutes RAW zu bauen .... umso besser denn RAW ist nach wie vor die Methode, wirklich intensiv in den Content einzugreifen.

@Cantsin
Auch die 12 Bit geben zu denken ... warum sollte ein Sensor mit der passenden Dynamik bei 12 Bit schluss machen.
Das war nur in den DNGs so der Fall, weil TIFF sich per definition auf 12 Bit beschränkt hat.
Aber auch andere Punkte der Beschreibung waren ziemlich komisch.

Nun ja, lasst uns abwarten.



Antwort von Frank Glencairn:

cantsin hat geschrieben:

Frage mich schon, ob hier BM einfach 12bit Log als Raw vermarktet. Ich teste BRAW jetzt schon ne ganze Weile, und hab natürlich auch jede Menge 1:1 Vergleiche (selbe Kamera/Licht/Motiv Optik etc.) mit CDNG gemacht.

Es ist quasi unmöglich einen Unterschied zwischen den beiden auszumachen, selbst bei extremen Pixel Peeping.

Auch in der Post verhält sich BRAW identisch.



Antwort von nic:

WoWu hat geschrieben:
@Cantsin
Auch die 12 Bit geben zu denken ... warum sollte ein Sensor mit der passenden Dynamik bei 12 Bit schluss machen.
Das war nur in den DNGs so der Fall, weil TIFF sich per definition auf 12 Bit beschränkt hat.
Aber auch andere Punkte der Beschreibung waren ziemlich komisch.

Nun ja, lasst uns abwarten. Weil du ein 16bit lineares Signal vom Sensor gut in 12 bit log (bzw. nicht-linear wie BMD es bei BRAW nennt) packen kannst, ohne wirklich wichtige Informationen zu verlieren, außer in den Highlights, die sowieso viel zu viele Werte haben? Dass sie von 16 bit lin vom ADC auf 12 bit non-lin in BRAW speichern und auf 16 bit lin im SDK gehen, hat BM schon bestätigt.



Antwort von WoWu:

Was mich auch irritiert hat war, dass er aus dem RAW Gesamtordner das eigentliche Videofile rausziehen konnte und das dann auch noch ein Bild ergab (zwar flat, aber Bild).
Sowas funktioniert mit RAW nicht.



Antwort von Frank Glencairn:

dienstag_01 hat geschrieben:

Aber das BM einen Codec, der das Demosaicing *teilweise* (was immer das heisst) in-Camera erledigt, dann RAW nennt, lässt dich nicht an deinen eigenen Einschätzungen zweifeln? Vereinfacht gesagt, Debayering ist ein 9stufiger Prozess, der sich gut in zwei generelle Schritte aufteilen lässt.

Schritt 1 Directional Buffer
A. Die Festlegung einer von vier möglichen Interpolationsrichtungen für Grün
B. Die Festlegung einer von jeweils zwei möglichen Interpolationsrichtungen für Rot und Blau
C. Die Festlegung der jeweils kürzesten Interpolationsrichtung

Schritt 2 Interpolation
Die tatsächliche Interpolation für alle 3 Farben

Wenn Schritt 1 in der Kamera erfolgt, und das Ergebnis (zusamen mit anderen Sensor- und Kamera-Informationen) in die Matadaten geschrieben wird, die dann von Resolve entgegengenommen und weiterverarbeitet werden, reden wir immer noch von tatsächlich undebayertem raw, die Kamera hat die Weiterverarbeitung lediglich für Resolve vorbereitet.

Der Vorteil von raw, gegenüber einem bereits deabyerten Bild ist ja die geringe Datenmenge, warum sollte BM also diesen Vorteil ausgerechnet da verschenken, wo es erstens überhaupt keinen Sinn macht, und sie zweitens versuchen eine geringere Datenrate zu erreichen?



Antwort von Jott:

Laut Blackmagic-Website erledigen sie auch Denoising und Schärfung bereits in der Kamera:

"Die RAW-Verarbeitung wurde teilweise aus der Software in die Kamera verlagert, wo sie beschleunigt werden kann. Unter Verwendung von Bildentrauschung, Sensorprofilerstellung und neuen Algorithmen für die Kantenwiederherstellung werden hochwertige filmische Bilder mit sagenhafter Tiefe, gestochenem Detail und großartiger Konturierung produziert."

Puristen mögen deshalb durch die Decke gehen, aber unter praktischen Aspekten ist das ein recht sinnvoller Ansatz, finde ich.



Antwort von Frank Glencairn:

Für Puristen gibt's ja noch DNG :-)

Ansonsten ist der Tenor, den BM da seit neuestem anschlägt natürlich schon interessant.

Im Prinzip läuft es auf folgendes raus:

"Okay, ihr seid mit den Möglichkeiten eines raw workflow genauso völlig überfordert wie eure schwachbrüstigen Rechner, die sich weit jenseits aller unserer Mindestanforderungen bewegen, deshalb nehmen wir euch jetzt am Händchen, und bauen ne Version, mit der jeder Schüler und sein billig Laptop zurecht kommt".

Und ja - so sehr ich BRAW auch begrüße (und nutzen werde) sehe ich diese dumbing-down auch etwas kritisch, wenn auch verständlich aus MB Sicht.



Antwort von dienstag_01:

Ehrlich gesagt, wäre das meine nächste Frage gewesen: wie schafft man Constant Quality, ohne das Nutzsignal zu *beschreiben*, also z.B. durch Denoising vom Rauschen zu trennen.
Ist aber nur ne Frage, soviel Ahnung hab ich jetzt auch nicht von der Materie.



Antwort von wolfgang:

"Frank Glencairn" hat geschrieben:
"Okay, ihr seid mit den Möglichkeiten eines raw workflow genauso völlig überfordert wie eure schwachbrüstigen Rechner, die sich weit jenseits aller unserer Mindestanforderungen bewegen, deshalb nehmen wir euch jetzt am Händchen, und bauen ne Version, mit der jeder Schüler und sein billig Laptop zurecht kommt". Und ich sehe das nicht mal als schlecht. Vielleicht entsprechen weder BMR noch PRR den Anforderungen mancher Puristen, das mag ja sein. Aber man möge den blöden Praktikern doch die Change geben mit diesem Schei.... glücklich zu werden. Ist deren gutes Recht, finde ich.



Antwort von Frank Glencairn:

Der Grund warum ich das teilweise kritisch sehe, ist daß die Latte halt für diejenigen, denen immer alles zu viel und zu schwer ist, tiefer gelegt wird, anstatt daß sie versuchen besser zu werden, ihre Fähigkeiten zu schulen, und irgendwann mal auf adequate Hardware aufzurüsten.

Das ist so wie im Kindergarten, wo es keine Herausforderungen und keinen Willen zum Sieg mehr gibt, sondern bereits einen Pokal fürs Mitmachen, auch wenn man völlig versagt hat. Das zieht sich dann durch die Schule weiter durch bist zum Studium, wo manche Studenten massive Schwierigkeiten mit - selbst einfacher - Mathematik und Rechtschreiben haben. Trash in - trash out.

Is vielleicht jetzt etwas überspitzt formuliert, aber ich denke permanent die Anforderungen für alles immer nur zu senken, führt auf lange Sicht halt in eine Sackgasse, weil es überhaupt keine Herausforderung und keinen Ansporn mehr gibt, sich irgendwo zu verbessern.

Wenn man das zu ende denkt, sind wir irgendwann mal wieder auf allen Ebenen bei einem MagicBullet angelangt - und das hatten wir doch seit ein paar Jahren eigentlich schon hinter uns gelassen.



Antwort von wolfgang:

Na wer ernsthaft arbeiten will, der wird irgendwann aufrüsten (müssen). Geht kaum anders.

Ansonst bin ich durchaus froh wenn das nicht unmittelbar passieren muss. Kostet ja auch immer Kohle.



Antwort von Roland Schulz:

Den Ansatz dieser Lösungen (Debayering in camera...) zur Umsetzung hatte ich ja schon bei PRR so vermutet und wurde da belächelt - machen wir uns nix vor - das „sind“ sicherlich produktive, neue Formate die Vorteile bringen ohne zu relevante Nachteile mitzubringen - „RAW“ ist das so aber alles NICHT mehr und man wird irgendwann differenzieren müssen in wie weit es sich überhaupt noch von anderen Codecs absetzt.

Ich hatte vor kurzem noch ebenfalls behauptet dass „in camera processing“ durchaus Vorteile bringen kann weil gerade dort ein schnelles, gutes und effektives Debayering, Denoising etc. auf nem daraufhin optimierten SoC u.U. „besser“ „in time“ durchgeführt werden kann.
Weiterhin werden Objektivdaten direkt verarbeitet die heute kaum ein RAW Prozessor in der Software überhaupt mitkriegt (fehlende Metadaten).

Man muss sich als Beispiel nurmal einige (Stand-)Bilder von aktuellen (Foto-)Kameras ansehen und dann gucken was die interne Engine gegen einen jahrelang weiterentwickelten „Standard“ wie z.B. ACR da draus macht.
In vielen Bereichen kann ACR da auch heute nicht gegen ein ebenfalls hochentwickeltes in camera processing punkten. 5F38379A-93A0-46E4-ADEF-224D3B03E674.jpeg Quelle: dpreview.com

Gerade den Punkt Debayering und besonders Noise Reduction sehe ich im Post heute noch als sehr komplex und schwierig.
Was Resolve Studio da bietet ist sicherlich schon potent (halbwegs effektiv und schnell), kann in den meisten Fällen aber auch keine Ergbnisse leisten die hochoptimierte SoCs liefern.

Ich denke diese „Hybridlösungen“ bieten Vorteile, nehmen aber auch ein Stück Potential denn eins ist klar, zumindest in der Theorie liefert ein „reines“ RAW Bild das denkbar meiste Potential.
Was man in der Praxis heute damit erreichen kann ist die zweite Seite.



Antwort von Roland Schulz:

"Frank Glencairn" hat geschrieben:
Der Grund warum ich das teilweise kritisch sehe, ist daß die Latte halt für diejenigen, denen immer alles zu viel und zu schwer ist, tiefer gelegt wird, anstatt daß sie versuchen besser zu werden, ihre Fähigkeiten zu schulen, und irgendwann mal auf adequate Hardware aufzurüsten.

Das ist so wie im Kindergarten, wo es keine Herausforderungen und keinen Willen zum Sieg mehr gibt, sondern bereits einen Pokal fürs Mitmachen, auch wenn man völlig versagt hat. Das zieht sich dann durch die Schule weiter durch bist zum Studium, wo manche Studenten massive Schwierigkeiten mit - selbst einfacher - Mathematik und Rechtschreiben haben. Trash in - trash out.

Is vielleicht jetzt etwas überspitzt formuliert, aber ich denke permanent die Anforderungen für alles immer nur zu senken, führt auf lange Sicht halt in eine Sackgasse, weil es überhaupt keine Herausforderung und keinen Ansporn mehr gibt, sich irgendwo zu verbessern.

Wenn man das zu ende denkt, sind wir irgendwann mal wieder auf allen Ebenen bei einem MagicBullet angelangt - und das hatten wir doch seit ein paar Jahren eigentlich schon hinter uns gelassen. Denke für viele selbstverständlich durch Beobachtungen im Umfeld aber trotzdem ein ganz wichtiger Punkt!!

Ich habe heute manchmal den Eindruck dass einige „Heranwachsende“ ohne Smartphone noch nichtmal mehr alleine geradeaus laufen können!!
Die Rechtschreibreform war auch schon ein Eingeständnis in die Volksverdummung! Andere verstehen heute nicht mal mehr wie rum sich ein drittes, gekoppeltes Zahnrad in einem Getriebe denn drehen könnte wo viele aus meiner Generation früher noch „echtes“ (!!) Legotechnik neben Fischertechnik rauf und runter zusammengebaut haben.
Ich habe im Bekanntenkreis Kinder deren Eltern sowas alles nicht mehr für notwendig erachten wenn man da mal „unterstützen“ will.

Ja wer zum Teufel soll da denn morgen noch nen neuen Porsche konstruieren ;-)?!


Ich glaube „wir“ haben hier ein noch anderes Problem nämlich dass die IT Industrie relevante Zweige, nämlich Rechenleistung in der Vergangenheit etwas vernachlässigt hat.
Die richtigen (Leistungs-)Sprünge blieben doch aus, Intel brauchte sich nicht zu überschlagen weil AMD doch fast am Boden war - das hat sich jetzt wieder etwas geändert. Unterstützende Hardwarelösungen waren zu teuer weil der Markt für sowas zu klein war.
Also muss man am Aufwand sparen wenn man trotzdem „Auflösung“ und damit Rechenaufwand weiter erhöht.



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
Der Grund warum ich das teilweise kritisch sehe, ist daß die Latte halt für diejenigen, denen immer alles zu viel und zu schwer ist, tiefer gelegt wird, anstatt daß sie versuchen besser zu werden, ihre Fähigkeiten zu schulen, und irgendwann mal auf adequate Hardware aufzurüsten. Was die adäquate Hardware betrifft: Der Performancesprung von BRAW ist mir äusserst willkommen. Für die Pocket 4K hatte ich eigentlich schon ein GPU-Upgrade eingeplant, das nochmal ca. die Hälfte des Kamerabodys gekostet hätte. Doch siehe da, das 4,6K-BRAW-Demomaterial läuft auf meinem fast vier Jahre alten Rechner prima.



Antwort von ffm:

Wobei der Hinweis auf die Jugend bei mindestens 20 Fehlern im Beitrag inklusive des zitierten ironisch wirkt. Oder ist es das alles nicht so wichtig in Zeiten, in denen manche "garnicht" schreiben...



Antwort von mash_gh4:

"Roland Schulz" hat geschrieben:
Gerade den Punkt Debayering und besonders Noise Reduction sehe ich im Post heute noch als sehr komplex und schwierig.
Was Resolve Studio da bietet ist sicherlich schon potent (halbwegs effektiv und schnell), kann in den meisten Fällen aber auch keine Ergbnisse leisten die hochoptimierte SoCs liefern. den punkt sehe ich genau gegenteilig. die diversen lösungen auf ASICs mögen zwar ihren zweck durchaus erfüllen bzw. verhältnismäßig einfache umsetzungen ausgesprochen effizient abwickeln, aber wo es tatsächlich um qualität, eingriffsmöglichkeiten und flexibilität geht, sind sie natürlich softwarelösungen auf leistungsstarken workstations signifikant unterlegen.

am deutlichsten sieht man das bei guten foto-RAW entwicklern (bspw. darktable), die einem in hinblick auf diese aufbereitung von rohen senseldaten bzw. jene aspekte, die man mit bereits debayerten bildinformationen nicht mehr in den griff bekommt, freiheiten und sinnvolle feine-tuning möglichkeiten an die hand geben, wie sie dir keine kamera ermöglichst.

was die effizienz angeht, sind natürlich ASICs kaum zu schlagen, aber es gibt zumindest ein paar ansätze, die diesbezüglich durchaus auch befiedigende bzw. hoch optimierte umsetzungen in anderer form ermöglichen. ich hab eh schon weiter oben in diesem zusammenhang wiedereinmal halide bzw. das vor kurzem neu hinzugekommene gradient-halide erwähnt. dabei handelt es sich um eine softwarelösung, mit der man die mathematische beschreibung entsprechender bildberarbeitungsprozesse und ungewöhnlich effizienten programmcode übersetzten kann. das beschränkt sich aber nicht nur auf die generierung von output, der diverse befehlsatzerweiterungen und optimierungen für vektor operationen in heutigen CPUs und grafikkarten möglichst gut ausschöpft, sondern man kann damit auch netzwerkbeschreibungen für FPGAs generieren. letzteres ist ja bekanntlich der ansatz, auf den intel und microsoft momentan große hoffnungen setzen, um längerfristig den gegenwärtig dominierenden grafikkartenherstellern wieder etwas entgegen zu stellen. die sache ist auch deswegen so spannend, weil hier die gegenwärtigen bemühungen im machine learning umfeld (siehe: TVM und NNVM) mit den aktuellen entwicklungen im computational photography immer mehr verzahnen. es gibt ja mittlerweile kaum mehr bereiche in der bildverarbeitung, wo in den letzten jahren mit diesen neuen zugängen nicht deutliche verbesserungen gegenüber den traditionellen ansätzen erzielt werden konnten. derartiges auch tatsächlich zeitnah nutzen zu können, setzt fast zwingend voraus, dass man sich von den starren vorgaben klassischer ASIC umsetzungen löst.
"Roland Schulz" hat geschrieben:
Ich denke diese „Hybridlösungen“ bieten Vorteile, nehmen aber auch ein Stück Potential denn eins ist klar, zumindest in der Theorie liefert ein „reines“ RAW Bild das denkbar meiste Potential. ja -- ich würde hybride ansätze auch nicht per se verteufeln wollen. eine derartige herangehensweise kann der praxis oft durchaus gerecht werden.

allerdings würde ich mir wünschen, dass es trotzdem dem anwender überlassen bleibt, hier möglichst frei bzw. in hinblick auf den gegebenen anwendungsfall zu wählen.

so geshen würde ich mir wohl am ehesten eine modulare lösung wünschen, wo man für jeden dieser ganz grundsätzlich unterschiedlichen bildaufbereitungsschritte selber entscheiden kann, ob man ihn auf der kamera od. im postprocessing abwickeln will bzw. welche software man für die jeweiligen schritte bevorzugt bzw. tatsächlich heranzieht.



Antwort von Axel:

Ein bisschen pauschal, mMn, die BRAW-Zielgruppe mit Millennials zu vergleichen, die ohne App für’s Über-die-Straße-gehen nicht mehr mobil wären. Wie viele Nutzer von “echtem”, weil undebayertem Raw, sehen denn jemals die Rohdaten? Eben, das Debayering und zahlreiche andere Entwicklungsschritte erledigt die jeweilige Software. Und was kameraseitige Rausch-Eliminierung betrifft, so ist das nicht so sehr ein Problem, Nutz- von Störsignalen zu unterscheiden, sondern wie viel Rauschen man noch als nutzbar akzeptiert. Bestimmt nimmt der hochwertigere BRAW noch genügend davon mit. Es könnte sein, dass BRAW *in der Praxis* vergleichbar mit tiefgefrorenem Blattspinat ist. Sogar absolute Puristen geben nämlich zu, dass nach dem Dünsten kein Unterschied feststellbar ist. Die andere Seite der Medaille sind Leute, die einen guten Kompromiss aus Prinzip ablehnen. Ob er gut ist wird sich wohl erweisen.



Antwort von WoWu:

Mit andern Worten, kein Mensch braucht RAW.

Also erst mal sehn, ob sich BM das auch sagt, und nur einfach RAW draufschreibt, weil die Meisten nach Ettiket arbeiten.

@Axel
schau Die mal genau die Vorteile von RAW (in seiner Gesamtheit) an und pick nicht nur das raus, was Otto Normalverbraucher braucht,
Da geb ich Dir Recht, die sind häufig schon mit LOG überfordert und setzen lieber Rauschbegrenzer ein, als mit einem von Natur aus möglichst sauberen Signal zu arbeiten.
Denen reicht natürlich auch die RAW Bezeichnung, egal was drin ist.

Es ist und bleibt eben immer alles eine Frage des Anspruchs.



Antwort von Jott:

Sagt einer, der gar nichts produziert. Es ist wie immer alles eine Frage der Realität.



Antwort von Roland Schulz:

Na ja, richtiges RAW scheinen wir hier und ggf. bei PRR aber tatsächlich auch nicht mehr zu haben.
Irgendwo scheinen sich „Formate“ bzw. „Codecs“ ein wenig anzunähern.
Wenn uns morgen jemand 600Mbps 12bit C4K HEVC o.ä. anbieten würde könnte man pauschal auch nicht mehr sagen dass es „schlechter“ als 4:1 10bit C4K „RAW“ wäre, oder doch?!

Einfach nochmal die RAW/JPEG Ergebnisse der a7R3 bzgl. Debayering (!) etc. ansehen,
und wir reden da über nen über Jahre gewachsenen RAW Decoder (Pixmantec RAW Shooter -> Adobe DNG Prozessversion 1 - 4, weniger „Echtzeitrelevanz“...) eines führenden Herstellers der in meinen Augen klar den kürzeren zieht!

Ich denke wirklich langsam das klassisches RAW in wenigen Jahren keine praktische Bedeutung mehr haben wird.



Antwort von iasi:

WoWu hat geschrieben:
Mit andern Worten, kein Mensch braucht RAW.

Also erst mal sehn, ob sich BM das auch sagt, und nur einfach RAW draufschreibt, weil die Meisten nach Ettiket arbeiten.
Es immer eine Frage der Definition.

Letztlich kommt es nicht auf die Bezeichnung an - ebensowenig auf die Zahl vor dem k.

Man kann mit BMD-Raw jedenfalls mehr in der Post anfangen, als mit manch einem anderen Codec.
Wer"s kompromislos will oder braucht, der geht eben zur nächsten Stufe - zu dem, was du als Raw definieren würdest.
Eben ganz prakmatisch.



Antwort von Axel:

WoWu hat geschrieben:
Da geb ich Dir Recht, die sind häufig schon mit LOG überfordert und setzen lieber Rauschbegrenzer ein, als mit einem von Natur aus möglichst sauberen Signal zu arbeiten. Es gibt diesen Mythos offenbar, dass man Raw ungestraft pushen kann, Stichwort Belichtung in der Post. In gewisser Hinsicht ließe es sich allerdings tatsächlich besser pushen, da komprimiertes Rauschen besonders schlimm ist - Beweis sind Millionen Lowlight-Youtube-Videos. Aber von dieser Sache mal abgesehen ist optimale Belichtung bei, sagen wir, 8-bit LOG und Raw gleich erstrebenswert, und daher unterscheidet sich das in dieser Hinsicht null.

Der Unterschied ist relativ, weil er sich letzten Endes an dem Ausmaß festmacht, in dem ich nachträglich Einfluss nehmen kann. Möglicherweise schränken diese neuen Raw-Formate dieses Ausmaß ein.

Es gibt noch einen anderen relativen Unterschied, der sich auf die Bildqualität aufgrund des Überflusses an Werten (im Vergleich zur Distribution) bezieht. Hier behaupten Apple und Blackmagic, dass ein großer Vorsprung gegenüber ProRes erreicht wurde, bei ähnlichen Dateigrößen. Also kein Anlass, betrübt den Kopf zu schütteln. Vielleicht bedeuten PRR und BRAW nicht so sehr, dass CDNG endgültig obsolet ist, als dass es neue Codecs mit guter (wenn auch nicht bester hypothetischer) Qualität gibt.

Und es zwingt einen schließlich keiner, damit zu arbeiten ...



Antwort von iasi:

Axel hat geschrieben:


Es gibt diesen Mythos offenbar, dass man Raw ungestraft pushen kann, Stichwort Belichtung in der Post. Das wird aber eben auch immer wieder falsch verstanden.

Raw belichtet man in der Regel ETTR - bei 8bit auf die bildwichtigen Elemente.
Klar kann man aus den Schatten auch bei Raw nicht ungestraft etwas hochziehen, aber in den Mitten ist der Spielraum eben nun einmal gegeben.
In der Post kann man also wirklich noch in aller Ruhe die Feinarbeit an der Belichtung machen und hat eben einen größeren Gestaltungsspielraum.
Das mögen Kameraleute oft nicht sehr, denn sie verlieren dadurch eben einen Teil der Kontrolle über das Bild.



Antwort von Frank Glencairn:

WoWu hat geschrieben:
Mit andern Worten, kein Mensch braucht RAW.
Also ich drehe jetzt seit 2012 fast ausschließlich raw, und möchte es jedenfalls nicht mehr missen - aber natürlich nicht jeder hat diesen Qualitätsanspruch, den meisten reicht halt irgendwas zwischen "gut genug" und "sieht man eh nicht". Mir nicht - warum sollte ich nicht in der besten Qualität aufnehmen, die meine Kamera hergibt?



Antwort von nic:

"Frank Glencairn" hat geschrieben:
WoWu hat geschrieben:
Mit andern Worten, kein Mensch braucht RAW.
Also ich drehe jetzt seit 2012 fast ausschließlich raw, und möchte es jedenfalls nicht mehr missen - aber natürlich nicht jeder hat diesen Qualitätsanspruch, den meisten reicht halt irgendwas zwischen "gut genug" und "sieht man eh nicht". Mir nicht - warum sollte ich nicht in der besten Qualität aufnehmen, die meine Kamera hergibt? Warum nutzt du BM-Kameras, wenn dir “gut genug” gar nicht ausreicht? Die UMs sind doch der Inbegriff für “gut genug”.



Antwort von Roland Schulz:

7nic hat geschrieben:
"Frank Glencairn" hat geschrieben:


Also ich drehe jetzt seit 2012 fast ausschließlich raw, und möchte es jedenfalls nicht mehr missen - aber natürlich nicht jeder hat diesen Qualitätsanspruch, den meisten reicht halt irgendwas zwischen "gut genug" und "sieht man eh nicht". Mir nicht - warum sollte ich nicht in der besten Qualität aufnehmen, die meine Kamera hergibt? Warum nutzt du BM-Kameras, wenn dir “gut genug” gar nicht ausreicht? Die UMs sind doch der Inbegriff für “gut genug”. Frank dreht die „guten“ Sachen mit Miet-REDs!!



Antwort von R S K:

DV_Chris hat geschrieben:
Wie zu erwarten springt Blackmagic NICHT auf den ProRes RAW Zug auf. Auch sehe ich keine Kameras, die ProRes RAW aufzeichnen würde. Tut mir persönlich für Atomos leid, aber da hat man wohl aufs falsche Pferd gesetzt. Unser Fachmann wieder… Hauptsache merkbefreites Apple-Bashing. Herrlich. 😄
"Keine Kameras, die ProRes RAW aufzeichnen". Jopp. Genauso top informiert wie eh und je.

Klar, Apple/AtomOS haben natürlich ohne aktiver Unterstützung der diversen Kamerahersteller einfach deren raw-Ports angezapft und geraten was das Tonemapping etc. sein könnte und dann ganz zuuuuuufällig das richtige getroffen um ein gutes Bild zu bekommen. Puh. Und die Hersteller selbst haben es natürlich nicht selbst in-camera implementiert weil sie es nicht wollen. Nicht weil sie es (noch) nicht aus lizenzrechtlichen Gründen dürfen, richtig? Von denen steht auch nicht einer in den Startlöchern es zu implementieren sobald das "Lizenzembargo" fällt, oder? Es ist auch logisch, dass AtomOS ihr Geschäft mit einem echten raw von dem minderwertigen nicht-raw Format eines Kameraherstellers mit vergleichbar winzigem Markanteil und einer einzigen Kamera (warum eigentlich nicht die Pocket 4K??) ganz doll bedroht sehen. Sie zittern regelrecht, da bin ich mir sicher.

Neues (pseudo) raw Format was bei Vorstellung nur von einem Hersteller aufgezeichnet und auch nur von einer NLE verarbeitet werden kann. Ich komm nicht drauf wieso mir das so bekannt vorkommt und warum das doch eigentlich ein totaler FULL FAIL ist… hmmmm…

Das beste ist natürlich wenn man sich die Threads zu ProRes raw nochmals anschaut, wie nahezu die gleichen Namen auftauchen die gar nicht oft genug die "Echtheit" und Qualität in Zweifel stellen konnten, aber hier plötzlich zum Thema die Füße ganz still halten… die Heuchelei ist ohrenbetäubend. So lange es nichts mit Apple zu tun hat, iiiiirgendwie in Konkurrenz steht, dann ist es damit automatisch das Nonplusultra und DIE ANDEREN sind die Fanboys. :-))))

Was ist eigentlich das Gegenteil? Brainlesshateboys? 🤔


Axel hat geschrieben:
Keine große Tragödie für Atomos. Brauchen nur noch BM Raw als FW-Update hinzufügen. Oder irre ich mich? Du irrst dich. Du scheinst auch nichts über die Vergangenheit beider Firmen zu kennen, oder? Denn dann wüsstest du wie lange du darauf warten kannst. Wenn BMD es ihnen überhaupt lizensieren würde, was ich doch sehr bezweifele, werden die es mit Sicherheit gar nicht erst wollen. Wozu überhaupt? Welchen Sinn sollte das machen und welchen Vorteil hätte AtomOS (oder BMD) davon? Es sollen doch alle in-camera machen, oder nicht? Wozu brauche ich dann ein Inferno etc.? Erst recht sobald AtomOSs Exklusivvertrag ausläuft wird BM raw nicht nur technisch schlechter dastehen wenn du mich fragst. Welcher andere Kamerahersteller wird deiner Meinung nach extra das Codec eines quasi-Konkurrenten implementieren bevor sie nicht einfach bei ihrem eigenen raw bleiben oder eben den höhenwertigen (und echten) eines nicht-Konkurrenten implementieren, von dem sie sowieso schon diverse andere Geschmacksrichtungen bereits unterstützen? Canon? Sony? Arri etwa? Und warum? Ich tippe einfach die Sensordaten über einen Port rauszuschicken (gar über HDMI?) und es tatsächlich AtomOS zu überlassen die weit einfachere Aufgabe ist, wenn auch (vermutlich) weniger profitabel, aber wer weiß… bin kein Kamera/Sensorhersteller.

Und warum meinst du hat BMD das ganze überhaupt entwickelt bzw. doch noch rausgebracht? Weil es besser ist als das was es schon gibt? Weil die Welt unbedingt noch einen weiteren proprietären Codec brauchte? Oder vielleicht… tja, warum wohl?


Axel hat geschrieben:
Jetzt muss, wie gesagt, nur noch Apple seinen Stolz runterschlucken und BM Raw im Oktober in FCP10.5 parat haben. Ähm, Stolz? Och bitte. Mal abgesehen davon, dass Apple nicht so ein Kindergarten spielt (oder kannst du ein anderes Beispiel nennen?) und es sehr wohl unterstützen würde, wenn sich tatsächlich eine nennenswerte Nachfrage ergibt, müssen die es SELBST doch gar nicht tun! Wenn von mir aus Nikon oder sonst wer BM raw implementiert, dann schreiben eben DIE das Plugin. Ist doch logisch. Oder von mir aus BMD selbst (worauf ich auf lange Sicht eher tippe). Oder musst du z.B. für RED etwa nicht erst selbst den Treiber VON RED runterladen um RED raw verarbeiten zu können? 😏

- RK



Antwort von Funless:

Jetzt beruhigen wir uns alle wieder und gucken ein bisschen YT Influenzer Video ...

https://youtu.be/ydDkfUpOgV8



Antwort von R S K:

Wenn schon, dann influenza.

- RK



Antwort von Funless:

"R S K" hat geschrieben:
Wenn schon, dann influenza.

- RK Ist aber kein Grippe Video.



Antwort von R S K:

Funless hat geschrieben:
Ist aber kein Grippe Video. Na dann… influencer.

😏

- RK



Antwort von cantsin:

Hier hat mal jemand mit Programmierkenntnissen ein reverse engineering von BRAW anhand des SDK vorgenommen:
What there is:

8x8 DCT (same as in jpeg-ext, prores, prores-raw and other codecs) - but in 12 bit precision
(with specific funny constants from one academic paper telling you how to do it super-fast)

The iDCT has separate shaders for full,half,quarter and eight of the resolution

The DCT compressed data is in a pseudo-YCbCr colour-space, so encoding a weighted RGB average, and differences towards R and B

Transfer curve that is partially linear and partially quadratic, with a threshold
Linearization LUT, with 32K points

There is a yet unknown feature that selects one of the 4 tables how to mix colors up (or that might be the quantization)

Decoding quality is either fast/rough or high-quality
Decoding to 4 buffer formats (RGBA, 32bit, 32bit planar, 16bit planar)
Decoding to 2 not yet understood formats with 1 and 4 elements (maybe yuv/rgb or rgb/raw)

Simple and straightforward processing (blacklevel, gain, linearization, demosaic, saturation, colorspace conversion)


What there is not:

Wavelets (dirac-pro, TICO/jpeg-xs)

Encoding (at least no API exists for inserting raw data and creating files)

No advanced de-mosaicing that would trace contours or do other funny stuff



Looking into a sample 4K6 file:

it is based on ISO MEDIA format (Quicktime MOV), had no trouble to parse it through by my MP4 library

it is clearly an i-frame file and it might be a constant bit-rate one I got, since the frame sizes were almost same

there is some acquisition metadata about lens, shutter, iso per frame, these take few 64byte chunks of each frame, in custom QT atom format (256 on my sample)

then goes the binary header, with information about the resolution and slicing the file

and the slice index and those unknown mixing flags per slice


The 4k6 file seems to be partitioned into 240 slices, that are in 8x30 matrix. 8 wide shall correspond to the camera capabilities seen earlier with the JPEG extended profile in the 3:1 and 4:1 codecs, yet there the slices spanned over the whole (or half) the height of the picture. Here they span just 88 pixels tall. More slices means more potential to get things decoded in parallel (either on cpu or gpu).

I have not found yet a way to decode the slice bitstream, to tell whether it is just a JPEG, or it has subsections that lead to even faster /progressive/ decoding when processed partially.


My opinion on some choices:

Use of ISO MEDIA is fine and getting a new extension is good to avoid people telling "hey, i cant open this MP4"
(which was and is a trouble with the nonstandard coding in the 3:1/4:1 formats)

Including the shady shader source code - this makes the library future-hardware proof. When you get a new GPU architecture, it will run optimally.
e.g. Canon in their SDK pre-compiled these functions for the current gpu architectures, which means it might not even run on something newer, or will run sub-optimally.

Instead of obfuscation, they just might use a compression/encryption and I would probably never find these shaders. Not on first sight.

The partial de-mosaic may just mean:
- take this RGGB raw data, create R, (Gr+Gb)/2, B, convert it to pseudoYUV444, encode with JPEG(444). And the little of Gb-Gr residue is encoded extra
- for fast decoding at 1/2 of resolution just decompress the JPEG and convert to final color space, no de-mosaic, look ma - what a speed!
- for high quality decoding, get the Gr/Gb difference back, compose the original RGGB bayer data and do a full resolution de-mosaic https://cml.news/g/cml-raw-log-hdr/topi ... s/25749037

Der letzte Punkt klingt nach einem cleveren Hack...



Antwort von mash_gh4:

diese ersten erkenntnise über die tatsächliche sind natürlich wirklich sehr interessant.
auf so einer basis kann man wesentlich vernünftiger über die tatsächlichen vorzüge und grenzen des formats diskutieren.
schade, dass es nicht von haus aus in einer solchen weise dokumentiert wurde. gibt ja offenbar wirklich nichts aufregendes daran, dass nicht auch in vielen anderen formaten und anwendungen ständig sehr ähnlich abgewickelt wird.



Antwort von Frank Glencairn:

Die tatsächlichen Vorzüge und Grenzen des Formats erkundet man am besten, indem man es ausprobiert.



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Die tatsächlichen Vorzüge und Grenzen des Formats erkundet man am besten, indem man es ausprobiert. da hast recht -- nur nennt sich das halt in jenen kreisen, die an entsprechenden technischen einsichten und fakten interessiert sind, gleich einmal: reverse engineering. ;)

das kann bei völlig ungenügender dokumentation durch den hersteller oft tatsächlich weit mehr bringen, als alles zu glauben, was einem diverse werbefritzen und technisch weniger bewanderte fanboys einzureden versuchen.



Antwort von Frank Glencairn:

Ich glaub nur, was ich in meinem Material sehe :-)



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Ich glaub nur, was ich in meinem Material sehe :-) naja -- mein alter hoch geschätzter logik-professor hat seinen studenten den sinn entsprechender bemühunge immer mit dem sehr einfachen beispielsatz: "wenn es regnet, ist die straße nass" zu veranschaulichen versucht, der ja bekanntlich leider auch den umkehrschluss nicht zulässt, dass es geregnet haben muss, wenn uns die straße nass erscheint...

aber natürlich macht's sinn, dass man einfach auch seinen augen traut bzw. die dinge auf ihre praktische tauglichkeit hin überprüft, nur erübigt sich dadurch noch lange nicht die sinnhaftigkeit, technische lösungen auch aus anderen blickwinkeln zu betrachten, sie zu verstehen/hinterfragen und auch in dieser hinsicht mit anderen lösungen zu vergleichen.



Antwort von Jott:

"Frank Glencairn" hat geschrieben:
Die tatsächlichen Vorzüge und Grenzen des Formats erkundet man am besten, indem man es ausprobiert. Das ist dann aber ein "Küchentischtest" (© wowu)! :-)



Antwort von WoWu:

@Cantsin,
danke für die Info.
JPEG XS lässt mal wieder grüßen.
Dann haben sie wohl den Apple-Aufschlag eingespart und die Lizenz gleich an den Urheber gezahlt.