Und genau wegen dieser Fragestellung ist es eben nicht offtopic. Roland hat ja recht, dass offenbar analoge und digitale ISO-Werte vorhanden sein können - die dann einmal ins Material eingeprägt werden oder eben nicht.
Das dürfte aber stark von der verwendeten Kamera abhängen. Bei der EVA1 etwa gibts analoge ISO Werte die dann eben eingeprägt sind. Egal ob CDNG oder PRR. Das hat Auswirkungen auf das Rauschverhalten - und sollte daher eben dem Anwender bekannt sein. Ist es aber bestenfalls teilweise, bei der EVA1 wurde deshalb empfohlen mit einer der beiden nativen ISOs oder nahe daran zu arbeiten. RAW ist das trotzdem, denn das Debayering findet ja in der App statt.
Nein, das nicht und richtig, es könnte überall individuell anders verfahren werden - Sinn macht das allerdings keinen.
Warum sind wir darauf gekommen?!
Die Frage war wenn ich nichts durcheinanderwerfe warum FCPX keinen RAW Entwicklungsdialog anbietet.
Die Antwort ist weil er nicht norwendig ist. Man kann alle Bearbeitungen des RAW Dialogs auch in folgenden Nodes/Prozessen durchführen ohne dass es etwas ändert.
Apple ist meistens „einfach“ und reduziert auf‘s Notwendigste - der RAW Dialog ist ganz nett, aber in Wirklichkeit redundant.
Frank Glencairn hat geschrieben: ↑So 15 Apr, 2018 22:10
Allerdings basiert diese ganze "Erkenntnis" nur auf deinen Behauptungen.
...na ja, zwei Referenzen hatte ich bereits angehängt, endlos viel wird man da auch nicht finden da das meist gut gehütete Interna sind, wobei auf dem Level eigentlich noch nichts Geheimes dabei ist.
Die Behauptung dass z.B. im Resolve RAW Dialog die WB, Gain etc. Anpassungen vor dem Debayering vorgenommen werden sollten ist aber ebenso unbelegt. Am Ende kommt auch da RGB raus und wird auf weitere Nodes gelegt.
wolfgang hat geschrieben: ↑So 15 Apr, 2018 15:38
Und genau wegen dieser Fragestellung ist es eben nicht offtopic. Roland hat ja recht, dass offenbar analoge und digitale ISO-Werte vorhanden sein können - die dann einmal ins Material eingeprägt werden oder eben nicht.
Das dürfte aber stark von der verwendeten Kamera abhängen. Bei der EVA1 etwa gibts analoge ISO Werte die dann eben eingeprägt sind. Egal ob CDNG oder PRR. Das hat Auswirkungen auf das Rauschverhalten - und sollte daher eben dem Anwender bekannt sein. Ist es aber bestenfalls teilweise, bei der EVA1 wurde deshalb empfohlen mit einer der beiden nativen ISOs oder nahe daran zu arbeiten. RAW ist das trotzdem, denn das Debayering findet ja in der App statt.
Das setzt aber eben voraus, dass ein Verfahren vorhanden ist.
Das, was von PRR als „Lut“ übergeben wurde ist wahrscheinlich kein LUT sondern eine Liste, die das CFA beschreibt, denn davon werden ja nun mittlerweile fast 10 unterschiedliche Typen eingesetzt und ohne die exakten Werte der monochromatischen Filter nicht bekannt sind, braucht man gar nicht erst mit dem De-Bayering anzufangen.
Danach geht es los ... welches De-Bayer Verfahren wird benutzt. Die Performanz der unterschiedlichen Verfahren wirkt sich ganz erheblich auf das Zielbild aus denn im De-Bayering entsteht die wesentliche Menge an Artefakten, überwiegend in der unterschiedlichen Phasenlage der einzelnen Pixels zueinander begründet. Die Frage ist also, wie stellt man die optimale spektrale und räumliche Korellation der Pixels zueinander her. Nichts, was man ohne die passenden Algorothmen in der PostPro nachbauen könnte. Es findet dazu eine Analyse der Frequenz und der räumlichen Bereiche statt.
Das De-Mosaicing führt trotzdem oft noch nicht zu perfekten Ergebnissen und Ein iterativer Nachverarbeitungsschritt der Farbkorrektur wird oft erreicht, um die Endresultatqualität durch Verstärkung der Spektralkorrelation noch zu verbessern.
Wahrscheinlich meinte der BMD Mensch das damit.
Nur das alles setzt eben das Vorhandensein der entsprechenden De-Mosaiking Algorithmen (mitsamt seiner Stellpatameter) voraus.
Wir haben damals mit 3 unterschiedlichen Algorithmen De-Mosaiced. Allerdings waren sie alle noch auf Bayer basierten CFAs. Das dürfte sich mit Zunahme der panchromatischen Filter und unterschiedlichen Geometrien der Farbkomponenten mittlerweile in den Mengen deutlich geändert haben.
Was den Rest der Metadaten (ISO, White.. etc.) angeht, ist das sowieso Schall und Rauch denn in Kameras, die direkt mit der Verstärkung auf den Sensorverstärker zugreifen ist das ISO und auch die WB sowieso eingebacken weil die Reglungen auf denselben Verstärker wirken.
Bei invarianten Kameras sind solche „on set“ Einstellungen meist hinterher ohnehin sehr verbesserungsbedürftig und „nice to have“ aber nicht wirklich Qualitätsentscheidemd.
Und sofern man im De-Mosaicing eine Objektivkorrektur vornehmen will, braucht man sowieso die exakten Tabellen des singulären Objektivs. Solange die De-Mosaicing App dafür keine Schnittstelle liefert, ist das eh nicht nutzbar.
Übrigens spielt das De-mosaicing gerade bei hoher Pixeldichte und Auflösung zur beeinflussung von Aliasing eine kritische Rolle, die man in der (herkömmlichen) Post überhaupt nicht mehr in den Griff bekommt.
Also, so wie ich das im Augenblick sehe, sofern es sich bei PRR tatsächlich um ein Luminanzsignal pro Pixel handelt, könnte die Übergabe der CFA Liste reichen, wenn nicht mehr als reines De-Mosaicing vorgenommen werden soll.
Das setzt aber zwingend eine App voraus, die ich in FCP auch noch nicht gefunden habe.
...wie kriegen das bloß Capture One, DxO, CameraRAW, SilkyPix, On1, Luminar und andere geregelt für jede erdenkliche Fotokamera mit pluralem Objektiv den idealen Debayeralgorithmus zu eruieren.
Das klingt nach einer nahezu unlösbaren Aufgabe ;-)!
Da ich aktuell noch etwas „sonyglaslos“ bin und zig Nikonoptiken passiv adaptiere wundere ich mich doch was da für wunderbare Ergebnisse bei rauskommen - in immerhin 6K Fotoauflösung...
Ein Hersteller entscheidet sich heute für einen Algorithmus - das war‘s.
Alle Korrekturen wie WB, Gamma, Vignette, CA, Entzerrung etc. (mit Ausnahme von blackshading, bad pixel remap...) werden nach dem Debayern angewendet.
Ein Hersteller, der das De-mosaicing in seiner Kamera macht, braucht auch nur ein Verfahren, weil er es immer nur mit einer Signalqualität zu tun hat und immer mit einer Sorte CFA.
Findet das De-Mosaicing aber in einer Postproduktion statt, hat man es mit unterschiedlichen Bedingungen zu tun.
Farbfilter-Arrays, die z.B. auf komplementären Primärfarben basieren, finden zunehmend Verwendung, ihrer hohen spektralen Empfindlichkeit wegen und ihrer größere Bandbreite gegenüber RGB-Filtern, was insbesondere in lichtschwachen Umgebungen von Interesse ist und / oder wenn die Bildrate eine niedrige Integrationsperiode erfordert.
Das sind nur zwei Varianten, auf die sich ein externes Verfahren einstellen muss und an denen beispielsweise DNG mangels vorhandener Metadaten der Hersteller weitestgehend versagt hat, weil es für die Konversion eine Interpretation vornehmen musste und mit den Ergebnissen nur all zu oft deutlich hinter den Herstellerverfahren zurückgeblieben ist.
Verfügt man aber über die nötigen Tools in der Post, muss die Zeit, die für die Demosaicing von Bildern benötigt wird nicht mehr niedriger sein als die Bildaufnahmezeit und man muss nicht mehr nach einem Kompromiss zwischen der Verarbeitungszeit und der Leistung suchen, die von den untersuchten Demosaicing-Schemata erreicht wird, wie es in den Kameras erforderlich ist.
Was das Ergebnis betrifft, habe ich oben schon beschrieben, -und das scheint der BMD Mann zu bestätigen- dass die Ergebnisse nach der Durchführung des De-Mosaicing Verfahrens noch nicht der erwarteten Qualität eines Endbildes entsprechen und die Farbkorrektur den letzten Schliff aufsetzen muss.
Das ist aber in Kameras nicht anders, man sieht das demosaicte Bild nur nicht, weil es nicht herausgeführt wird.
Wo man allerdings nicht drum herum kommt ist das Einwirken auf die oben beschriebene Korellation der einzelnen Pixels, weil ansonsten das Ergebis eines De-Mosaicing in Bezug auf Unschärfe Artefakte, Zippereffekte und Falschfarben ziemlich unerträglich aussehen kann.
Man kommt bei der Anwendung von De-Mosaicing Schemata in der Postproduktion nicht ohne Eingriff in die Parameter zu keinem befriedigenden Ergebnis.
Das ist ja alles nicht falsch, nur werden die ganzen von mir angeführten Foto RAW Comverter nicht mit pro zu verarbeitender Kamera verschiedenen Algorithmen arbeiten sondern jeweils auf ein gewähltes Verfahren setzen.
Bei den CFAs gibt‘s sicherlich nich Unterschiede, gerade Nikon hat mit der D5 offiziell bekanntgegeben dass man schwächere Filter einsetzt. Das muss dem Konverterhersteller entweder bekannt sein oder man macht über entsprechendes Know How Reverse Engineering und dabei sollte gerade Adobe Kenntnisse besitzen die auch auf den Videobereich anwendbar sind.
Über verschiedene Testaufnahmen mit Patchfeldern kriegt man schon ne hohe Genauigkeit raus. Das was darüberhinaus durch IR-/UV Licht „versaut“ ist ist ohnehin nicht auflösbar da keine Information über diese Lichtanteile mitgespeichert wird. Man weiß im Post nicht wie viel UV-/IR Anteil die Aufnahme beeinflusst hat. Das ist und bleibt eine unauflösbare Größe.
Da ist viel Spekulation enthalten, denn die Kamerahersteller geben eben diese Daten nicht öffentlich bekannt. Da Pana mit der EVA1 gemeinsam mit Atomos Pate bei PRR und der Aufzrichnung im Shogun Inferno waren, ist gerade diese Kombination intensiv diskutiert worden.
Nur kann die Kombination dieser Geräte eben auch CDNG, und das liefert interessante Zusatzinformationen. Fakt ist, dass man in Resolve bei *CDNG* einstellbare Metadaten hat. In FCP X gibt es diese Einstellmöglichkeit (zumindest oder nur ? bei PRR) offenbar nicht, aber es werden definitiv die Metadaten in die PRR Datei geschrieben (der Test von Motiongroup war hier mit PRR und Medinfo leicht nachvollziehbar).
Dass einige Dinge bei der EVA1 wie (analoge) ISO aber nicht nur in Metadaten geschrieben werden, sondern in PRR eingebrannt sind, wurde von Mitch Gross für die EVA1 auf Facebook bestätigt. Bei WB bin ich mir da nicht sicher - aber wenn man mit der nativen ISO oder nahe daran arbeitet und eine WB bei der EVA1 macht sind die praktischen Nachteile wohl begrenzt. Betrifft dann aber wie gesagt auch CDNG - weil das von der Hardware der Kamera her fixiert ist.
Dass bei den Scene Based Ansätzen wie beim Resolve Farbmanagement oder bei ACES ohnedies immer eine IDT genutz wird ist ja bekannt. Und auch bei der EVA1. Man findet im CDNG Material aus EVA1/Shogun Inferno eben v log und v Gamut in den Metadaten des Materials und Resolve liest die aus dem CDNG auch brav aus (wird also bei einer zukünftigen PRR Implementierung in Resolve nicht anders sein). Und damit werden keine LUTs genutzt wie WoWu meinte, sondern das Scene based Farbmanagement von Resolve - und wohl auch bei FCP X gibt es ja offenbar eine ACES Unterstützung?
Sollte PRR in Resolve bearbeitbar werden, dürfte dort ebenso eine Einstellmöglichkeit der Metadaten auftauchen. Nur weil das FCP X offenbar nicht explizit vorsieht heißt das eben nicht dass eine IDT nicht korrekt genutzt wird. Aber FCP X ist ja auch keine Gradingsoftware, und hoffen wir dass die PRR Unterstützung auch in Resolve kommt.
wolfgang hat geschrieben: ↑Mo 16 Apr, 2018 09:16Fakt ist, dass man in Resolve bei *CDNG* einstellbare Metadaten hat. In FCP X gibt es diese Einstellmöglichkeit (zumindest oder nur ? bei PRR) offenbar nicht, aber es werden definitiv die Metadaten in die PRR Datei geschrieben (der Test von Motiongroup war hier mit PRR und Medinfo leicht nachvollziehbar).
(...)
Nur weil das FCP X offenbar nicht explizit vorsieht heißt das eben nicht dass eine IDT nicht korrekt genutzt wird. Aber FCP X ist ja auch keine Gradingsoftware, und hoffen wir dass die PRR Unterstützung auch in Resolve kommt.
FCP wäre besser bei der oft verspotteten Farbtafel geblieben, hätte sie lieber noch ein wenig aufgebohrt. Was hier seit Dezember läuft, lässt selbst Fan-Urgestein wie mich (der sich aber schon lange mit Color, Color Finale und Resolve befasst hatte) die Haare raufen.
Ich stimme dir darum zu. Potenziell revolutionäres Codec-Konzept (die Zeit wird's zeigen), aber eine Software, die es gar nicht vernünftig nutzt.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Roland Schulz hat geschrieben: ↑Mo 16 Apr, 2018 11:56
[
Das ist aber völlig unerheblich!
Es geht darum wie aus RAW Daten RGB Daten gewonnen werden. Ob in der Kamera oder im Converter spielt keine Rolle.
Nein, das ist weder unerheblich noch spielt es keine Rolle, sonder das ist der Punkt über den wir hier reden.
Nochmal speziell für dich:
Es macht einen Unterschied, ob ich die erste Korrektur im Raw Tab vornehme, oder auf dem bereits debayerten RGB mit Farbrädern/Kurven etc.
Deshalb sind die RAW Tabs auch nicht einfach nur so zum Spaß da, und sie sind auch nicht überflüssig, egal wie oft du das behauptest.
Wenn du es nicht glaubst, probier es einfach aus.
wolfgang hat geschrieben: ↑Mo 16 Apr, 2018 11:59
Auch wenn die Performance mit PRR beeindruckend ist.
Naja, wie viel PIP, Burns Effekt x5 braucht man denn bei der täglichen Arbeit?
Vielleicht einmal in 30 Jahren, wenn man eine 80er Retro KnofHof Show simulieren will?
Im normalen raw Schnittbetrieb geht ja sowieso schon alles in Echtzeit oder schneller.
wolfgang hat geschrieben: ↑Mo 16 Apr, 2018 11:59
Aber weißt du dass genau das die Frage für mich löst, ob ich für des kommend 5.7K raw der EVA1 mir doch einen Mac anlachen soll?
Wozu nämlich wenn FCP X hier auch genug Schwächen hat? Auch wenn die Performance mit PRR beeindruckend ist.
Adobe hat ja bereits angeblich Interesse bekundet, BlackMagic zeigt sich wohlwollend kritisch. Es ist so, dass weder Atomos noch Apple diese Kuh zum Fliegen bringen, wenn keiner sonst mitmacht. Die "Unterstützung" von Canon, Pana und Sony ist ja völlig passiv. Den wenigsten (nämlich nur denen, die FCPX haben und ohne Chromatic oder Color Finale eine längere Sequenz aufwändig farbkorrigieren wollten mit 10.4) ist hier klar, welche Misere ich gerade anspreche. Ich fände es ehrlich gesagt nicht so schlimm, die o.e. Metadaten in FCP nicht angezeigt zu bekommen, wenn dafür alles liefe wie geölt mit PRR. Mit den FCP-Werkzeugen selbst würde sich wohl jeder hier irgendwie anfreunden können, sie sind nicht allzu exotisch. Was leider völlig misslungen ist - meiner sehr unbescheidenen Meinung nach, aber ich könnte es *im Detail* (der Teufel steckt im Detail) aufzeigen -, ist der Farbkorrektur-Workflow. Stell dir vor, du hast hundert Raw-Clips in einer Sequenz, und du musst sie alle graden. Da kriegst du in FCP 10.4 einen Schreikrampf. Das musst du dir nicht anlachen. Warte, ob und bis es von Resolve adoptiert wird.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Verwendet das Projekt und ihr könnt eure Maschinen 1:1 gegeneinander Vergleichen... alles andere ist nicht zielführend und auch sinnlos wie Frank selbst gerade erklärt....
Das Teil läuft seit Jahren ohne Probleme und ohne 1000 Core 18 Fach SLI GPU Konfiguration.. eure Leistungsparanoia wie damals schon beim alten NMP lassen wir besser unkommentiert..
Ja, was ich damit sagen wollte ist, daß CDNGs, die von vielen als sooooo Hardware hungrig und Ressourcen fressend angesehen werden, nicht mal eine 12 Jahre alte CPU, und eine 4 Jahre alte GPU auch nur halbwegs auslasten, um in Echtzeit oder schneller zu laufen.
Das einzige was tatsächlich stimmt ist, daß Einzelbildsequenzen etwas länger zum kopieren brauchen, als eine einzelne PRR Datei.
Von mir hast das nie gehört;)
Im übrigen hat die Slashcam Redaktion ihr First light mit Prores RAW gehabt und bestätigt das in diesem Monsterfred geschriebene eigentlich zu 100%
Danke dafür..
Ps zu deiner CPU.. das ist auch heute noch eine 1a CPU von der Leistung her..
Die bei Intel sind und waren absichtlich keine Zauberer.. homöopathische Dosen in Funktion und Leistung für ordentlich Geld ist das Credo.. und die Dummen waren die Kunden..erst AMD hat sie aktuell ein wenig aus dem Schlaf gerissen und wie Nett es funktionierte sonst wäre es die nächsten Äonen so weiter gegangen..
das ist auch mit ein Grund warum sich Apple die neue Rel so mancher HW Produkte auf die lange Bank geschoben hatte... selbst die die in der MacFraktion einen Hackintosh mit den neuesten Komponente gebastelt hatten wurden immer wieder aufs neue enttäuscht.. die Sprünge sind vernachlässigbar..
Frank Glencairn hat geschrieben: ↑Mo 16 Apr, 2018 16:04
Hatte gerade Zeit für nen kleinen Test
Blackmagic CDNG Material aus der Ursa Mini (von einer 4TB Festplatte im USB3 Dock), plus 4 x PIP mit Burns Effect in Resolve, und ne LUT oben drauf.
Läuft in Echtzeit (24p) GPU und CPU knapp zu 50% ausgelastet.
Und das auf ner uralt Win 7 Workstation mit einem i7 980 6 Kerner @ 3.33Hz (Gulftown - also eine antike CPU von 2006) und ner 4 Jahre alten GTX 980.
PRR unterscheidet sich also nicht wirklich, von CDNG, was die performance betrifft.
Ja die GPU Last wurde doch weniger als Problem gesehen (wo soll auch bei Einzelbildern der Dekodieraufwand liegen)? Eher geht es um so Dinge wie erforderlicher Speicherplatz, da benötigt halt CDNG in etwa das Doppelte von ProRes RAW. Und deshalb hätte ich gerne ProRes RAW auch in Resolve und unter Windows implementiert.
Gegen das Speicherplatz-Problem gibt's aber bei CDNG zumindest eine teilweise Abhilfe. Man nehme einfach slimraw und kann damit nochmals Speicherplatz sparen. Ist recht performat, das kleine Tool. http://www.slimraw.com/
Es wird eh kommen ... nur keine Hast.. der Codec muss selbst unter OS X ein systemcodec werden solange er nur proprietär unter fcpx verfügbar ist brauchtest Du dir keinen Kopf machen..
Zuletzt geändert von motiongroup am Mo 16 Apr, 2018 17:30, insgesamt 1-mal geändert.
wolfgang hat geschrieben: ↑Mo 16 Apr, 2018 16:59
Eher geht es um so Dinge wie erforderlicher Speicherplatz, da benötigt halt CDNG in etwa das Doppelte von ProRes RAW. Und deshalb hätte ich gerne ProRes RAW auch in Resolve und unter Windows implementiert.
Naja, komprimiertes PRR HQ hat ungefähr die selbe Datenrate, wie die komprimierten CDNGs aus den BM Kameras - da ist nicht wirklich viel um.
Und ganz ehrlich, 4TB kosten nur noch um die 100 Öcken, Speicherplatz war noch nie so billig und so schnell wie heute.
Digibeta Bänder haben das zigfache gekostet, von Film ganz zu schweigen - das ist wirklich Jammern auf höchstem Niveau.
Roland Schulz hat geschrieben: ↑Mo 16 Apr, 2018 11:56
[
Das ist aber völlig unerheblich!
Es geht darum wie aus RAW Daten RGB Daten gewonnen werden. Ob in der Kamera oder im Converter spielt keine Rolle.
Nein, das ist weder unerheblich noch spielt es keine Rolle, sonder das ist der Punkt über den wir hier reden.
Nochmal speziell für dich:
Es macht einen Unterschied, ob ich die erste Korrektur im Raw Tab vornehme, oder auf dem bereits debayerten RGB mit Farbrädern/Kurven etc.
Deshalb sind die RAW Tabs auch nicht einfach nur so zum Spaß da, und sie sind auch nicht überflüssig, egal wie oft du das behauptest.
Wenn du es nicht glaubst, probier es einfach aus.
wolfgang hat geschrieben: ↑Mo 16 Apr, 2018 11:59
Auch wenn die Performance mit PRR beeindruckend ist.
Naja, wie viel PIP, Burns Effekt x5 braucht man denn bei der täglichen Arbeit?
Vielleicht einmal in 30 Jahren, wenn man eine 80er Retro KnofHof Show simulieren will?
Im normalen raw Schnittbetrieb geht ja sowieso schon alles in Echtzeit oder schneller.
Ja, Frank hat wieder mal recht, Weissabgleich wird selbstverständlich besser auf *Graustufenbildern* (=RAW) gemacht, als mit RGB-Werten.
Spätestens seit 75 Jahren - Happy Birthday, LSD ;)
dienstag_01 hat geschrieben: ↑Mo 16 Apr, 2018 17:44
Ja, Frank hat wieder mal recht, Weissabgleich wird selbstverständlich besser auf *Graustufenbildern* (=RAW) gemacht, als mit RGB-Werten.
Spätestens seit 75 Jahren - Happy Birthday, LSD ;)
Blickst du wirklich immer noch nicht wie so eine Pipeline funktioniert?
Aber vielleicht solltes du mal bei BM anrufen, und den Entwicklern von Resolve sagen wie man sowas richtig macht, weil du ja offensichtlich viel mehr davon verstehst als die. Die sind dir sicher total dankbar, daß sie dann nicht mehr so viel Zeit mit der Entwicklung der RAW Tabs verschwenden müssen.
Weil der Frank gerade auf seine 1A CPU aufmerksam gemacht hat.. Cores sind nicht immer ausschlaggebend...
Es kommt immer auf das Gesamtbild an und die verwendete Umgebung in die ich mich begeben möchte..;) und noch viel wichtiger ist es im Preisvergleich der Komponenten zu sich selbst ehrlich zu sein..
Gehört aber eigentlich nicht hier her nur wird es immer wieder einmal unterschwellig eingestreut..
Diese ist NUR mit echtem Zugriff auf die RAW Daten möglich. So weit ich sehen kann ist dies jedoch weder mit Apples ProRes RAW noch mit Canons RAW Light möglich, da hier eben Canon und Apple bestimmen, auf welche Parameter man zugreifen kann. Auch sind Tricks wie der Golden Sample Modus von Kinefinity nur möglich, wenn man wirklich Zugriff auf die Daten hat. Wer hier gerne experimentiert, bzw. sowas in Software nachbauen will, kann dies z.B. einfach mit RAWpy bzw. LibRAW unter CDNG machen. Allerdings nicht mit Apple/Canon RAW in der jetzigen Implementierung.
Frank Glencairn hat geschrieben: ↑Mo 16 Apr, 2018 17:26
Naja, komprimiertes PRR HQ hat ungefähr die selbe Datenrate, wie die komprimierten CDNGs aus den BM Kameras - da ist nicht wirklich viel um.
Das gilt aber nur für BM Geräte, wo etwa 3:1 verfügbar ist. Das gilt aber schon nicht mehr für Atomos Rekorder, wo CDNG eben locker das Doppelte an Speicherplatz braucht wie PRR.
Und daher ist für diese Rekorder PRR durchaus attraktiv. Und aus dem gleichen Gründen ist es für BM eben weniger attraktiv (nicht nur wegen den persönlichen Animositäten zwischen den beiden Eigentümern).
Und die Preise für den erforderlichen Speicherplatz sind so nicht vergleichbar, den da reden wir von unterschiedlichen Geschwinfigkeits- und damit Preisklassen. Die SSD kostet halt noch immer deutlich mehr.
rudi hat geschrieben: ↑Mo 16 Apr, 2018 18:23
An dieser Stelle möchte ich auch noch was beitragen. Wir hatten ja vor kurzem einen Artikel zur Highlight Recovery von RAW-Daten auf slashCAM:
Diese ist NUR mit echtem Zugriff auf die RAW Daten möglich. So weit ich sehen kann ist dies jedoch weder mit Apples ProRes RAW noch mit Canons RAW Light möglich, da hier eben Canon und Apple bestimmen, auf welche Parameter man zugreifen kann. Auch sind Tricks wie der Golden Sample Modus von Kinefinity nur möglich, wenn man wirklich Zugriff auf die Daten hat. Wer hier gerne experimentiert, bzw. sowas in Software nachbauen will, kann dies z.B. einfach mit RAWpy bzw. LibRAW unter CDNG machen. Allerdings nicht mit Apple/Canon RAW in der jetzigen Implementierung.
Diese ist NUR mit echtem Zugriff auf die RAW Daten möglich. - Im speziellen Fall sicherlich (Ist ja ein RAW-Tool). Ganz allgemein gibt es diese Art der Bearbeitung aber schon seit Jahren mit RGB-Werten, nennt sich Channel Mixing oder -Blending. Gehört zu den eher fortgeschrittenen Techniken der Bildbearbeitung (Restauration) und kann in den Händen von Leuten mit Ahnung wahrscheinlich einiges mehr als so ein Automatismus ;)
wolfgang hat geschrieben: ↑Mo 16 Apr, 2018 18:38
Das gilt aber nur für BM Geräte, wo etwa 3:1 verfügbar ist. Das gilt aber schon nicht mehr für Atomos Rekorder, wo CDNG eben locker das Doppelte an Speicherplatz braucht wie PRR.
Und daher ist für diese Rekorder PRR durchaus attraktiv.
Und wohl der eigentliche Grund für die Entwicklung von PRR.
Nachdem aber nichts so schnell im Preis fällt wie Speichermedien stellt sich die Frage, wie viele sich in der Praxis von PRR angesprochen fühlen.
dienstag_01 hat geschrieben: ↑Mo 16 Apr, 2018 17:44
Ja, Frank hat wieder mal recht, Weissabgleich wird selbstverständlich besser auf *Graustufenbildern* (=RAW) gemacht, als mit RGB-Werten.
Spätestens seit 75 Jahren - Happy Birthday, LSD ;)
Blickst du wirklich immer noch nicht wie so eine Pipeline funktioniert?
Aber vielleicht solltes du mal bei BM anrufen, und den Entwicklern von Resolve sagen wie man sowas richtig macht, weil du ja offensichtlich viel mehr davon verstehst als die. Die sind dir sicher total dankbar, daß sie dann nicht mehr so viel Zeit mit der Entwicklung der RAW Tabs verschwenden müssen.
Oh, cool, Pipeline, klingt echt schocking jetzt ;)
Zum Ändern der Farbwerte braucht man Kenntnis des CFA, alles andere würde mich sehr, ich nenns mal WUNDERN.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
