Log space round tripping

I’m using Nuke with ACES and we received DPX (cineon) log plates which will need to be returned in log as well. Writing out to ADX10 doesn’t seem to work as we get all sorts of weird clipping errors. We can use ACEScc but I’ve read that’s not supposed to be used for writing. What is the proper path for log - lin - log with ACES?

Thanks!
Den

I’m having this same question. Can anyone shed some light here?

Hi,

ACES does not really support Cineon directly, however given you are using Nuke, both the ACES OCIO Config with Input - RED - Curve - REDlogFilm or Nuke’s Colorspace node can encode and decode to Cineon.

Cheers,

Thomas

Thanks Thomas. I tried both of those and am getting slightly different results when comparing them with the original DPX in a round trip. However, inspired by your suggestiuon I tried the OCIOlogConvert node in Nuke and that seems to match perfectly. I’m not sure what the OCIOlogConvert is doing under the hood that may be different from the others. But it seems like that’s a viable option. Yay!

On a related note, I’d like to try to educate the indie filmmakers we work with about the benefits of using an EXR container rather than DPX as a stepping stone towards getting them to embrace ACES. Can you point me to anywhere that this is discussed, either here or elsewhere?

I’m not using DPX much these days, it is still widely used though and received an update last year to support HDR and WCG. The problem with DPX is that it is not really geared toward VFX. It is good for interexchange of plates between companies but beside that it is quite limited. Last time I checked, it did not support alpha channel for example, then there is multi-channel and deep :slight_smile:

Yes we certainly would not use it for CG. But even for interexchange, say of plates with VFX comped in, would there be an advantage to returning 16-half EXR files (in log) to DI as opposed to 10-bit DPX? Or is that gain not significant?

You should not write log data to a half-float EXR. The way EXR stores data is geared towards linear, and is inefficient (and potentially lossy) with log.

1 Like

Thanks for clarifying that Nick.

DPX has supported alpha for 20 years as I remember outputting them in Shake and at the time the Flame would crash on reading them. These days sadly many DI applications such as Resolve will crash on reading them (flame and nuke read them fine).

@Derek: the OCIOLogConvert node in nuke simply uses the colorspace of the compositing_log and scene_linear role in your ocio config. So it is not a strict cineon log transform like the build in nuke log2lin node.

src = OCIO::ROLE_COMPOSITING_LOG;
dst = OCIO::ROLE_SCENE_LINEAR;

Yes, I should have written instead that support for alpha in DPX is sub-optimal. So I checked with Nuke and it write alpha channel properly, so this at least that. The spec has slots for various other ones: http://www.fileformat.info/format/dpx/egff.htm