Apologies for the delay in response here. Extremely busy on my end... On Sun, Jan 22, 2017 at 9:13 AM Ton Roosendaal <[email protected]> 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 _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
