Page MenuHome

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

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)

Details

Type
Bug

Event Timeline

Haig Petrus (hpetrus) set Type to Bug.
Haig Petrus (hpetrus) created this task.
Haig Petrus (hpetrus) raised the priority of this task from to Needs Triage by Developer.

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

Bastien Montagne (mont29) triaged this task as Normal priority.Apr 10 2015, 4:11 PM
Sergey Sharybin (sergey) closed this task as Archived.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.

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.

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.

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.

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.

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.

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.