Wieso nicht? Die Performance soll dem normalen ProRes entsprechen (noch mal, das ist der Witz an ProRes Raw, sonst wäre es ja witzlos!), müsste also sehr wohl gehen. Keine Ahnung, ob es schon einen Schnipsel Material irgendwo zum Downloaden gibt, dann könnte man's ja mal probieren, statt einfach was zu behaupten.
Jott hat geschrieben: ↑Di 10 Apr, 2018 18:32
Wieso nicht? Die Performance soll dem normalen ProRes entsprechen (noch mal, das ist der Witz an ProRes Raw, sonst wäre es ja witzlos!)
Das kann technisch einfach nicht sein, wenn da in Echtzeit debayert wird. (Es gibt ja auch keine Foto-Raw-Formate, die ebenso performant angezeigt werden wie JPEG.)
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
"Dank der für macOS optimierten Leistung können Cutter 4K ProRes RAW-Dateien in voller Qualität auf MacBook Pro- und iMac-Systemen in Echtzeit ohne Rendering abspielen." (Apple)
Da steht nicht iMac Pro. Wozu streiten - wen's interessiert, der wird's probieren. Sollte 5,6K zu viel sein für eine schwächere Maschine, dann halt nicht mehr realtime, aber der EVA-Wolfgang käme trotzdem an sein Material ran.
Zuletzt geändert von Jott am Di 10 Apr, 2018 18:45, insgesamt 1-mal geändert.
WoWu hat geschrieben: ↑Di 10 Apr, 2018 17:49
Du vergisst dabei, woran ADOBE eigentlich gescheitert ist, nämlich daran, dass ein echtes RAW Signal all die Informationen berücksichtigen muss, die der Kamerahersteller als sein Alleinstellungsmerkmal in die Sensorumgebung eingebracht hat.
warum sind sie daran gescheitert?
DNG ist in der durchaus in der lage, die nötigen daten, so wie sie direkt vom sensor kommen, vernünftig aufzuzeichnen. dass man sie dann auch reichtig auswertet, was in verschieden anspruchsvollen weisen umgesetzt werden kann, ist wieder ein ganz andere geschichte, aber bzgl. des eigentlich transports der der daten und einer klar geregelten übergabe der nötigen metadaten gibt's daran nicht viel auszusetzten.
WoWu hat geschrieben: ↑Di 10 Apr, 2018 17:49
Das beginnt damit, dass die Farbmaske in Farbgebung und Überlappung bei jedem Kameramuster unterschiedlich ist, dass auch im De-mosaicing diese speziellen Eigenschaften einfließen müssen.
Es ist naiv anzunehmen, dass Farbmasken identisch sind und nur aus den Grundfarben bestehen, nur weil RGB drauf steht.
das hat sehr wenig mit den kameras zu tun, sondern nur mit den verwendeten sensoren. im übergabeformat muss diesbezüglich auch keine information über die tatsächliche spektrale sensibilität der verschiedenfarbigen sensel enthalten sein. es reicht völlig aus, wenn man an hand der metadaten eine eindeutige beziehung zwischen dem bei der aufnahme tatsächlich genutzen sensor und externen daten bzgl. der spektalen sensibilität herstellen kann. entsprechende korrekturen bzw. sensorspezifische aufbereitungsprofile kann man dann bspw. mit [https://www.ludd.ltu.se/~torger/dcamprof.html]DCamProf[/url] od. ä. generieren.
WoWu hat geschrieben: ↑Di 10 Apr, 2018 17:49
Genau aus diesem Grund wurde ja ACES entwickelt, um den Herstellern diese Möglichkeit in einer eigenen IDT zu lassen, ohne sie Preis geben zu müssen.
Es ist ja nicht so, dass es keine Standardisierungsbemühungen gegeben hat.
Es hat nur keine Einigung gegeben.
naja -- es gibt sehr viele überschneidungen zw. gutem RAW prozessing und ACES, aber völlig vermischen od. als austauschbar betrachten, wie du es tust, sollte man es nicht.
ACES liegt doch eine stufe höher bzw. bezeht sich im wesentlich nur auf bereits debayertes materal. allerdings behandelt es licht und farben tatsächlich in mathematische modellen, die sehr nahe an dem dran sind, wie man es auch beim RAW processsing handhabt. der grund dafür liegt aber eher darin, dass sich diese modelle (scene referred linear light), die sich an physikalischen beschreibungen und gesetzmäßigkeiten orientieren, als deutlich zweckmäßiger für komplizierte farbbearbeitungsaufgaben bzw. deren exakte umsetzung erwiesen haben, als jene zugänge die sich vorwiegend an den wiedergabegeräten bzw. damit verbundenen konventionen der datenrepräsentation orientieren (display referred -- bspw. rec709). trotzdem behandelt ACES mehr die grundsätzlichen rahmenbedingungen eines befriedigenden postprozessing workflows, als dass es sich zu sehr um die details der RAW aufbereitung kümmern würde. wie man also zu vernünftigen ausgangsdaten kommt, die man in den ACES workflow einbringt, ist also grundsätzlich offen. es kann also im grunde, um eine ganz extreme ausformung heranzuziehen, durchaus auch völlig künstlich generierter content sein. ich würde aber realistischer weise aber eher dahingehend argumentieren, dass die einzige relevante anforderung im falle von ACES sich darauf beziehen dürfte, das man ausgangswerte zu verfügung hat, die eine möglichst eindeutige rückführung auf in die welt der physikalischen grundgesetze von farbe und licht erlauben. ob man dafür nun ungebayeres RAW od. irgendwelche möglichst unverfälschte LOG-Formate zur Aufzweichnung der ursprünglichen sensordaten verwendet, macht dabei keinen großen unterschied.
Jott hat geschrieben: ↑Di 10 Apr, 2018 18:40
Her mit einem Schnipsel.
"Dank der für macOS optimierten Leistung können Cutter 4K ProRes RAW-Dateien in voller Qualität auf MacBook Pro- und iMac-Systemen in Echtzeit ohne Rendering abspielen." (Apple)
Da steht nicht iMac Pro. Wozu streiten - wen's interessiert, der wird's probieren. Sollte 5,6K zu viel sein für eine schwächere Maschine, dann halt nicht mehr realtime, aber der EVA-Wolfgang käme trotzdem an sein Material ran.
...wir sollten abwarten welche GPU Apple hier für Prores RAW erwartet. Mein Macbook Pro mit 5100er Intel Grafik wird MIT SICHERHEIT nicht reichen.
Jott hat geschrieben: ↑Di 10 Apr, 2018 18:40
Her mit einem Schnipsel.
"Dank der für macOS optimierten Leistung können Cutter 4K ProRes RAW-Dateien in voller Qualität auf MacBook Pro- und iMac-Systemen in Echtzeit ohne Rendering abspielen." (Apple)
Ja, aber das bedeutet eben nicht, dass die Performance die gleiche wie die von debayertem ProRes ist. (Das wäre ja die simpelste Form eines falschen Syllogismus.)
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
Jott hat geschrieben: ↑Di 10 Apr, 2018 18:40
Her mit einem Schnipsel.
"Dank der für macOS optimierten Leistung können Cutter 4K ProRes RAW-Dateien in voller Qualität auf MacBook Pro- und iMac-Systemen in Echtzeit ohne Rendering abspielen." (Apple)
Ja, aber das bedeutet eben nicht, dass die Performance die gleiche wie die von debayertem ProRes ist. (Das wäre ja die simpelste Form eines falschen Syllogismus.)
Ggf. passiert das auch alles nur in 1/4 oder 1/8 der nativen Auflösung - wir werden sehen.
Roland Schulz hat geschrieben: ↑Di 10 Apr, 2018 18:13Die hat nen alter ebay billig-Mac aber nicht!
Der Vorschlag dreht sich doch nur darum, dass er an die ProRes Raws aus seinem Shogun ran kommt, sie de-bayern und in einem Format ausgeben kann, das er mag. Dazu braucht's High Sierra, die fcp x-Demo, aber keine Rennmaschine, die acht raw-Ströme gleichzeitig spielen kann. War ein Vorschlag, der nichts kostet. Sorry dafür! :-)
Du unter der Perspektive des reinen Wandels ist das ja ok. Nur ist die Frage ob das wirklich reichen kann.
Gerne mal her damit via WeTransfer, ein paar aussagelose Blümchen à la YouTuber-Testfilmchen reichen ja. Dann probier ich gerne mal auf dem älteren 15"-Macbook Pro, an dem ich gerade tippe, wie sich das verhält.
Jott hat geschrieben: ↑Di 10 Apr, 2018 19:14
Hat jemand einen Schnipsel? Das sind doch alles Dinge, die praktisch probiert werden müssen.
Red-Files liefen ja auch schon vor vielen Jahren nativ auf Macs, also auf aus heutiger Sicht völlig lahmen Kisten.
4K RED Raw läuft auf nem "alten" Mac?! Was wäre das für ein Rechner mit was für einer GPU wenn man mal fragen darf?!
4K REDRAW lief auf einem 2010er 3,33 GHz 6-Core Intel Xeon “Westmere” Prozessor mit
ATI Radeon HD 5870 1 GB mit 1/4 debayer in Echtzeit. Full debayer dauerte, wenn ich mich recht erinnere schon 4- oder 5fache Echtzeit.
7nic hat geschrieben: ↑Di 10 Apr, 2018 19:47
4K REDRAW lief auf einem 2010er 3,33 GHz 6-Core Intel Xeon “Westmere” Prozessor mit
ATI Radeon HD 5870 1 GB mit 1/4 debayer in Echtzeit. Full debayer dauerte, wenn ich mich recht erinnere schon 4- oder 5fache Echtzeit.
Das ist nämlich genau die unbekannte Variable - Apple sagt nur, dass die Performance von ProRes Raw auf iMacs und Macbook Pros gut sei und suggeriert damit einen Durchbruch bei der Raw-Performance, sagt aber nichts über die Debayer-Qualität beim Playback im NLE.
Ich kann natürlich auch CinemaDNG in Resolve auf 1/2- oder 1/4-Debayer-Qualität fürs Playback einstellen (und anschließend in voller Qualität rendern) und habe dann keine Probleme auf Mittelklasse-Hardware. Insofern ist die Frage, wieviel ProRes Raw dann tatsächlich ggü. bestehenden Lösungen bringt, außer der höheren Nutzerfreundlichkeit von Raw in einer .mov-Datei.
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
Ich als Edius Anbieter und Nutzer zucke immer etwas zusammen, wenn jemand von "Echtzeit" schreibt. In Edius definiert sich Echtzeit nämlich so:
- Projektauflösung entspricht einmal der Clipauflösung
- Volle Auflösung bei der Wiedergabe (also nix mit 1/2, 1/4, etc)
- Original Framerate (also ohne skipped Frames)
- Im Original Codec (also keine "optimierten" Medien oder ähnliches)
Und da trennt sich dann oft die Spreu vom Weizen.
Und ja, die Raw Wiedergabe in Edius ist nicht die Stärke des Programms.
cantsin hat geschrieben: ↑Di 10 Apr, 2018 19:56
Insofern ist die Frage, wieviel ProRes Raw dann tatsächlich ggü. bestehenden Lösungen bringt, außer der höheren Nutzerfreundlichkeit von Raw in einer .mov-Datei.
das hängt sehr stark vom verwendeten filesystem und der fähigkeit des verwendeten betriebssystems ab, unmengen von [relativ] kleinen dateien vernünftig zu handhaben -- schlagt sich also durchaus spürbar in der performance nieder.
die meisten systeme kommen mit zusammenhängenden streams jedenfalls deutlich besser klar. wobei es heute eher nicht mehr üblich ist, zwischenschichten einzubauen, um entsprechende nachteile bzw. fragmentierungstendezen zu minimieren, wie das z.b. noch beim flame und seinem StoneFS der fall war. prinzipiell sind derartige filesequenzen aber auch heute noch, obwohl die systeme mittlerweile, viel besser geworden sind, eine ziemlich suboptimale lösung.
7nic hat geschrieben: ↑Di 10 Apr, 2018 19:47
4K REDRAW lief auf einem 2010er 3,33 GHz 6-Core Intel Xeon “Westmere” Prozessor mit
ATI Radeon HD 5870 1 GB mit 1/4 debayer in Echtzeit. Full debayer dauerte, wenn ich mich recht erinnere schon 4- oder 5fache Echtzeit.
Das ist nämlich genau die unbekannte Variable - Apple sagt nur, dass die Performance von ProRes Raw auf iMacs und Macbook Pros gut sei und suggeriert damit einen Durchbruch bei der Raw-Performance, sagt aber nichts über die Debayer-Qualität beim Playback im NLE.
Ich kann natürlich auch CinemaDNG in Resolve auf 1/2- oder 1/4-Debayer-Qualität fürs Playback einstellen (und anschließend in voller Qualität rendern) und habe dann keine Probleme auf Mittelklasse-Hardware. Insofern ist die Frage, wieviel ProRes Raw dann tatsächlich ggü. bestehenden Lösungen bringt, außer der höheren Nutzerfreundlichkeit von Raw in einer .mov-Datei.
Würde 4:1 compressed cdng in Premiere und FCPX genau wie in Resolve laufen und wäre es in einer Datei zusammengefasst, dann wäre PRR in der Tat unnötig.
DV_Chris hat geschrieben: ↑Di 10 Apr, 2018 20:03
Cantsin, Danke für die Anmerkung.
Ich als Edius Anbieter und Nutzer zucke immer etwas zusammen, wenn jemand von "Echtzeit" schreibt. In Edius definiert sich Echtzeit nämlich so:
- Projektauflösung entspricht einmal der Clipauflösung
- Volle Auflösung bei der Wiedergabe (also nix mit 1/2, 1/4, etc)
- Original Framerate (also ohne skipped Frames)
- Im Original Codec (also keine "optimierten" Medien oder ähnliches)
Und da trennt sich dann oft die Spreu vom Weizen.
Und ja, die Raw Wiedergabe in Edius ist nicht die Stärke des Programms.
Wenn du mit 8K oder 6K-Rohmaterial arbeitest, ist dir 1/4 debayer für den Schnitt in Echtzeit völlig ausreichend.
Natürlich ist es ausreichend. Aber trotz all dem Buzz sollte man die Dinge benennen wie sie sind. Bin somit gespannt, wie sich die Files wirklich verhalten werden.
motiongroup hat geschrieben: ↑Di 10 Apr, 2018 22:12
auf einem mb Air11"2014 vier Spuren inkl BIP, KenBurns und Farbkorrektur ohne Aussetzer und ohne Vorberechnung.
Das ist natürlich 'ne Ansage... Sind das 4K-Raws?
"Wieso eigentlich überhaupt was drehen? Warum nicht jahrelang nur darüber philosophieren?" -stip
ja 4k 25p beide gleiches Motiv ne Lampe in der ein Geist sitzt..
extrem gut zu bearbeiten ohne leak egal ob bei Skalierung oder bei der Korrektur.
die vier Kerne sind am Anschlag.. also 2/2
werd mal übermorgen schauen wie sich das die 4970k mit der IGPU und der GTX 970 teilt..
fcpx macht noch sperranskis auf dem Test Hack vermutlich die NV Webtreiber.. bin aber eh am überlegen ob nicht ne zert. 580er rein soll... wobei ich habe mit Video aktuell nicht viel am Hut und für xcode brauch ich sie nicht.. mal schauen..
motiongroup hat geschrieben: ↑Di 10 Apr, 2018 22:12
auf einem mb Air11"2014 vier Spuren inkl BIP, KenBurns und Farbkorrektur ohne Aussetzer und ohne Vorberechnung.
Schau an. Das wäre wie von mir erwartet und von anderen als völlig unmöglich erachtet. Ist das die Footage von diesem Typen?
Zum Material selbst, das ist wirklich einfachst auf jeglichen schwachbrüstigen Macs zu verarbeiten auch der betagte mbp17“ aus 2011 nimmt das Problemlos... wobei, der nimmt auch proresHQ problemlos.
Der Codec selbst ist nur unter fcpx verwendbar, wobei ich nicht sagen könnte das es unter iMovie für den Rohschnitt nicht auch funktionieren sollte da es der selbe Unterbau ist..
QT und alle anderen Player und Tools verstehen es nicht.. ebenso wie Resolve 14... die 15 is noch Beta und somit tabu.. wobei das liest sich schon recht gut....
Interessant zu lesen in jedem Fall die Kommentare dazu das nicht jeder Glücklich ist mit der Integration von Fusion in RS. Raunzen gibts aber immer.... auch schon unter eXtreme7Pro von Cinegy.. Wurst ist lange her..
Ich vermute mal dass die aktuelle Rel. von fcpx ein wenig vorschnell rausgehauen wurde wegen der Partner .. es sind leider manche Features ;) noch nicht wirklich bereinigt und gehörten noch überarbeitet was aber in allen Häusern bei der Komplexität der Programme vorkommt.. mein Premiere Nachbar wollte sich gestern mit einem Braun Rasierer die Pulsadern öffnen..
motiongroup hat geschrieben: ↑Di 10 Apr, 2018 22:12
auf einem mb Air11"2014 vier Spuren inkl BIP, KenBurns und Farbkorrektur ohne Aussetzer und ohne Vorberechnung.
der QT Player spielt sie nicht ab ist kein Systemweiter Codec..
Also in 1/1 Auflösung mit voller Framezahl und ohne dass im Hintergrund etwas optimiert wird? Wie Du schreibst ist die CPU Auslastung am Anschlag. Was macht die GPU? Wo liegen die beiden Files? Single SSD oder Raid?
Zuletzt geändert von DV_Chris am Mi 11 Apr, 2018 07:59, insgesamt 1-mal geändert.
Ohne Frage eine beeindruckende Performance, von der Rechnerperformance aber auch WEEEEEEIIIIT weg von nem 4 Spur MB Air 2014 ;-)!!
Die Maschine kostet so immerhin knapp 16t€!
motiongroup hat geschrieben: ↑Di 10 Apr, 2018 22:12
auf einem mb Air11"2014 vier Spuren inkl BIP, KenBurns und Farbkorrektur ohne Aussetzer und ohne Vorberechnung.
der QT Player spielt sie nicht ab ist kein Systemweiter Codec..
Ohne Frage eine beeindruckende Performance, von der Rechnerperformance aber auch WEEEEEEIIIIT weg von nem 4 Spur MB Air 2014 ;-)!!
Die Maschine kostet so immerhin knapp 16t€!
Stimmt völlig. Die gezeigten Werte sind beeindruckend, leider auch der Preis.
motiongroup hat geschrieben: ↑Di 10 Apr, 2018 22:12
auf einem mb Air11"2014 vier Spuren inkl BIP, KenBurns und Farbkorrektur ohne Aussetzer und ohne Vorberechnung.
der QT Player spielt sie nicht ab ist kein Systemweiter Codec..
Da muss dann ja der etwa noch viel mehr können:
Apple MacBook Pro 15" Touch Bar, i7 2,8 GHz, 16 GB RAM, 256 GB SSD, space grau
Vielleicht sollten wir noch mal auf andere Tests warten - das kommt mir da nicht ganz koscher vor. Kann unmöglich glauben dass nen 2014er MBA auch nur eine UHD PRRAW Spur 1/1 in Echtzeit schafft.
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.
