All,
I’ve prepared a first working draft an ACES ODT end-user document that lives on my fork of the aces-dev git repo. The document is written in LaTeX so it’s easy to provide comments, fork, make changes, and provide pull requests for those interested in helping out.
For those who prefer an MS Word version …
TB-2017-00x.docx (831.5 KB)
Please ignore minor formatting and typographical issues in the Word version as I’ll be manually translating any comments to LaTeX anyway.
Nice work, Alex!
A few thoughts:
Thanks … took a few rounds of back and forth with @joachim.zell to get it right
I’ll see what I can do about getting some clearer images in there.
Yeah, the iPad is a curious device. Not really what we’d like people to be using for this kind of application, but this document is intended to be “real world” and the bottom line is that people are using them. I’ve supported a few shows that have used iPads and it’s actually possible. The key properly encoding the images for what the iPad expects by choosing the right ODT and tagging the media files properly.
Here’s a few good resources on the topic :
Right now we aren’t doing anything different for the X300. I’m going to have to think about this one a little and maybe do some testing (we do have an X300 at our disposal). I’m not sure if we actually need to do anything different, but we should confirm that.
Hey Alex, I just did the service of running out the PDF version of the LaTeX doc for quick reading, and added a draft watermark just to avoid confusion. Figured I’d share with the rest of you.
TB-2017-00x.pdf (1.7 MB)
Thanks @SeanCooper …
I probably should have included the PDF with the original post. Can you throw a PR at my fork for the draft watermark?
Thanks - I hadn’t come across a coherent explanation from Apple re: the ‘nclc’ tag. It’s funny, I’m normally trying to do whatever I can to prevent Quicktime from doing anything too clever on playback, precisely because we have no knowledge of how a client intends to consume a deliverable, outside of whatever specs they may or may not give us. It’s never fun being the one to have to explain why the same deliverable looks different when played back on Quicktime X vs 7, or on a Mac vs PC, Premiere vs FCP, VLC vs whatever. Likewise, in Nuke, the only way to “safely” view a display-referred quicktime is to bypass the display transform and set the read node’s transform to “Raw”.
In any case, it’s very difficult to control for incorrectly / inappropriately / unintentionally set metadata when writing Quicktimes, just as it is difficult to control for how that metadata is or isn’t handled by the playback application. It’s kind of like handling DPX metadata or trafficking CDL values – you need a plan for these things – ideally, something describable via CLF or ACESClip.
Using iPads to view QuickTimes makes perfect sense, and I often advocate the same thing; and I’m not really against the idea of describing a viable workflow for using iPads – there’s lots of real-world value in that. But that would require a conscious decision to either delve into the nuances of QuickTime encoding for iPads, or to not open that can of worms. Either way, it’s a slippery slope to a conversation, possibly even a project, well outside the scope of ODT applications.
It’s really a much broader existential question – if ACES provides ODTs for idealized physical devices, should ACES provide something akin for video encoding – reference ffmpeg flags for HEVC, codec settings for ProRes, etc – such that accurate LMTs could be derived to accurately simulate one device on another? Would vendors be willing / incentivized to contribute whitepapers, code, ffmpeg flags, device or application characteristics, advice? Whose responsibility would it be to maintain a best-practices document like this? Where does ACES end and consumption begin?
I do think there’s an opportunity to describe iPad-based workflows here, but I’d be sensitive to the qualitative difference between signal encoding and file encoding – for a document like this, maybe acknowledging such a difference is enough, and the rest can be left as an exercise to the reader. (Although I’d again argue that this would be a missed opportunity to solicit vendor involvement, seeing as ACES positions itself as the vendor-agnostic, supremely capable, all-singing, all-dancing modernist color encoding of tomorrow 
). If you guys need another block for the diagram, I’d be happy to provide acronym options.
I’d be curious to know what you guys are doing in terms of calibration – and if we’re doing something different, I’d be equally curious about what that would imply. I’ll grill one of the engineers at work for specifics, in terms of device settings and exact calibration white point (in cie1931 values).
But that we’re even having this conversation is why I wanted to bring up the Judd Vos thing in the first place. How can / to what end should ACES facilitate communication or declaration of device-specific settings, or facility-specific practices? CLF seems like the appropriate place to characterize and describe device / facility specifics, I think. Could be a good way to share just enough information between vendors without crossing into IP territory, creative whitepoints nonwithstanding.
Beyond Quicktime & co, (iPads, iPhones) + ACES are used in realtime applications, e.g. ARKit, I would be very happy to have some ODTs for them.
Cheers,
Thomas
@Thomas_Mansencal … agreed but primary intention here is to document the current set. Might be out of scope at this particular moment, but this opens a bigger conversation about what ODTs are needed moving forward.
@Alexander_Forsythe just submitted the PR for the watermark
Last QuickTime & Co. comment! Just felt it was worth mentioning, Apple has published a SMPTE document called RDD 36:2015 - SMPTE Registered Disclosure Docs - Apple ProRes Bitstream Syntax and Decoding Process – I haven’t personally looked at it, but this felt like the right place to post. It would be cool to have a suite of LMTs that simulate how certain codecs and settings are gonna screw with the color 
Totally different topic – I noticed (I believe) there were VFX sections listed, but I don’t think they had any content. Content would be pretty swell. Just curious what the discussions surrounding VFX ODTs have entailed.
I did want to bring up ODTs for Texture Painting (diffuse maps specifically). I know there are a couple of camps here – those that feel that textures / assets absolutely must be evaluated under the shot / show look(s), and those that feel that asset texturing and lookdev should be absolutely decoupled from show- or shot-specific looks. In either scenario, I’d argue that there needs to be a “neutral” or “monitor” look that consists of a gamma-corrected view of texture colors as sampled by the renderer. And I’d imagine that, unless the texture artist is explicitly baking in the RRT to the texture, the appropriate ODT to use would be one that bypasses the RRT altogether; not sure about how to handle D60 sim, since it may or may not give the wrong impression, depending on, for instance, if daylight or pyro shaders are used in lighting, and whether or not they’ve been tweaked to use AP1 chromaticities (presuming an acescg-based texture pipeline).
Anyway, just wanted to get your thoughts. Is my thinking correct in that the recommend ODT should bypass the RRT? And… that white point, should we be simulating D60?
This is actually a pretty involved question.
If you are working in ACEScg, you have linear files with D60 already. You are probably looking at it on a D65 computer monitor, so if the target is a cinema project, you would want to use the RRT with an ODT for D60sim to see a display referred image for the theater. The painting though will have limited dynamic range based on the ODT chosen. Better would be to paint with an HDR ODT for an extended range even on a monitor as long as the artist is aware that they are painting on a low contrast device that cannot show everything. (or they can paint knowingly in a log space – artists are often very adaptable.)
The previous paragraph about ‘bypassing the RRT’ has an assumption problem though. The RRT currently
has the first reduction step from linear 33 stops of range to a display output of about 400,000:1 (if I remember the number correctly). It does not have a single gamma but is an S-shaped curve over the whole range. The ODTs then ‘bend’ the highlights for the dynamic range of the output chosen which sometimes can effect any of the values above the mid-grey. So (sorta) half the highlight treatment is in the RRT and half is in the ODT. So the RRT cannot really be bypassed to accurately predict what the ACES display-referred image would look like.
You mention two camps here, looking at assets with the show ‘Look’, and the other as ‘scene’ assets that are decoupled from the look of a show. ACES was designed with the latter in mind, but always had the ability to flip in the look (the RRT+ODT). The idea was that making assets for the ‘scene’, (i.e. linear light) would make it easier to drop-in a dinosaur into existing photography, so that all you had to do was match scene lighting (which is known at the time of work) rather than the look of the movie (which isn’t really known completely until the end of post). Though DPs plan for a look, there is often a gap between the plan and the way things really go.
So how to paint textures (or matte paintings)… one way is to use other techniques and then invert them as display referred through the RRT and the matching ODT for the display used. But whether it matches the scene depends upon the care taken by the artist. Eventually, painting on HDR monitors will be a great solution, because the texture can be designed for a larger range. In the meantime, a simpler gamma correction as you mention is a widely used method to get the painting into ACEScg as an approximation, then some work is needed in lighting for the texture and by the colorist to lock it in. This is working in scene space.
If there is insistence on creating it for the final look, then I recommend the full RRT+ODT preview LUT should be used – and at the moment – a higher dynamic range ODT than the show is designed for should be used.
This area is part of the ACESnext conversation, and showed up in the April ARE paper
Actually 100,000,000:1 … 10,000nits to 0.0001 nits
Per Jim’s comment, this is complicated and depends highly on the workflow and tools used to do texture painting. To address the directly question … no you don’t ever want to use an ODT without the RRT. The results would probably look pretty erroneous as ACES data is encoded very differently than what the ODT expects.
Thanks. Yup that is it. I didn’t remember correctly. 
Hey guys! Really appreciate your patience and responses, as always
So, first, let me apologize – “an ODT that bypasses the RRT” makes pretty much zero sense. ODTs are, by definition, RRT-refferred; and “bypassing the RRT via an ODT” would be applying a meaninglessly dumb operation on the wrong side of the equation. By “ODT that bypasses the RRT”, I’m realizing I mean an ODT-referred LMT that serves to “neutralize ACES tone mapping” so… roughly, AP0-to-display + EOTF + invODT + invRRT I suppose.
Jim, your points are well taken, and I’m fully picking up what you’re putting down – for our matte painting department, we’ve tried both approaches you suggest – working on Log integer data under an appropriate concatenation of transforms, as well as working directly on top of display-referred plates with invertible transforms… the latter seeming especially dirty to me, but it’s better than the alternative (having to work on top of power-windowed, grade-baked-in, plates… in 2017…).
I was speaking in particular about painting diffuse textures for CG, however, which has pretty different restrictions and workflow requirements; in particular, linearized diffuse texture RGB values must not surpass 1.0; else, physically based renderers are inclined to treat the textures as emissive. Painting linearly but viewing under the RRT+ODT would roll off acescg values greater than 1.0 (and presumably appear darker compared to a straight acescg --> bt.1886 gamut and conversion transform). But more to the point, these are normalized, linear color maps intended to be perceived as such by the renderer – plus, if texture artists are pulling in an sRGB image, they have a certain expectation that’s more or less thwarted when when they discover that sRGB --> acescg --> aces --> RRT+ODT (sRGB) is not the same thing as sRGB --> acescg --> sRGB. And neither are the same as evaluating under what the actual shot or show lut(s) look like.
I guess I’m not certain if neutralizing the RRT+ODT tonemap via LMT is “truthier” than leaving it in. If all our shows were ACES shows, I’d feel pretty good about using the RRT+ODT in texturing; but since we have about as much ACES work as we have non-ACES work, it’s difficult for me to determine the most appropriate way of viewing to preserve “job independence” in our assets. As Alex suggests, there are a lot of nuances… lot of ins, lot of outs, lot of whathaveyous.
Sorry guys, I’ve derailed this thread a whole lot. Please feel free to move / delete / prune whatever you’d like. I think it’s more important that you guys get the feedback requested, rather than hearing me harp on these edge cases that are probably suited for other threads…