After Effects Beta introduces OCIO implementation which is fantastic news . Currently they’ve implemented ACES 1.0.3 OCIOv1 config and the beta OCIOv2 cg and studio configs.
I took it for a quick spin and realized that you can’t output a file with RRT+ODT applied? The color space Display - sRGB is just the ODT only if I’m correct?
Is this intentional? Should we add a layer/node with view transform before we decide to export to say ProRes ACES 1.0 SDR Video - Display Rec.709?
With the LUT based configs this extra step isn’t needed because we hade the Output - ''display" color spaces.
How do others do this now in Nuke etc? I can imagine that it’s very easy to add the display out as node without really disrupting the rest of the node tree/your viewer but AE’s layer system makes doing this less than ideal.
So I guess it’s up to the users to decide whether they’d like a ‘baked color space’ added to the list so they can pick it on export/write settings instead of an extra node/layer on top of your comp?
In that case it’s also up to the implementers to decide if they want to add these as a color space but It would make sense to be able to do this in default configs no? So I’m wondering if the final design of the new configs should have this by default?..
I would assume that it happens a lot that VFX needs to export previews directly out of their software with view transforms baked in instead of handing it of to editorial first in scene-referred.
I thought some more about it and while my first response sounded like a valid point I’m not so sure if it is very practical to have in the ACES supplied configs. It would mean they’d have to add all the possible display + view combinations as their own entry in the color space list making that list unnecessarily long and convoluted. What we actually need would be a way to say we want to export a view instead of just a color space when exporting/writing files and get represented with the views list instead. I just don’t know if that is technically possible? It would be up to the software vendors to implement such a feature.
I don’t think it’s something for software vendors to solve really. Seems like a design question for OCIO itself. That is, how did the makers of OCIO v2 envision this working? Then implementing that in the exemplar configs based on that intended design. I believe many of the same folks who designed OCIO v2 are the same folks designing the ACES configs.
It’s entirely possible that there is a less cumbersome way of doing this, I just don’t know of one. But if any one would, they would.
Thanks for bringing it up on the GitHub page! It looks like they have the same views on it that I also had in my last post above. We always have the option to add the combined transforms in our own configs, but I understand they do not want this in the “standard” package.
For Nuke it’s not too troublesome because whatever write node setup you create will never be in the way of your main pipeline to your viewer. Maybe some day AE will become node based
When it comes to AE they haven’t implemented the OCIODisplay as plugin yet so we can only use fnord plugin or export to something scene referred. But it’s all brand new in beta so enough time to work things out. I’ll make Adobe aware of it and hopefully they can implement it soon.
From what I understood, the desired workflow is not to have that defined in a config, but to instead do it interactively in the software GUI.
That’s true for the write node, but when you add in the OCIODisplay node before it this does affect the view. That’s where I come back to what you said earlier
I think that you’re spot on about that. This seems the best approach as it is forward thinking.
Until then, however, I imagine I’ll stick with adding DisplayViewTransforms into the config.
That’s lovely! I’m sure Nuke users will find that handy. Exactly what I had in mind when mentioning software implementation. Hoping Adobe will add a similar mechanic to their export settings. I’ll ask about it on their beta forum.
@Shebbe I came here to bring up this same issue; I should have figured you would have beaten me to it!
I just started looking at the OCIO implementation in AE beta and as you mentioned, I can really on get the 1.0.3 config to work for outputting 3D renders (I believe this is working because the old Output - sRGB includes the RRT+ODT, correct?) .
If After Effects is utilizing a v2 OCIO, surely they’re aware they’d need to provide a OCIODisplay effect to make this fully functional? Or is there another way to achieve this without an OCIODisplay effect that I’m not aware of?
Adobe may or may not be aware of this issue still have to make a summary post of the current implementation status. But yes 1.0.3 config works because the color spaces also have combined view transforms. A clunky workaround if you want to use it now is to export using either PreserveRGB or pick Raw as color space. Then add the fnord OCIO plugin on top of your comp set to display instead of transform and go from your working to display space there. They still need to add OCIODisplay plugin or combine it inside the Transform plugin just like fnord’s version.
I know from your tutorials that you preferred the hybrid managed setup so icc profile embedding still works, I’m not sure how they’ll implement such a feature because the software cannot understand rendering intent from OCIO and add proper icc equivalent profiles to it. Perhaps if they make it compatible with their own implementation of the configs but that would defeat the purpose of custom configs. OCIO isn’t really meant to be built to work together with icc I think. I don’t know if for stills AE auto tags them but you might have to add the sRGB profiles later on in Photoshop or something.
The implementation is quite fresh and AE v23 just released so they still have plenty of time to improve things. Let’s hope they will do so before release.
Thanks for your help once again @Shebbe ! So I think I learned something new here. I come from a photo background so ICC profiles are my jam. But OCIO doesn’t care at all about ICC profiles? So for instance a .jpg brought in to After Effects with OCIO enabled has a media space of sRGB and a media override color space I can select. So OCIO by default doesn’t care about that embedded sRGB color profile of the .jpg? In this case, I have to select an “Override Media Color Space” because I need to bring this into the OCIO world, and OCIO doesn’t look at the sRGB ICC profile and interpret that as an sRGB input profile. Is that correct?
I’ll try my best to answer this but I’m also still learning plenty:).
I’m pretty sure that’s the case yes. Hope someone can correct me if not. OCIO in general works with roles for certain file types/bit depths. These can be viewed in the config itself or even exposed to the user if the software provides this. Most software like Mocha AE/Pro, Nuke, 3D apps etc. already support this.
There are also other roles like color picking where you can define in which color space that should be. This is relevant for e.g. inputting client colors which are display sRGB to auto convert them into a config’s scene_linear role values like ACEScg in the case of ACES.
Next to the defaults you can also define aliases. You can have filenames that end with say _srgb_texture → ‘MyAlbedoTexture_srgb_texture.png’ and inside the config have them linked to their respective color spaces so whenever you load such a file it already gets that color space assigned.
Example from Natron.
However I’m not sure if OCIOv2 still works like this (the ACES beta configs in current AE beta). The way the config is written is a lot cleaner partly because all of the transforms are analytical built-in instead of LUTs. The alias list isn’t present in the ACES published v2 configs I think. But the current OCIOv1 ACES 1.0.3 implementation in AE Beta does have it. They haven’t added support for reading it though it seems…
I encourage you to have a look at the config file of ACES 1.0.3 inside the AE install folder. The bottom section of the list holds pretty much all the color spaces again but defined under the group aliases.
There are a lot of reasons why using OCIO over icc based management is a better choice for Film, CG and VFX. Others can probably do a much better job at explaining why but what I generally like about it is that it makes you aware of everything that you bring in or spit out. ICC based management in AE isn’t practical because it’s never updated, you see your monitor/system profiles, and icc tags don’t necessarily represent the data inside a file. A camera that recorded in it’s native gamut and log transfer function will still be encoded in a BT.709 tagged video container. Adobe is trying to “fix” this by introducing auto conversions to timeline color space for such files that can hold metadata but they haven’t even designed a DRT yet… And the added metadata part already tells that just icc isn’t enough.
Now on the delivery side of things I can understand that this is/can be annoying especially for stills. If you render to ProRes the file automatically becomes tagged as Rec.709 which is what we want in most cases… but we still need some tools eventually to also properly tag files on the way out.
. Currently they’ve implemented ACES 1.0.3 OCIOv1 config and the beta OCIOv2 cg and studio configs.
