nic hat geschrieben: ↑Mi 18 Sep, 2019 12:40genug Kontrolle in der Post, damit man es wie Raw behandeln kann
Was kann es denn was ich nicht auch mit jedem anderen Format auch kann? WB, ISO, Farbraum kann ich alle auch so ändern, auch wenn es nicht explizit auf irgendeinem Pop-up oder Slider steht. Wobei 100%ig korrektes Kamera/Sensor-spezifisches Tone Mapping via LUT z.B. geht wegen des demosaicing genau genommen gar nicht erst. Auch wenn
das niemals einer wird je erkennen können, aber wenn wir schon davon reden…
Übrigens wenn BMD irgendwann mit einer Revision ihres „image processing pipelines” kommen, wie z.B. RED letztens schon mit IPP2, dann hast du als
heutiger BRAW Nutzer rein gar nichts davon. Bei RED und PRraw wiederum bekommst du damit aber jedes mal auch für
altes Material die jeweils neue, verbesserte Farbbearbeitung an die Hand.
nic hat geschrieben: ↑Mi 18 Sep, 2019 12:40Für BM-User stellt sich eben nicht die Frage, ob BRaw oder PRRaw.
Wie genau? Wenn PRraw ihnen gar nicht erst zur Verfügung steht.
BMD wird aber über kurz oder lang PRraw nicht ignorieren können und werden ihren Stolz runterschlucken müssen. Genau wie sie umgekehrt FCP unterstützen werden. Wobei sie wohl auch den längeren, nativen Weg werden nehmen müssen (oder schon nehmen?), was auch die Verzögerung erklären könnte. Wobei es umgekehrt eben auch nicht einfacher ist wegen Apples Richtlinien.
nic hat geschrieben: ↑Mi 18 Sep, 2019 12:4012bit stellen für BRaw keine Beschränkung dar, da es momentan keine Sensoren, bzw. ADCs gibt, die 12bit log an seine Grenzen bringen würden.
Nur dass man die 4 bzw. 6bits auch für was anderes nutzen kann und ja,
im Moment. Aber auch da, keiner wird 12bit ProRes von 12bit BRAW jemals unterscheiden können, auch wenn es mit Sicherheit wieder welche behaupten werden, also so gesehen sowieso müßig. Der letztendlich einzig wirkliche Vorteil für 99% der User ist halt, je nach gewählter Geschmacksrichtung, potentiell niedrigere Datenrate/Größe.
Unterm Strich ist BRAW eine super Alternative, ganz klar. Super Performance, Qualität und Größe, ob „echt” oder nicht. Es ist eben nur schade, dass trotz dessen und, ja, vor allem auch PRraws Existenz, noch immer alle meinen ihre eigene Varianten bringen zu müssen, wo das einfach für niemandem einen Vorteil darstellt. Ausser vielleicht für den Hersteller um evtl. proprietäre Sensordaten und Einstellungen zu schützen, auf Kosten des Nutzers. Apple hat PRraw aber eben genau aus dem Grund entwickelt, um interessierte Kamerahersteller quasi die Arbeit abzunehmen und diesen endlosen, sinnbefreiten Codecwust ein Ende zu setzen. Und wenn man ehrlich ist gibt es keinen nachvollziehbaren, logischen Grund oder Vorteil für
andere Kamera OEMs, ausser BMD, BRAW zu nutzen. Erst recht nicht für die die sowieso schon die sonstigen ProRes Formate aufzeichnen. Oder kannst du dahingehend was nennen? Und „
Kompatibilität” zieht nicht, da Apple ganz klar signalisiert, dass es (zusammen mit dem Rest) überall kommen wird. Sogar unter Windows.
Übrigens ist mir auch noch eingefallen, dass Plugins auch immer ein potentielles
Sicherheitsrisiko darstellen. Auch wieder etwas was Apple um jeden Preis vermeiden will. Wie man z.B. ironischerweise bei Quicktime unter Windows gesehen hat, von so einem Quatsch wie Flash mal ganz abgesehen. Stabilität ist dann noch ein weiterer Faktor. Ein super Beispiel dafür ist wie z.B. Workflow Extensions (Frame.io, Shutterstock etc.) in FCP implementiert sind im Gegensatz zu anderen, die so gesehen das nächstbeste zu „Plugins” im klassischen Sinn sind. Aber eben nicht ganz, aus Stabilitätsgründen.
- RK