DPX/Cineon : let OCIO handle color space conversions #34684

Closed
opened 2013-03-18 22:09:46 +01:00 by Julien Enche · 23 comments

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.%%%

**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.%%%
Author

Changed status to: 'Open'

Changed status to: 'Open'

%%%Will check this patch.%%%

%%%Will check this patch.%%%

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.

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.
Author

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.

flowers_rgb.dpx

flowers_rgb_with_wrong_header.dpx

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. ![flowers_rgb.dpx](https://archive.blender.org/developer/F92024/flowers_rgb.dpx) ![flowers_rgb_with_wrong_header.dpx](https://archive.blender.org/developer/F92025/flowers_rgb_with_wrong_header.dpx)

Added subscriber: @troy_s

Added subscriber: @troy_s

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 #44341 but also extends to an impossibility of loading any number of camera encodes from Arri Alexa- [x], 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.

Thoughts?

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 #44341 but also extends to an impossibility of loading any number of camera encodes from Arri Alexa- [x], 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. Thoughts? - [x] 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.

BUT

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?

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. **BUT** 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.

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.

Added subscriber: @iamawizard

Added subscriber: @iamawizard

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

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

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

@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.

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.

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_s, 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 ;)

@troy_s, 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.

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?

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

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

Added subscriber: @WilliamSchilthuis

Added subscriber: @WilliamSchilthuis

Added subscriber: @RobertWesseling

Added subscriber: @RobertWesseling

Added subscriber: @frameshift

Added subscriber: @frameshift
Sergey Sharybin was unassigned by Dalai Felinto 2019-12-23 16:42:37 +01:00
Member

Added subscriber: @Blendify

Added subscriber: @Blendify
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Aaron Carlisle self-assigned this 2019-12-28 20:25:25 +01:00
Member

Hi thank you for submitting a patch, unfortunately, we no longer use the task subtype "Patch" please submit new patches through the differential tool: https://developer.blender.org/differential/

Hi thank you for submitting a patch, unfortunately, we no longer use the task subtype "Patch" please submit new patches through the differential tool: https://developer.blender.org/differential/
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#34684
No description provided.