DPX/Cineon : let OCIO handle color space conversions
Open, NormalPublic


Group: Unstable (example)

Before going any further, this patch is not intended to be submitted as is, but is just a base for discussion.

DPX format is very flexible, and can store images in different color spaces (sRGB, Linear RGB, Cineon Log, other Log color spaces...). The main drawback of this flexibility is that a lot of software are not really compliant and output DPX with wrong header. Due to this, loading and converting DPX files automatically is difficult and error prone as you have a lot of chances to do something just wrong (eg. do a sRGB -> linear conversion whereas the file was actually in log color space).
The only way to prevent that is to let the user have the possibility to adjust the color conversion used, assuming he knows what he's doing and what color space is being used in the DPX file. Now that Blender includes and uses ocio, I think it's a good way to enhance the DPX files support.

This patch removes all the color space conversion code from the DPX code. Now, when a DPX file is loaded, color space is dynamically selected according to the file header information. If image is flagged as Cineon Log or Log, Cineon color space is selected, otherwise it just defaults to sRGB (same behavior than Nuke). The user can then adjust the setting if the result is not correct.
This also adds the possibility for users who know what they're doing to add color spaces in their ocio config file, and use them with their DPX files (something that is currently not possible if another color space conversion occurs internally in the DPX loading code).

To achieve that, I've added a function in the color management code, "colorspace_set_named", which selects a color space according to its name (or return FALSE if the color space does not exist).

Note also that YCbCr conversion are still done internally and are not planned to be removed.

When saving a DPX file, the image is flagged according to the color space selected in the color management settings :
- flagged as Cineon if Cineon Log color space is used
- flagged as Linear if Linear or sRGB color spaces used, or if the "Save As Render" option is turned off
- and flagged as "User Defined" for any other color spaces.

Then, the "Log" option is not needed anymore and has been removed from the file saving dialog.

Everything seems to work fine, but it definitely needs some more testing from users and a careful review from devs.
I'm open to any suggestions and remarks.



Was thinking about the patch. And one thing i really don't like is hard-coded color space names like

if (strcmp(ibuf->float_colorspace->name, "Linear") == 0)

This could be set using roles i think. Another thing is that with Cienon space moved to OCIO opening the files is not so much portable anymore across different OCIO configurations.

Would also be nice to have dpx file with wrong headers.

Thanks for the comments.

I agree with you that it's not a good idea to have harcoded name, and to use a new role instead.

I don't understand your comment about the portability across different OCIO configurations. Do you mean that if a user has DPX files with a specific colorspace and a tweaked OCIO configuration, it won't open nicely on another Blender installation ?

I also uploaded two DPX files :

  • One file in sRGB colorspace with a correct header.
  • The same file, with the same sRGB colorspace but with a wrong header stating the file is in Cineon Log colorspace. This file is then displayed much darker because of the Log -> sRGB conversion happening at load time.



I'm strongly believing we should revisit this and make DPX code loading precisely the same as the rest of the image loading code, EXR excluded as also needing transforms.

The main issue is that currently I know of two studios that can't rely on industry standard DPX support in Blender due to this problem. It is related to T44341 but also extends to an impossibility of loading any number of camera encodes from Arri Alexa[1], to R3D, to Sony. This is problematic on a number of fronts.

While I completely agree with Sergey on the hard coded aspect, I'm hoping that we could simply add a role for a given bit depth that would cover all encodes at any given bit depth, while making the side bar in the save file permit changing colour space encoding.

If we do this, the default colourspace encode for a DPX would be loaded as given by the default in the configuration, and easily changed as per every other format using the sidebar of the UV Image Viewer. I'm happy and willing to add in the proper configuration for a basic Cineon encode, such that current loading would look identical to previous behavior.


[1] Sample footage available at https://www.arri.com/camera/alexa/learn/alexa_sample_footage/ which is an Arrilog V3 format I believe, along with unique chromaticities.

Not total fan of using roles for that, but that's at least localizes all the definitions in a single place.

There are also parts of the patch which deducts transfet_* based on the color space, those are to be fully removed and _any_ colorspace conversion are to be fully left to OCIO.


Here's my question: how much strict DPX standard defines color spaces? The comment in code says:

The SMPTE defines this code:
*  0 - User-defined
*  1 - Printing density
*  2 - Linear
*  3 - Logarithmic
*  4 - Unspecified video
*  5 - SMPTE 240M
*  6 - CCIR 709-1
*  7 - CCIR 601-2 system B or G
*  8 - CCIR 601-2 system M
*  9 - NTSC composite video
*  10 - PAL composite video
*  11 - Z linear
*  12 - homogeneous

So basically, if the color spaces (other than User-defined) has strict definition in standard it'll be weird to override them with OCIO. And what exactly standard says about user-defined space?

Valid points.

I guess what would need to be determined is if the DPX loading code is doing anything right in the first place. I know for example, that the DPX can specify chromaticity coordinates, and Blender ignores that.

To the best of my knowledge, DPX formats are typically manually handled, as with EXR, frequently ignoring metadata in many instances.

Needless to say, perhaps there is a way to put a toggle in the sidebar that permits imagers to load the DPX "raw" and rely on their particular OCIO configuration? Would OIIO help here?

This is at least a large problem for saving as it is loading. Being able to save a display referred DPX at ten or twelve bits, using a unique transfer curve, is key.

No easy answers.

Hi guys, I am Sivaprasad Velayudhan from Realworks Studios.
and we are having the same issue of misinterpretation of industry standard dpx files.
they look darker when compared to interpretations in other tools like resolve and after effects

i am just reporting an issue about the existing state of dpx import, which is a major part of vfx work

@Sivaprasad Velayudhan (iamawizard), can you provide some example images? If they can't go public, feel free to mail them directly to me.

Given the ArriRaw converter, there are at least a dozen different implementations that can be encoded into a DPX.

The only method to properly interpret this data is via OCIO, so if at all possible, it would be excellent if we can get a "Let OCIO Handle The Decode" override.

This would enable 100% accurate DPX decoding as well as not entirely break some of the legacy bits that are in place.

If one examines the SLog, VLog, CLog, and all of the other variants at HPD's ACES repo here https://github.com/hpd/OpenColorIO-Configs/tree/master/aces_1.0.1/luts, one can see the problem; it is impossible to hard code all of the camera vendor transfer curves into Blender. That doesn't even include revisions and other custom transfers.

Most vendors these days provide OCIO transfer LUTs for their cameras, and it is expected OCIO will be handling them.

@Troy Sobotka (sobotka), easy to say, difficult to implement in manageable way. If there's no standard on that, artists will always struggle to know what's their color on disk and which space they need to use when something is wrong.

Before jumping into project called "Let's just wack yet-another-option" i'd really rather spend some time on actual format specification.

P.S. If specs really allows to dump whatever space you want without mentioning what it is in a metdata i 'd recon this POS and drop the bloody thing out ;)

It has nothing to do with specs. It has to do with transfer curves, something that everyone in the motion picture world deals with every day. It isn't complex if imagers can select the damn colourspace, just as they do with _every other RGB format out there_.

It really is simple: let OCIO configurations handle DPX transforms at the imager's request.

Visual effects and post houses _may_ rely on metadata, but just as frequently use other techniques such as even filenames (which OCIO supports to a degree) to communicate colour space components. Having a program try to deal with the _ever changing_ encoding characteristics is vastly worse than updating a LUT set.

I am unfamiliar with the artists that would have a problem with this, as every imager using DPX encodes is going to immediately look to see where they can determine the encoding characteristics.

Dropping it would be foolish as DPX forms a baseline reference for display referred encodes just as much as EXR does for scene referred encodes.

Currently, because of DPX handling, Blender cannot deal adequately with footage from cameras, which is a problem given it seeks to support small studios attempting to use it, as the above participants have highlighted.

Can you point to an exact specification about what data DPX actually expects to store and how?

The specification is an SMPTE standard that can only be downloaded from the various international standards sites for a fee. The general outline can be read at http://www.digitalpreservation.gov/formats/fdd/fdd000178.shtml#local

Add Comment