Page MenuHome
Create Task
Maniphest T44341

Access to apx10 colorspace (as well as some others) missing in Color Management drop-downs
Closed, ArchivedPublic
Actions

Description

System Information
Linux Mint 17.1/Ubuntu 14.04/CentOS 7
Quadro 5000K
GTX 680

Blender Version
Broken: 2.74
Worked: Can't confirm

Short description of error
Although OCIO.conf contains adx10 and log10 descriptions, nothing in Blender's interface or automatic/default responses detect or apply these specific colour spaces to DPX or any other files with these spaces embedded. The presence of these extra colour spaces in the .conf file leads me to believe that this may be a bug and not simply a missing feature, but con't confirm. Natron 1.2.1 and Nuke both handle these same files correctly using OCIO.

Exact steps for others to reproduce the error

  1. Go into Node Editor mode
  2. Input an image or image sequence of DPX with apx10 colorspace embedded
  3. Go to Scene > Color Managment and change and look under Render: View: dropdown; there's no apx10 there; so leave as Default
  4. Correct the gamma to 2.2 (this seems to reveal Blender's default behaviour regarding DPX by putting it into log space by default)

Related Objects

Event Timeline

Haig Petrus (hpetrus) created this task.Apr 10 2015, 3:57 PM
Haig Petrus (hpetrus) raised the priority of this task from to 90.
Haig Petrus (hpetrus) updated the task description. (Show Details)
Haig Petrus (hpetrus) added a project: BF Blender.
Haig Petrus (hpetrus) edited a custom field.
Haig Petrus (hpetrus) added a subscriber: Haig Petrus (hpetrus).
Bastien Montagne (mont29) assigned this task to Sergey Sharybin (sergey).Apr 10 2015, 4:11 PM
Bastien Montagne (mont29) added a subscriber: Bastien Montagne (mont29).

Sergey shall know what’s going on here. :)

Bastien Montagne (mont29) lowered the priority of this task from 90 to Normal.Apr 10 2015, 4:11 PM
Sergey Sharybin (sergey) changed the task status from Unknown Status to Unknown Status.Apr 21 2015, 10:20 AM

There are two things here:

  • Currently color pipeline in DPX is kinda hard-coded. This is because there are variety of "built-in" color spaces for which we don't really want to use OCIO because of portability reasons. If DPX has UserDefine color transfer in it's setting using current color pipeline might work as expected tho.
  • The reason we choosed OCIO over hardcoded color spaces is because everyone who needs some specific color spaces in his pipeline will easily make some needed for him tweaks to the configuration file without exposing all sort of weird and wonderful color spaces to all blender users.

So thanks for the report, but i don't think exposing all the color spaces to the interface by default is the good idea.

Troy Sobotka (sobotka) added a subscriber: Troy Sobotka (sobotka).Feb 17 2016, 10:04 PM

Just bumped into this today.

@Sergey Sharybin (sergey) - any chance of revisiting this?

Currently it is impossible to save a display referred DPX with a log-like transfer from the OCIO config.

Sergey Sharybin (sergey) added a comment.Feb 18 2016, 9:17 AM

Why would one do this and why it's something we should have in official builds?

Keep in mind, OCIO is easily configurable, and it's the whole idea of using it to not care of all weird and wonderful usecases in an upstream.

Troy Sobotka (sobotka) added a comment.Feb 18 2016, 1:57 PM

Currently, getting in and out of Blender is a challenge.

For example, I recently added the 6.5 stops above middle grey view transform in. It takes values ten stops below middle grey, mapped to 0.18, and 6.5 stops above. The scene referred upper value is 16.291.

So rendering in Blender, there is no way to get a high quality DPX out with the log transform above; it is impossible.

What would be expected is the display referred log transform ends up baked into the DPX such that it can be taken out and used for grading.

A simple example, but it applies across many different areas.

Troy Sobotka (sobotka) mentioned this in T34684: DPX/Cineon : let OCIO handle color space conversions.Mar 6 2016, 6:32 AM
Troy Sobotka (sobotka) added a comment.Jul 13 2016, 6:23 AM

Any motion on this?

Every house pretty much relies on in house transforms or OCIO, so having a raw load that leverages OCIO would solve this short term. OIIO handles all the metadata longer term.

DPX support is a bit of a showstopper.

Sergey Sharybin (sergey) added a comment.Jul 14 2016, 10:33 AM

There is no motion in this. There was a patch (which you already mentioned) which kind of tries to address this, but which isn't (a) really artist-friendly (b) moves hardcoded thing from DPX IO to OCIO.

Being a proprietary nature of a format, which is mainly used in a mixed pipeline with closed/opensource software it's not that high prio for the core team. However, if there is someone from the studio who really improves DPX support in Blender and sticks around for maintenance we're all up including that work.

Troy Sobotka (sobotka) added a comment.Jul 14 2016, 2:03 PM

DPX is actually a SMPTE standard, much like many other facets already within Blender. It is used almost exclusively to communicate display referred image encodings.