[Bf-committers] Blender developers weekly meeting, 2017-01-22

Troy Sobotka troy.sobotka at gmail.com
Tue Jan 31 04:06:26 CET 2017


Apologies for the delay in response here. Extremely busy on my end...

On Sun, Jan 22, 2017 at 9:13 AM Ton Roosendaal <ton at blender.org> wrote:

- Filmic Blender has not officially been submitted for review, we'll ask
Troy Sobotka about it.
It's in github though: https://github.com/sobotka/filmic-blender
Main issue seems to be that the filmic OCIO files break compatibility.


There are several issues at play here, not the least of which is that
everyone should come to a conclusion as to how to move forward with the
default configuration.

First, the default configuration fails ociocheck:

ERROR: NOT DEFINED (default)
ERROR: NOT DEFINED (data)
ERROR: NOT DEFINED (compositing_log)
ERROR: NOT DEFINED (color_timing)
ERROR: NOT DEFINED (matte_paint)

In particular, the "data" role, among others, should be leveraged via the
API to avoid hard coded problems and yield an agnostic application from the
colour front.

Second, on the subject of backwards compatibility, it seems to be a
hobgoblin of certain mindsets, especially that the considerations for
backwards compatibility end up being somewhat arbitrary and whimsical. In
particular, the default configuration, in addition to failing ociocheck, is
a large stumbling block to moving forward in 2017 for a number of reasons.
It was a byproduct of duplicated / erroneous / inappropriate transforms,
some of which belong in discrete sets from Sony, ACES, and the Nuke default
configuration. These were never intended to be mixed and matched, but alas,
history is history and all we can do is attempt to move ahead...

How to move forward is a reasonable question here. Two cents from someone
that probably should be ignored:

   - Order "Displays" based on primaries of the display. That is, looking
   forward, REC.709 lights (aka the lights that the sRGB specification) would
   form one display grouping, with REC.2020 lights forming another cluster,
   etc. This would allow Blender to move forward with proper views to support
   Apple P3 displays, HDR10, etc.
   - Properly implement the data role and others. Remove the hard coded
   values "Default" etc. and instead implement roles, permitting any valid
   OCIO configuration to be properly loaded by Blender with no tweaking. Props
   to angavrilov for spotting the data space issue in Blender.
   - Remove the Sequencer role and switch it instead to one of the defaults.
   - Repair and remove the vast bulk of the unfortunate transforms that
   include the incorrect RRT and others.
   - Figure out what to do with the rather broken Instagram "emulation"
   modes (Hint: Garbage them). These aren't derived properly and essentially
   are random dice. Worse, when tacking on properly designed Look transforms,
   the complexity of integration with the many existing Instagram filters is a
   mess, and certainly would not work properly with Apple P3 or REC.2020 for
   example. In the Instagram Looks place, include a single custom transform
   skeleton for imagers to craft their own CDL transforms as required.
   - Implement Lukas Stockner's patch for colour space agnostic RGB.
   <https://developer.blender.org/T46860> This would permit Blender to
   properly render REC.2020 / HDR10, and other wider gamut spaces correctly.
   - Implement the proper sRGB EOTF as opposed to the Sony transform which
   has a confused range particular to Sony's pipeline. This would essentially
   be a noop, but clean up the values.
   - Permit EXRs to be subject to transforms. This is problematic as it
   currently exists given that you can't properly transform EXRs to various
   destinations.

As we can see, there are going to be a number of challenges cleaning up the
Blender configuration. I'm happy to do the work of designing the
configuration with Views, as well as even an alternate directory full of
typical camera transforms for ingestion. That said, we should probably
seriously consider getting the infrastructure in place properly before we
move forward.

Would this break compatibility of some older files? Yes. Is this an issue?
Not given that the entire source tree is available and the project is open
source. Would this surgery be more well suited for 2.8? Probably if we can
get discussions going in earnest.

With respect,
TJS


More information about the Bf-committers mailing list