If you're looking for an intermediate format for working in ACES you have OpenEXR. ProRes or DNxHD would be inputs or outputs from an ACES workspace as they represent limited, (usually) display-oriented color spaces and not ACES.

Sony has designed some of their cameras to work more explicitly as inputs to an ACES workflow, cameras like the F55 and F65. The format itself isn't necessarily as important and there isn't much cause for transcoding from any other format to this format if you're going to ultimately be working in ACES anyway. You're just creating more work and consuming more disk.

Other cameras work in ACES with their camera-specific IDT (Input Display Transform). So you would take the CinemaDNG or R3D or ProRes or whatever the camera records and then transform it into the ACES space while applying an sRGB or rec709 ODT (Output Display Transform) for viewing, and any target space needed for distribution.

edit: unfortunately there isn't widespread adoption yet. Old dogs don't like new tricks, even if it makes their life better and easier.

edit2: also, if you aren't shooting a RAW camera there is basically no reason to be messing with ACES. Any GH, any camera that shoots h.264 or 422 Prores, it's a waste of time.

Wat?

ACES is a large color gamut, larger than even the visual spectrum. There is no using 100% of it.

You can work this way in Nuke and in DaVinci and even After Effects to a certain extent. You don't have to develop anything.

This is part of the reason we can't have nice things...

Below is a test of GH2 with ACES sRGB:

Whatever the theory says, ACES give a colors and tonality that GH2 can't produce by itself or with any normal grading, filter or plug-in. And I don't see any headache working with ACES at all.

What exactly do you mean when you say that the video you posted is with "ACES sRGB"? Those are two different mutually exclusive color spaces. Either something is in sRGB, or it is in ACES. Perhaps you could share a little more about your workflow? I think one of the main reasons that you don't see any headaches in working with ACES is because you misunderstand what it is. As far as stuffing ACES into an 8-10 bit codec, you could certainly do it, but I'd advise against it. Capturing full ACES gamut generally requires floating point, and your color data will occupy only a tiny subset of the total gamut, and consequently most of the bits of the codec would be wasted on colors you will never care about, effectively giving you something like the equivalent of 5 bit sRGB chroma resolution. That's why the ACES spec explicitly spells out that OpenEXR is the interchange format.

"ACES give a colors and tonality that GH2 can't produce by itself or with any normal grading, filter or plug-in." Uh, my only response is "citation needed." What are you doing with ACES, and what do you consider "normal grading"? Ultimately the math of an IDT to transform GH2 footage to ACES is just linearization, and a matrix multiply to move from sRGB primaries to ACES primaries. I'm not sure why you think this math has magical powers, or that it's terribly exotic.

As far as I know, I was one of the first people to actually have to set up a Baselight to do end-to-end ACES grading for a national TV spot in the US, and I attended a very interesting presentation by SMPTE about ACES workflow a while back, and I genuinely have no idea what you are talking about.

@producer How about letting us in on your secret?

@producer I thought you might like to share how you do your ACES workflow test videos.

Ok. You do realise that even the Sony YUV 10bit codec is rec709? It's the Vegas export that can't do the colour space conversion to other codecs.

Nuke doesn't like ACES (2.0) at all (I don't know about AE and DaVinci, but I really doubt there's much difference). As I said, the point of such a large color gamut is to make all the other fall into that one to simplify the linear aspect of a production. Unfortunately it creates more problem than it solves (at least in Nuke). By using 100% I meant the advantages it offers (i.e. a much smoother workflow) and no one yet to my knowledge has managed to take all the benefits of what it is supposed to do.

Nuke has problems with a lot of things thanks to The Foundry. ACES or no it doesn't properly deal with Alexa conversion. It doesn't have reliable streaming media support and, currently, it's got a very unhealthy habit of writing corrupted project files from the Mac version. One can only hope they successfully sell the company like is their aim to a more capable licensee. And yet none of that has anything to do with how other software works either.

Besides the larger gamut its aim is to also normalize the results from various cameras. Most of them nominally produce imagery that must first be "fixed" before actually crafting a look. It's easy enough to find solid reference for the benefit of better nominal imagery through an ACES pipeline versus the standard sub-standard methodologies. And I've seen it first hand with RED imagery as well, given footage right off the camera looks pretty horrible through their typical color science.

The only thing that makes it necessarily harder to deal with is having to deal with other people who think it's trying to take their job, who haven't read the white paper, old dogs, new tricks, etc.

Plus as I said, many production companies had that kind of things for years. Where I worked we use to work with a space called bMut(and a lot of numbers after that, R&D versions) It's not quite as wide as ACES (but not far from it) and it did the job (with a lot of scripting).

I worked at two of the premiere shops for color in film (among others), Digital Domain and Sony Pictures Imageworks, who, along with ILM, set the standard by which the entirety of the industry followed and ACES is the result of this, along with OpenEXR. The methodologies for color prior to this were terrible, with the wheel being constantly re-invented and wasteful, show-specific solutions. Those were the dark times and they should be viewed from a place of "glad we don't have to live that way anymore." All that pain was necessary to arrive at this better solution.

This sRGB conflation with ACES of producers is unfortunate though.

In the context of producer's footage, he isn't starting with anything that would benefit any more from an ACES workflow than working in a 32bit project in After Effects. Most of the work you see online is from people working in 8bit or 16bit workflows. The results you can get from a float workflow, yes, can be startling compared to the conventional 1990s (non Nuke) way most people still seem to work but this isn't really a function of ACES.

An irony here is because he's starting with rec709 footage specifically and fixated on sRGB, he's actually, in a very round-a-bout way, transcoding to a smaller gamut colorspace than where he started, though this is often just an academic distinction and shouldn't adversely effect the footage in any way that matters here. It's the one appropriate for his monitor (sRGB), if he doesn't at least have the equivalent to an HP Dreamcolor, but it's much ado about nothing. ACES is for higher dynamic range sources. Even the white paper says don't bother for low dynamic range video sources.

And another very fresh test (1080p):

Rec2020 is already making its transition in. 4K/UHD is ushering in the end of rec709. Hopefully gamma will be rigidly enforced with this new standard and not the sometimes 2.4 sometimes 2.2 liberal application of gamma that you find with rec709 implementation and deployment.

Unfortunately, it too keeps the anachronistic and unnecessary "studio swing". I dearly hope that I see that nonsense disappear in my lifetime.