Infoseite // ACES Tutorial und Workflow in Sony Vegas Pro 13

Newsmeldung von slashCAM:


Schon seit Version 12 beherrscht Sonys Vegas Pro ACES via OpenColorIO, doch wie sieht der Workflow in der Praxis aus? Jacob Balazer scheint sich mit dieser Materie schon gut auszukennen und stellt nicht nur korrekte Konfigurationsfiles für Version 13 kostenlos zur Verfügung, sondern exerziert auch gleich einmal einen Beispiel-Workflow durch, in dem versucht drei Kameras anzupassen




Hier geht es zur Newsmeldung mit Link und Bildern auf den slashCAM Magazin-Seiten:
ACES Tutorial und Workflow in Sony Vegas Pro 13




Antwort von wolfgang:

Die dazu gehörige Diskussion ist bereits seit einiger Zeit hier gelaufen:
http://www.sonycreativesoftware.com/for ... eID=923626



Antwort von WoWu:

Das sieht aber so aus, also es bei ACES ein ähnliches Problem geben wird, wie ADOBE das wohl schon bei CinemaDNG hatte, dass nicht genügend Hersteller die exekten Werte ihrer Kameras rausrücken, bzw. es beschränkt bleibt auf einige kommerzielle Kameras und Übertragungsfunktionen und dadurch im Semi-Bereich einfach die korrekten IDTs fehlen und dann "nach Gusto" einfach "gebaut" werden.
ADOBE hat das dann, basierend auf den bestehenden Modellen, dann interpretiert, was ACES gar nicht erst macht.
ACES verlässt sich drauf, dass die IDTs korrekt vom Hersteller kommen und man dann damit auch entsprechend korrekte Ergebnisse erzielt.
Ist das nicht so ... und werden IDTs, -wie in diesem Fall- geschätzt, funktioniert es nur so gut, wie auch schon vorher -denn die Schätzung wird ja nicht besser.
Wie sinnvoll dann also so ein Workflow noch ist, sei dahin gestellt.
Es reduziert sich dann nämlich eigentlich nur noch auf die Archivierung umgemappter Daten -ggf. unterschiedlicher Kameras- in einem gemeinsamen Datenraum. Ob es das nun bringt.
Mit andern Worten, solange der Kamerahersteller diese Spezielle Kamera nicht für eine ACES Anwendung mit der korrekten IDS unterstützt, ist der Nutzen des Workflows begrenzt. (Es sei denn, man hat Anwendungen im VXF Bereich, die Arbeiten im linearen Raum voraussetzen. Dann muss man aber auch alle Filter haben, die in dem Raum arbeiten).



Antwort von Peppermintpost:

@Wolfgang

schön das du noch an uns glaubst, aber auch im VFX Bereich werden wir leder eher von Blog Beiträgen getrieben als das da echtes Wissen über Farben/Farbräume vorhanden ist. Ich selbst verstehe ACES auch immer noch zu wenig, weil jedes mal wenn ich mich mit dem Thema auseinandersetze stosse ich an so viele Limitierungen, das ACES für mich zzt leider so gar keinen Sinn ergibt. Kann aber auch meine eigene Unwissenheit sein, kann ich zzt noch nicht richtig einschätzen.



Antwort von WoWu:

Moin Peppermintpost.

Ich hate ACES schon für eine gute Sache weil (endlich einmal) ein Workflow standardisiert worden ist.
Aber ich glaube, dass es, wie schon CinemaDNG auch zu wenig Unterstützung durch die Hersteller findet und dann (im Semi-Bereich) genau wieder zu dem verkommt, was CinemaDNG heute ist. Eine Nische.
Das ganze Prinzip steht und fällt ja damit, das man über die IDTs alle Kamera- und Computersignale in ihren Werten korrekt zueinander in einem gemeinsamen linearen Raum zusammenführt. Die Arbeitsweise danach ist so ziemlich wie auch jetzt. Man manipuliert im Originalsignal -zu bestimmender Güte- im Verhältnis (über einen LUT zur Sichtung) und transformiert das Ganze in einen Zielfarbraum für das Endprodukt.

Nur, wenn die Eingangssignale nicht über ein IDT vom Hersteller eingespielt werden, sondern -nach Gusto- gemapped werden, dann wird das dem Ziel natürlich nicht gerecht und man hat eigentlich keinen Vorteil gegenüber manueller Arbeitsweise.
Denn in falsches Mapping ist in einem linearen Raum noch genauso falsch wie in einem nicht linearen.
Solange der Hersteller nicht verrät, wie er die Werte transportiert und wie er die Farbinterpretation vornimmt, ist das Alles nicht besser als das, was ADOBE da auch schätzt, nur dass man es in ACES selbst schätzen muss.
Vorteil gegenüber ADOBE ist allerdings, dass man in einem 16 Bit rum arbeiten kann, wo ADOBE bei 12 Bit aufhört. Aber die Anwendung dürfte sehr speziell sein.
Ich hab übrigens noch nicht rausbekommen, was der unter ACEScc versteht.
In den Academy Unterlagen findet sich drüber nichts.

Ich hoffe, das ist nun nicht schon wieder irgend ein Hersteller-Derivat. das würde die ganze Idee schon wieder konterkarieren.



Antwort von Peppermintpost:

hey Wolfgang, nur nochmal für mich zum Verstämdniss. Selbst wenn wir mal ausser acht lassen, das nicht alle Kamera Hersteller mitspielen. Wenn man aber verschiedene Kameras hat für die es ein ACES Profil gibt, was ist denn dann mit Banalitäten wie zum Beispiel unterschiedliches Glass, was ja schon einen Einfluss hat, oder noch viel krasser ein Weissabgleich. Das ist doch im ACES Profil nicht drin, damit bleibt doch ein Kamera Color Matching eine manuelle Angelegenheit, und damit geht doch der Sinn von ACES schon zu einem grossen Teil verlohren, oder nicht?



Antwort von WoWu:

Das ist völlig richtig. Die Lage im grösseren Farbraum ist völlig "floating".
Die Chancen sind sogar gross, dass man bei einer solchen Transformation weitere Fehler macht und natürlich addieren sich Rechenfehler auf das Signal.
Auch weiss nur der Hersteller, welche Farbinterpretation für sein Signal eigentlich die Richtige ist und die zieht er beim De-Bayern ja schon automatisch in die "Schuhsohle" der Gerätefarbmetrik, was dem ganzen Ansinnen von ACES und der Mischbarkeit mit VXF Daten schon widerspricht.
ACES funktioniert wirklich nur korrekt mit IDTs vom Hersteller.
Ansonsten hast Du genau das "Gewurschtel", das es heute schon gibt, nur dass die LUTs anders heissen.



Antwort von Peppermintpost:

Entschuldige Wolfgang das ich es so laienhaft ausdrücke, aber dann erscheint mit der eigendliche "Witz" bei ACES doch darin zu bestehen, das die Signale in 32bit foat bzw 16bit float verarbeitet werden. Denn selbst Linear ist ja nicht bindent bei ACES da ACEScc ja auch wieder ein Gama verbogenes Signal ist.

Das eine höhere Farbauflösung in der Nachbearbeitung von Vorteil ist wenn es um die Qualität geht, das ist doch jedem sowieso klar, und alle Systeme die sich mit dem Thema Finishing auseinander Setzen (von Nuke, Flame, Smoke, Resolve etc etc) bieten ja auch 16bit float oder sogar 32bit float Einstellungen an. Nur reine offline Systeme wie z.B. Avid tuen das nicht, macht an der Stelle ja auch wenig Sinn.

Mir erschliesst sich der Vorteil bei ACES einfach nicht. Die Idee ist gut, aber die Umsetzung halte ich für viel zu inkonsequent, womit bei mir das ganze System stirbt weil es genau das was es eigendlich tuen soll nicht tut.



Antwort von Frank Glencairn:

ACES macht in einem Bereich Sinn wo man z.B mit einer Alexa, einer Epic, Kodak Vision und einer Phantom gedreht hat. ACES bringt die Verschiedenen Materialien quasi auf einen Nenner.

Für Produktionen mit einem Kameratyp oder Semi/Hobby Anwendungen ist das fürn Arsch, weil Premiere, AE und Resolve sowieso schon durchgängig in 32bit arbeiten - da gewinnt man nix mit ACES.






Antwort von WoWu:

Peppermintpost

Ja und nein.
ACES ist eine gute Sache, weil endlich einmal der Workflow dokumentiert, damit standardisiert und damit austauschbar wird.
An jeder Stelle des Workflows können "externe" Bearbeitungen eingefügt werden und Files werden von überall zugreif- und bearbeitbar.
Es macht auch Sinn, wenn ich unterschiedliche Ziele bediene, weil ich solche Ziele im Workflow (auch parallel sehen kann)
Das geht heute auch schon, aber mit einwenig Transformationsaufwand.
Insofern macht ACES schon Sinn und es wäre wünschenswert, es durchzusetzen denn es ist zumindest kein Schritt rückwärts und in mancherlei Hinsicht ein Schritt vorwärts.
Nur muss man das Für und Wider richtig verstehen denn erst wenn man die Hersteller dazu zwingt, die (IDT) Vorarbeit beizutragen, kommt man auch in die Vorteile:
Beisiel: Die Kamera kann im linearen Raum Farben darstellen, die in der Schuhsohle nicht vorkommen. Wie die entstanden ist, muss man sich mal reinziehen, um das genauer bewerten zu können.
VXF kann aber Farben, die bereits heute verfügbare Systeme reproduzieren können ... zukünftige sowieso.
Wenn mein IDT nicht stimmt (und das kann nicht stimmen, solange ich solche Signale re-engineeren muss), wirst Du hinterher immer die VFX Farben an das Kamerasignal angleichen müssen, obwohl es eigentlich nicht nötig gewesen wäre, weil die Kamera, wäre sie nicht auf die Farbmetrik beschränkt, das hergäbe.
Man gewinnt also absolut nichts, wenn man mit solchen nachgebauten Signalen arbeitet, würde aber viel gewinnen, wenn man mit den vermittelten kamerawerten, bestens noch in RAW, umgeht.
Ist es kein RAW, ist man auch in ACES nicht mehr farbraumneutral, weil die Farbraumzuordnung bereits in der Kamera stattgefunden hat.
ACES ist also nur so gut, wie das Eingangssignal und die Herstellerunterstützung es zulässt.
Daher sollte (muss) man den Druck auf die Hersteller erhöhen.
Dazu muss man es möglichst überall einsetzen und benutzen.
Sonst geht es wie mit Cinema DNG - wobei ich das gegen ACES gern tausche.
Aber wir sollten jetzt alle (speziell die VFXer) nicht den Fehler machen, und es einfach abhaken und so weiter machen, wie bisher.
Das wäre, meiner Meinung nach, der falsche Ansatz.

Frank

mit 16-32 Bit hat das nur ganz begrenzt was zu tun.
Wobei die gewählten 16 Bit sowieso die bessere Lösung sind.