ACES...

[Blair S. Paulsen]

Michael's post is hard to argue with. I just wish there was an easier way to reap the core benefit of a benchmark color space. Behind all the acronyms there is a very real upside to being able to take a wide variety of sources and put them in a reference container with fixed values for post/DI.

If VFX were not a part of the scene then roll your own LUTs might be sufficient, but that's not most people's reality. I also think that whatever dire warnings about digital and archiving you might place credence in, having an open source standard with wide parameters will improve the odds of being able to access digitally acquired images in the future.

Cheers - #19

[Bruce Allen]

Michael:

"What attracts you personally to the desert?"

T.E. Lawrence: "It's clean"

Although I agree that the complexity of ACES is kinda the opposite of clean :)

Seriously, though: what do you guys use most of the time while we wait for ACES? Don't want to give away trade secrets but I suspect you guys aren't able to stay in R3D until the very end, based on your public posts (eg Dragon Tattoo) - and film VFX workflow in general. It's just impossible.

So: DPX log files with P3 or 709 primaries? RedLogFilm? How much tweaking of the R3D decode settings do you do?
(here's what I do: RedLogFilm and just get WB, color and exposure roughly right... then do the rest in RGB grading environment. Run NeatVideo and optical correction in between. Ignore exhortations to "stay RAW")

What LUT do you use? If you give stuff to a VFX vendor do you give them a preview LUT for your RedLogFilm conversion to 709 / sRGB / P3? Do you make that yourselves?
(here's I do: use the Arri LUTs)

I must admit to a hack of my own: even when I work in Log format... I still save as EXR. The disk space savings are huge, the CPU overhead not too big... and there is no quality loss. Sometimes I sacrifice a tiny bit of quality by saving in 4:2:2 format with B44 compression. Huge savings in disk space. Only drawback is the potential to confuse the heck out of 3rd parties!

Bruce Allen
www.boacinema.com

[Zack CC]

Man, this thread got good all of a sudden.

[Martin Stevens]

Thank you Michael...........I love reading your posts..............and your Blog.

THANKS!

Also.....isn't LA a desert, or wasn't LA a desert once?

;)

[Gavin Greenwalt]

BTW what LUT do you guys use when working with RedLogFilm?
Bruce Allen

RedColor3 for all below...

Linear EXR 16b -> (No LUT) -> Nuke
RedLog Film DPX 10b-> (Cineon>Lin) -> Nuke
RedGamma3 TIF 16b-> (sRGB > Lin) -> Nuke

to...

Comp in 32b Linear w/ (sRGB Viewer LUT)

to...

lin > target LUT.

So in many respects a very similar workflow to ACES.

[Blair S. Paulsen]

I have not tried it personally, but Gavin's use of Nuke as the "mezzanine" point seems like a great way to get some of the benefits of ACES topology sooner than later.

Its also worth noting that RedLogFilm uses a proper Cineon curve so if handled properly (yes Bruce, that's a big IF) R3Ds processed to DPX using RLF should provide predictable results.

10 bit log DPX has held up well considering its age, but IMO a migration to OpenEXR and putting the log crutch away is overdue.

Cheers - #19

[Ian Vertovec]

Hey Bruce,

We do things very much the same as yourself. REDlogfilm DPX with P3 primaries mostly.

I usually build a custom VFX LUT per show, but essentially start out in the same place. I generally do this for creative reasons, not technical. A broad family comedy and a cult horror movie could both have a REDgamma3-esque starting point, but why should they? It really doesn't take a huge investment in time to build something custom based on the lighting style and conversations with the DP.

You can use an Arri lut if you wish, but understand that Log-C isn't exactly the same thing as true cineon, which REDlogfilm is based. So you won't get results identical to what you would get if you used a true RLF to RC3 conversion. Having said that, it will still look great 90% of the time.

Now when I grade, I generally don't use the actual lut, I use the correction that was used to build the lut. That way if I find it paints me into a corner, I have the controls to back it off. Also I keep handy the original lut as a reference to make sure I'm "still in the zone".

That is something that has always concerned me about ACES. The RRT and ODT combination really seem to resemble a 5219 print stock emulation, at least the early stuff I've looked at. So everything has too much contrast. Like magic bullet was applied or something. I'm concerned about fighting to reduce contrast and/or saturation should it not be creatively desirable.

[Gabriele Turchi]

REDlogfilm DPX with P3 primaries mostly.

Now when I grade, I generally don't use the actual lut, I use the correction that was used to build the lut. That way if I find it paints me into a corner, I have the controls to back it off. Also I keep handy the original lut as a reference to make sure I'm "still in the zone".

Hi Ian ,
when you say """DPX with P3 Primaries """ what do you mean ?
that you process DPX (from R3D ) applying a P3 Colorspace matrix ?

ps: i agree about using the layer/node (curve) custom built that emulate a 1D lut (so you can modify accordingly ) ...

Scratch have a very nice function that when load a 1D lut it can create a curve out of that (so you can modify the curve )

g

[Tim Whitcomb]

I honestly don't understand your point. All technology gets improved over time, and all methodologies get refined over time. ACES is an industry wide initiative that is currently a work in progress that will hopefully provide improved and standard approaches to some current issues (archival formats are one very major one).

I could just as easily point out that a bunch of huge movies are coming out that aren't being shot on film. Or Red cameras. The statement would be equally as meaningless.

Context Mike .;; in reference to confusion around a complex subject matter - this kind of thread is dangerous as competitors can spin it as " yeah welll Red is not Aces compliant workflow" and more fud spreads... so I think in that context it was meaningful but I'm not surprised you don't. LA is no longer the only place movies are made Mike and we struggle with workflows like the rest of the world and welcome a standard like ACES... Meantime I felt it necessary to iterate that Red's current challenges with ACES is not relevant to getting a quality deliverable as can easily be misconstrued in this thread.

[M Most]

.. this kind of thread is dangerous as competitors can spin it as " yeah welll Red is not Aces compliant workflow" and more fud spreads...

Well, if we're pointing out FUD, allow me to quote Cioni:

The complex world of ACES will get worse before it gets better. ACES will cost more. ACES will take longer. ACES will eat up more space and require more support, more assessments and more adjustments.

ACES is constantly getting better because its creators understand that there are problems at this point, and also because they understand color science better than just about anyone here or elsewhere on this planet and therefore have the experience and knowledge necessary to eventually work out those problems. ACES will cost more??? Really? The fact is that ACES is an industry initiative being done by the Academy of Motion Picture Arts and Sciences Scientific and Technical Committee, and whose work is free to all who want to use it, and will remain so. ACES will take longer?? ACES will eat up more space and require more support? Once again, the fact is that ACES can easily be incorporated into existing workflows. It basically replaces an input transform with an IDT, and an output LUT with an output transform, consisting of the RRT/ODT combination. You can use those transforms as part of a "live" working environment. Using an ACES workflow does not require creation of new files and does not require use of the half float EXR container. Those things are there for storage and image exchange.

I have already gone on record in this thread as portraying the ACES system as a work in progress, particularly the RRT. I have said that more work needs to be done to refine it, and that in its current state, there are issues that need to be addressed. What irks me is that I'm quite sure Michael is aware of all that, yet statements are made here that are patently false. I too believe in facts, not FUD. The facts are that it is a work in progress, is currently imperfect, but has a lot of potential for a lot of reasons, and will evolve over time. FUD is that it costs money, somehow adds time to the post process, and takes up more space.