Should the OCIO configuration be a user preference or a file setting? Perhaps the default file setting could be a user preference, but it still seems to make sense to have it per file, so that you can have multiple projects with different OCIO configurations, and not have to switch the user preferences to edit them correctly.

taken from https://wiki.blender.org/index.php/Dev:Source/Image/OpenColorIO

I'm not sure User Preferences is good enough, because loading and saving a blender file with a wrong config can lose data in the form of color space selections in various places.

I wonder if it is possible to make 'resetting to default' that happens on file load somehow non-permanent, i.e. keep the true setting in memory (until the user actively changes the field) and write it to the file on save? Or at least make it cause a more obvious error report, than some obscure messages written to the console.

Adding @Bastien Montagne (mont29), so i'm not the only judge here.

The reason why Default and Filmic are treated with preference is simply because they are (or will be) included in Blender by default.

But, I can see that having the option in the file would be better.

Now, how to implement this? Having an option per scene is even more complex since e.g. Images can be shared between scenes, so that's not really great. Then, where in the file should the chosen config be stored? The only approach that I can think of right now is adding a ColorConfig datablock, and that's not going to happen.

@Lukas Stockner (lukasstockner97), i don't see reason of treating bundled configurations any different. From user perspective you just have a list in user preferences where you can add/delete configurations, give them names etc. And then for a .blend file you specify which of those registered configurations you are planning to use. This gives you following benefits:

• We can extend bundled configurations as much as we want
• People can register their own funcky configurations as much as they want
• When you open .blend file you'll always have it displayed/rendered correctly, assuming you've got corresponding OCIO config registered. Without worrying that you forgot to change OCIO configuration in user preferences prior to opening the file.

The simplest way would be to store OCIO configuration name in WindowManager. It is not ideal and kinda annoying, but i do not see other alternatives at this moment.

This seems more flexible approach to me, but here is list of issues which are not covered at all:

• How do we make it easier to interchange one configuration with another? Shall we introduce non-color space as a role to address current issues? Do we have other cases to be covered to make interchange less painful?
• How do we make per-project OCIO configuration easier to handle? Is registering configuration rom the SVN repository enough? How do we prevent accidents from happening when artists update blender and not copying user preferences before opening/saving production file which was supposed to use custom OCIO setting?
• How do we make it more reliable rendering/farming pipeline with custom OCIO configuration? Shall we allow bundling OCIO into .blend file?
• Pretty sure i'm missing something important here.

This is a tricky project to handle correctly and requires brainwork and design before you can start coding anything. In fact, this design work which is to be done is 95% of work here, code will not be hard to be made here. So i would really suggest first coming up with a design proposal, discuss it with all involved parties and only then start coding.

How do we make it easier to interchange one configuration with another? Shall we introduce non-color space as a role to address current issues? Do we have other cases to be covered to make interchange less painful?

While most work in a project is going to ultimately be bound to the colour transforms in a config, I would strongly recommend that the default roles in OCIO (and validated in ociocheck) are leveraged to permit transitioning between ociocheck'ed configurations. This will assert graceful configuration changes.

(default)
(scene_linear)
(data)
(reference)
(compositing_log)
(color_timing)
(color_picking)
(texture_paint)
(matte_paint)

These are the default roles ociocheck enforces.

If we at least move away from hard coded transform hunting and leverage the role lookups, we can probably head off most of the badness that ensues when flipping a configuration.

For custom OCIO configurations, maybe the datafiles/colormanagement/ folder could contain subfolders for each, and it would simply use the folder name in the UI. No need to set up anything up in the user preferences, Blender would automatically detect this.

To me it seems the scene is the right place to choose the configuration, not the window manager. Maybe it's tricky with multiple scenes?

For filmic though, why have a separate configuration? It adds extra steps for users to switch between view transforms for no good reason I can think of, and long term it gives developers more work to maintain multiple configurations. As far as I can tell we should be able to add extra filmic view transforms to the existing configuration, perhaps with a new mechanism to limit looks to certain view transforms.

For filmic though, why have a separate configuration?

Because the current configuration is a hodgepodge of cobbled together transforms that aren't even relevant or are outdated. Also, OCIO is oriented around a consistent reference space, which moving into 2017 means AP1 or REC.2020 primaries. Maintaining a bunch of incompatible transforms makes zero sense.

I agree that using the family category could help in limiting or classifying transform options however.

If there's a different scene linear and reference space, then I can see we need a separate configuration. However, currently filmic still uses the same Rec.709 reference space?

If the plan is to keep the Rec.709 reference space in filmic for 2.79, then I would suggest to merge it into the existing configuration. We could then add a new configuration when there is a new reference space. Otherwise we need to break compatibility quite badly, or we end up with 3 configurations to maintain and present to the user.

Also, when we officially support a configuration with a different scene linear space, we should think about how to deal with compatibility of .blend file assets. It would be very confusing if the user has to be always aware which configuration each asset was made for, if there is no automatic conversion.

The only reason we are having this discussion is because folks are actually using and trying the colour management transforms. At least part of that I would attribute to the clairty of the configuration which has all portions operating together.

This is not the case with the previous configuration which yields essentially random results due to the mix and match nature.

I have said that merging is the very thing that got us into this mess. It will not get any better if we carry this trend forward.

Regarding references, and other changes, Filmic was always intended to introduce concepts piece by piece. Those pieces need the foundational design I laid out in order to achieve them with any degree of sanity. That is, it will make additions and evolution much easier if the foundation is stable. Default configuration merge hell is no such creature.

What are you suggesting the path is then:

• Add filmic config in 2.79 with the better reference space
• Break compatibility when changing to a better reference space
• Add a second filmic configuration when changing to a better reference space
• ... ?

Apologies for not being clear on my thinking.

First, I think to avoid the pain of developers dealing with confusion and misunderstanding, I believe the ability to set a config from within Blender is very wise, as Sergey has pointed out.

Here is what I would attempt short term:

• Add configurable config selection for 2.79 if possible.
• Tidy up all loose hard coded searching to use appropriate roles for 2.79.
• Leave configuration as is and prepare folks as best as possible.
• Have Lukas Stockner's patch integrated for sorting out testing of wide gamut reference configuration.
• Minor tweaks as outlined in the curves posting I made etc.

Essentially use 2.79 to get us ready for wider gamut and solid scene referred workflow. Implementing roles across the board fixes pure broken compatibility issues in terms of outright errors. That paves the way for a solid foundation for 2.8 changes. For 2.8 first release:

• Remove previous configuration and replace with a cleaned up variant suitable for 2017 with clear documentation. Happy to handle this part if desired.
• Add cleaned version for 2.8, with decent view transform for rendering. Plausible to even leave the sRGB EOTF variant as default.
• Integrate cascading UI or sorting to help folks grow into the tidied configuration and keep relevant transforms in relevant areas.

Moving forward to the release after, due to exposure and confusion likely to result with a stable view transform and scene referred / display referred concepts:

• Convert to wider reference space with properly transformed Views.

That brings Blender into wide gamut rendering and many other facets. Possible to shift to wide gamut for 2.8, but I am willing to wager a *huge* amount of confusion with too aggressive changes? Or is 2.8 the wise spot for this?

Wide gamut *will* break compatibility no matter how we slice it. Perhaps we can start the educating at 2.79?

2.8 seems like the right release to introduce wide gamut, and indeed we can do some intermediate now in 2.79 so we can already start testing that. I'm hoping we can keep some compatibility when we officially introduce wide gamut, maybe automatically converting between scene linear color spaces. It's going to break a lot of things, importers/exports, shaders, scripts, .. . But that's for another time to discuss.

I don't think it makes a huge difference if we have one or two configs now, but I would still make them as compatible as reasonably possible. My suggestion would still be one config in 2.79 for the sake of simplicity now and when have make it compatible again with more changes in 2.8, but I will leave that decision to those actually working on this.

If there need to be two configs, I would strongly suggest to make changes, since switching configurations now means some color spaces have different names or are missing entirely. For example if I set a normal map image to Non-Color now, that does not exist in filmic and it will use the SRGB EOTF, and the render will be wrong. Right now users are mostly interested in getting a better view transform, if switching to filmic breaks normal maps (and more) that's a problem a lot of users will run into.

There's a few easy things possible for compatibility like:

• Rename Non-Colour Data -> Non-Color Data (images and view transform)
• Rename sRGB EOTF -> sRGB (images)
• Maybe add back Linear ACES, Raw, VD16, XYZ (images)
• Rename sRGB / BT.709 -> sRGB (display)
• Rename sRGB EOTF -> Default (view transform)

To me it seems that if we are going to do renaming or removing of color spaces, 2.8 is really the better time to do that so we can do version patching for compatibility, rather than now already using two partially incompatible configs.

For example if I set a normal map image to Non-Color now, that does not exist in filmic and it will use the SRGB EOTF, and the render will be wrong.

This particular issue is the one I spoke of regarding roles. If we implement roles across Blender properly, using the ones enforced by ociocheck, this becomes a non-issue. That is, the data role in Filmic versus the data role in the current would both point to equivalent non-colour transform definitions.

Rename Non-Colour Data -> Non-Color Data (images and view transform)

See above. Solved by proper implementation of roles. American versus Canadian, UK, etc. spelling of course can be adjusted.

Rename sRGB EOTF -> sRGB (images)

There are other transforms that end up added into a configuration for wide gamut to properly deal with chromaticities. This naming is on purpose and specifically addresses the transfer curve portion. Transition solved by roles as well.

Maybe add back Linear ACES, Raw, VD16, XYZ (images)

XYZ will be added as a role for Stockner's patch. VD16 is junk from Sony's legacy. ACES is incorrect. Neither belong in the configuration.

Rename sRGB / BT.709 -> sRGB (display)

No. This is a display category regarding colours of primary lights in the displays. The other groupings to be added include DCI-P3, which will also include Apple's DCI-P3.

Rename sRGB EOTF -> Default (view transform)

No. This is going back to the configuration we currently have, and one I am dead set against. Sorting out this mess means getting folks using the right terms and understanding where and what they do.

There is nothing gained muddying up the waters to where they are now.

In D2547#59743, @Troy Sobotka (sobotka) wrote:

This particular issue is the one I spoke of regarding roles. If we implement roles across Blender properly, using the ones enforced by ociocheck, this becomes a non-issue. That is, the data role in Filmic versus the data role in the current would both point to equivalent non-colour transform definitions.

Renaming Non-Color to Non-Colour Data is arbitrary though? By convention we use American English spelling in any case.

If we can get better support for roles in 2.79 I doesn't really matter if it's called Non-Color or Non-Color Data. If we don't get better roles in 2.79, we will need compatible names.

Rename sRGB EOTF -> sRGB (images)

There are other transforms that end up added into a configuration for wide gamut to properly deal with chromaticities. This naming is on purpose and specifically addresses the transfer curve portion. Transition solved by roles as well.

The naming here was intended to refer to the color space of the image file. Not the name of the transform to convert from the reference space to that color space.

Further, if we switch to a wider gamut reference space then the color space of the image stays the same, but the transform will not longer be just the sRGB EOTF, but also include a conversion to sRGB primaries. So then the name doesn't really cover what happens anymore.

XYZ will be added as a role for Stockner's patch. VD16 is junk from Sony's legacy. ACES is incorrect. Neither belong in the configuration.

Ok, I don't think many users care about ACES and VD16 so I don't really care about losing that when switching to filmic.

Rename sRGB / BT.709 -> sRGB (display)

No. This is a display category regarding colours of primary lights in the displays. The other groupings to be added include DCI-P3, which will also include Apple's P3.

I'm not sure why "BT.709" needs to be included, as far as I know sRGB implies BT.709 primaries. Why do users need to know about this?

I'm fine with leaving out Rec709 and XYZ displays spaces, and introducing more appropriate ones with better names.

Rename sRGB EOTF -> Default (view transform)

No. This is going back to the configuration we currently have, and one I am dead set against. Sorting out this mess means getting folks using the right terms and understanding where and what they do.

I think this is referring to the name of the display space where it shouldn't. If the user already indicates that their display is sRGB, there is no need to indicate again that they want to use the sRGB EOTF. What they are indicating is that they want the naive transform without any filmic adaption.

Further if a user e.g. has a secondary monitor with a DCI-P3 display space, both displays will share a view transform, while the second monitor will not use the sRGB EOTF. That's why we kept the view transform names display space agnostic.

If we can get better support for roles in 2.79 I doesn't really matter if it's called Non-Color or Non-Color Data. If we don't get better roles in 2.79, we will need compatible names.

I hope we can get roles in place as it will make all transitions easier for certain. I am also discussing the reference metadata with Sean Cooper, so hopefully we can sort that out soon.

Rename sRGB EOTF -> sRGB (images)
The naming here was intended to refer to the color space of the image file. Not the name of the transform to convert from the reference space to that color space.
Further, if we switch to a wider gamut reference space then the color space of the image stays the same, but the transform will not longer be just the sRGB EOTF, but also include a conversion to sRGB primaries. So then the name doesn't really cover what happens anymore.

Except in the case of BT.709 primaries based files with linear encodings, where the chromaticities component would be required, but not the OETF / EOTF. Hence the division.

There are also going to be times where, with a properly colour managed UI set, where someone may very well need only the EOTF and not the full display referred transform. In this case, having the transform clear for use in curves or such is helpful.

XYZ will be added as a role for Stockner's patch. VD16 is junk from Sony's legacy. ACES is incorrect. Neither belong in the configuration.

Ok, I don't think many users care about ACES and VD16 so I don't really care about losing that when switching to filmic.

Yes. In the case of both ACES and VD16, they are wrong so we are serving a greater good on their removal.

Rename sRGB / BT.709 -> sRGB (display)

No. This is a display category regarding colours of primary lights in the displays. The other groupings to be added include DCI-P3, which will also include Apple's P3.

I'm not sure why "BT.709" needs to be included, as far as I know sRGB implies BT.709 primaries. Why do users need to know about this?

Because the actual colour primaries are taken from BT.709. In this case, it also covers BT.709 broadcast displays with BT.1886.

I'm fine with leaving out Rec709 and XYZ displays spaces, and introducing more appropriate ones with better names.

The transforms for REC.709 OETF will be required, but only on inputs. The proper view for REC.709 is BT.1886.

Rename sRGB EOTF -> Default (view transform)

No. This is going back to the configuration we currently have, and one I am dead set against. Sorting out this mess means getting folks using the right terms and understanding where and what they do.

I think this is referring to the name of the display space where it shouldn't. If the user already indicates that their display is sRGB, there is no need to indicate again that they want to use the sRGB EOTF. What they are indicating is that they want the naive transform without any filmic adaption.

There are many transforms for any given set of primaries. The term sRGB for example, can refer to one of many different components. Clearly labeled transforms hurt no one, and elevate the understanding on the part of the folks using them. This can be already seen with folks using better terminology after having adopted the Filmic transforms.

In this particular case, it is also referring to the actual transform, which is purely the EOTF from sRGB, and not another EOTF.

Further if a user e.g. has a secondary monitor with a DCI-P3 display space, both displays will share a view transform, while the second monitor will not use the sRGB EOTF. That's why we kept the view transform names display space agnostic

This wasn't always the case. When OCIO was originally added, the proper method was per panel for this very reason. Hopefully we can return to this as currently it makes colour accurate views impossible in a dual head scenario. A super simple example of this unfortunate design at the moment is a MacBook Pro 2016+ with an sRGB display. Yikes.

View transforms are never agnostic, so having them clearly labeled is a step in the right direction.

In D2547#59746, @Troy Sobotka (sobotka) wrote:

Except in the case of BT.709 primaries based files with linear encodings, where the chromaticities component would be required, but not the OETF / EOTF. Hence the division.

For this we would use a name like Linear sRGB, Linear BT.709, .. to distinguish from sRGB. The way I understand the design of OpenColorIO is that this is a place where you give the name of a color space, not the name of a transform. I don't think anyone will be confused in thinking that selecting "sRGB" will save linear.

There are also going to be times where, with a properly colour managed UI set, where someone may very well need only the EOTF and not the full display referred transform. In this case, having the transform clear for use in curves or such is helpful.

Not sure if I understand this correctly, but we already have Save as Render and View as Render options to control of the view transform should be used or not. Maybe there needs to be an option to pick a specific view transform. But to me that seems like it should be an option independent of the color space of the image file. Or at least that's how the design has worked so far.

Because the actual colour primaries are taken from BT.709. In this case, it also covers BT.709 broadcast displays with BT.1886.

There are many transforms for any given set of primaries. The term sRGB for example, can refer to one of many different components. Clearly labeled transforms hurt no one, and elevate the understanding on the part of the folks using them. This can be already seen with folks using better terminology after having adopted the Filmic transforms.

In this particular case, it is also referring to the actual transform, which is purely the EOTF from sRGB, and not another EOTF.

This wasn't always the case. When OCIO was originally added, the proper method was per panel for this very reason. Hopefully we can return to this as currently it makes colour accurate views impossible in a dual head scenario. A super simple example of this unfortunate design at the moment is a MacBook Pro 2016+ with an sRGB display. Yikes.

View transforms are never agnostic, so having them clearly labeled is a step in the right direction.

To me it seems like you are interpreting the Display Device and View Transform settings quite different than they were intended in the original design. Which might be better in some ways, but it does raise a lot of questions for me, and makes for an odd fit when we have two configs with different interpretations of what the settings do.

I'm all for making Display Device a per window settings, but you seem to be suggesting that View Transform should also be per window then?

Right now we try to separate between the particular display used with Display Device, and the artistic choices in a specific scene with View Transform. If the view transform is not display device agnostic, then e.g. whether or not a filmic or naive view transform is used can vary depending if you open the .blend on your laptop or desktop computer, or which of the two monitors you are viewing it on.

Saving renders to disk as .jpg files currently uses the scene view transform. If this becomes dependent on the display device, it seems we will need a separate view transform for file saving, which adds more steps for users and more ways to misconfigure things.

For this we would use a name like Linear sRGB, Linear BT.709, .. to distinguish from sRGB. The way I understand the design of OpenColorIO is that this is a place where you give the name of a color space, not the name of a transform. I don't think anyone will be confused in thinking that selecting "sRGB" will save linear.

At which point we are effectively making up terms for the sake of doing so. Likely wiser to just leave the terms as they are.

The EOTF is a term, as you can see from BT.1886 which is a view transform designed for any set of primaries under a BT.709 OETF, for example.

Views are merely aggregate collections of view transforms under the singular banner of a display cluster.

There are also going to be times where, with a properly colour managed UI set, where someone may very well need only the EOTF and not the full display referred transform. In this case, having the transform clear for use in curves or such is helpful.

Not sure if I understand this correctly, but we already have Save as Render and View as Render options to control of the view transform should be used or not. Maybe there needs to be an option to pick a specific view transform. But to me that seems like it should be an option independent of the color space of the image file. Or at least that's how the design has worked so far.

Baking transforms is a pretty complex beast for certain. In an ideal world, one would be able to stack the transforms as required. For example, a base View plus a look, or a series of looks designed to work together.

For now, it is fine, and the Views behave perfectly acceptably with the exception being EXRs. Those are going to be a headache in the future with a wider gamut reference.

To me it seems like you are interpreting the Display Device and View Transform settings quite different than they were intended in the original design. Which might be better in some ways, but it does raise a lot of questions for me, and makes for an odd fit when we have two configs with different interpretations of what the settings do.

Not sure the current config is worthy of comparing in terms of where a more forward looking config might end up.

Displays are groupings of views based on the colorimetry of the display type. Views are simply transforms based under those primaries.

I'm all for making Display Device a per window settings, but you seem to be suggesting that View Transform should also be per window then?

Not sure what you mean here, but for example, it is very useful to have a base log view and a False Colour, or a log view and a look view with a simple grade. Having two views simultaneously is hugely useful.

In terms of dual head or optional outputs, those may very well be different display devices. Even in the case of same primaries on two different display devices, you may have different corrections per display.

Does that make sense?

Right now we try to separate between the particular display used with Display Device, and the artistic choices in a specific scene with View Transform. If the view transform is not display device agnostic, then e.g. whether or not a filmic or naive view transform is used can vary depending if you open the .blend on your laptop or desktop computer, or which of the two monitors you are viewing it on.

Corrections could very well find themselves in a simple view transform. They could also be tacked onto the end of a look. Would depend on context I would think.

Saving renders to disk as .jpg files currently uses the scene view transform. If this becomes dependent on the display device, it seems we will need a separate view transform for file saving, which adds more steps for users and more ways to misconfigure things.

It sure does. That said, consider the case where we have a wide gamut reference space such as REC.2020 or AP0. If you want to save as an EXR with BT.709 primaries, how are we going to accomplish that gracefully?

Even in the extremely simple case of a MacBook Pro DCI-P3 display and a generic BT.709 display we already have an issue.

Sorry... I don't have any clear solutions at this point other than to start ironing out the glaring problems I can see in the not-too-distant future.

So let's see:

• Baking transforms is clearly going to be an issue moving forward. A transform stack with some sane defaults never-to-be-seen unless someone hits "Advanced..." perhaps could work.
• Per panel View / Looks are likely required. From multi-head to creative use.

In D2547#59748, @Troy Sobotka (sobotka) wrote:

At which point we are effectively making up terms for the sake of doing so. Likely wiser to just leave the terms as they are.

But that's kind of my point, calling it just "sRGB" is entirely standard in 3D software and accurately describes the color space. Adding EOTF in the name is not making it more accurate, nor does it solve the problem that you still need to find names for the linear color spaces.

Not sure what you mean here, but for example, it is very useful to have a base log view and a False Colour, or a log view and a look view with a simple grade. Having two views simultaneously is hugely useful.

Viewing something like false color fits more as an option like viewing individual R/G/B/A channels, per image editor, not per monitor.

In terms of dual head or optional outputs, those may very well be different display devices. Even in the case of same primaries on two different display devices, you may have different corrections per display.

For users I think having these things decoupled matters:

• Per monitor / window display space
• Per scene view transform for the render output
• Per scene or per image editor view transform for inspecting, like false color

I would argue that using the same per scene view render output transform for all monitors is sufficient (with a per image editor option to override it). What I mean by the same is not that they use exactly the same LUT, but the same choice between "default", "filmic", "ACES RRT", .. which would be available for all display spaces and gives a similar result on each.

A small minority might want do color grading separately for e.g. output to the web and film, with possibly a different view transform. In that case they will likely need a new scene with its own compositing nodes, and then one view transform per scene is fine too.

All of this fits as an extension of the existing design.

It sure does. That said, consider the case where we have a wide gamut reference space such as REC.2020 or AP0. If you want to save as an EXR with BT.709 primaries, how are we going to accomplish that gracefully?

For that we could have an image color space named Linear sRGB or Linear BT.709.

But that's kind of my point, calling it just "sRGB" is entirely standard in 3D software and accurately describes the color space.

We would probably need to agree that most software is entirely acceptable with their colour handling in 2017. I wouldn't say it is, but that is coming from someone under the weight of a thousand emails asking for help sorting out the colour pipes in several wonderful applications.

Take a peek at the official ACES configs and you will get a pretty good idea of a very nicely laid out set of transforms and views that work within the ACES structure.

It isn't that I am against the idea of a proper sRGB transform. It is more that in 2017 media creation, it simply isn't granular enough. Hard for me to demonstrate when we still have miles to go tightening the bolts on the low hanging fruit.

Adding EOTF in the name is not making it more accurate, nor does it solve the problem that you still need to find names for the linear color spaces.

In *this* case, the EOTF specifically identifies the transfer function, which is what it happens to be doing. It is relevant again as the actual transform and the view are applying precisely that.

When I flip over to the wide gamut, the EOTF for the view transform would change to what it identifies, as well as remain as a transform for curves, colour pickers, gradients, etc.

Viewing something like false color fits more as an option like viewing individual R/G/B/A channels, per image editor, not per monitor.

It is a unique view anchored in a very specific set of transforms. It is in many ways no different than the log view.

For users I think having these things decoupled matters:

• Per monitor / window display space
• Per scene view transform for the render output
• Per scene or per image editor view transform for inspecting, like false color

Agree entirely. I would add in Looks to the chain for decoupled ideas.

Full decoupling is almost mandatory for file output anyways. Having a section for each transform is unwieldy, and a transform chain stack like the materials stack could work wonders here. Sane defaults based on roles for those that don't touch them.

I would argue that using the same per scene view render output transform for all monitors is sufficient (with a per image editor option to override it).

If you are grading and you have a dual head setup with profiled monitors this fails. If you have a MacBook Pro 2016 and a BT.709 display this fails. It can't work as far as I can tell, but perhaps you can see something I can't.

What I mean by the same is not that they use exactly the same LUT, but the same choice between "default", "filmic", "ACES RRT", .. which would be available for all display spaces and gives a similar result on each.

Again, displays are anchored on chromaticities typically. Varying chromaticity outputs would break this scheme.

Easier to simply let the "display" type do exactly what it describes; select a display type. Per screen as required.

A small minority might want do color grading separately for e.g. output to the web and film, with possibly a different view transform. In that case they will likely need a new scene with its own compositing nodes, and then one view transform per scene is fine too.

This is godawful if I am understanding it correctly, which is not likely given my tendency to stupidity. Different views and flipping should be quite common. I'm not quite entirely understanding your divisions though here perhaps.

All of this fits as an extension of the existing design.

Some of it does. Some of the existing design is also about as far away from design as one could suggest and isn't exactly something to forge ahead with.

For that we could have an image color space named Linear sRGB or Linear BT.709.

Except good old EXRs don't permit transforms within the current design.

In D2547#59754, @Troy Sobotka (sobotka) wrote:

In *this* case, the EOTF specifically identifies the transfer function, which is what it happens to be doing. It is relevant again as the actual transform and the view are applying precisely that.

When I flip over to the wide gamut, the EOTF for the view transform would change to what it identifies, as well as remain as a transform for curves, colour pickers, gradients, etc.

The image setting here is not a transform, it is the color space of the image file on disk. If there are multiple ways to transform to/from that color space, that should be a separate setting.

When we add wide gamut and the reference space changes, what would happen with PNG textures that have color space "sRGB EOTF"? If I understand correctly they would only get the sRGB EOTF for conversion, and the chromatiticities would be wrong. If instead they have an "sRGB" color space that includes both the sRGB EOTF and the conversion to the right chromaticities, renders will continue to look correct.

I can see how just an sRGB EOTF could be useful for curves for example, but not as an image color space.

It is a unique view anchored in a very specific set of transforms. It is in many ways no different than the log view.

I'm not sure what "anchored" means here. But if we have a false color or log view transform, then they can be available for all display devices we support. In the OCIO config it might be tightly coupled, but from the user point of view it should not be.

Agree entirely. I would add in Looks to the chain for decoupled ideas.

Yes looks are another one.

But this is what I don't understand. The filmic config breaks the decoupling we have in place, by having "sRGB EOTF" and "BT.1886 EOTF" view transforms which only make sense for specific display devices, not for all. What I mean by decoupling is that all the options listed in View Transform should be available and make sense for all Display Device options, so that users can pick them independently.

If you are grading and you have a dual head setup with profiled monitors this fails. If you have a MacBook Pro 2016 and a BT.709 display this fails. It can't work as far as I can tell, but perhaps you can see something I can't.

I don't see the problem with selecting e.g. "Filmic" as the View Transform for a scene, and then having a different Display Device for each monitor. When would you select e.g. "Filmic" for one monitor and "RRT" for another?

For temporary viewing in an image editor I can understand it. But to me it seems 99% of the time the scene level view transform should be shared for all displays, so at least by default the user should not have to deal with a separate view transform for displays and file saving.

Except good old EXRs don't permit transforms within the current design.

EXRs are required to have a linear color space, and we can do conversions between the reference space and other linear spaces for reading/writing EXR files. I don't see the problem there, they can work like other image files but with fewer valid color spaces.

The image setting here is not a transform, it is the color space of the image file on disk. If there are multiple ways to transform to/from that color space, that should be a separate setting.

We can disagree here. You can't avoid the labelling. See below.

When we add wide gamut and the reference space changes, what would happen with PNG textures that have color space "sRGB EOTF"? If I understand correctly they would only get the sRGB EOTF for conversion, and the chromatiticities would be wrong. If instead they have an "sRGB" color space that includes both the sRGB EOTF and the conversion to the right chromaticities, renders will continue to look correct.

Correct. Which is why you have to identify the proper transforms when you have the need.

The difference is that from an OCIO standpoint, they are just transforms. So either you properly label them or you just ram all the same terminology under a huge banner of sRGB, which is precisely what got us here in the first place.

So you end up needing, yes... Wait for it... The sRGB EOTF (under a curves family for example) and an sRGB Colorspace or such. Now if you want to discuss coding up some sorting to the transforms based on Family, I am all for it. ;)

I have worked through the labelling and ordering for a few years now, and open to errors in the conventions. It is really great that a huge smattering of folks are starting to think about these things *now*.

I can see how just an sRGB EOTF could be useful for curves for example, but not as an image color space.

Right. And how / where does it appear when you load up various OCIO configs? ;)

It is a unique view anchored in a very specific set of transforms. It is in many ways no different than the log view.

I'm not sure what "anchored" means here. But if we have a false color or log view transform, then they can be available for all display devices we support. In the OCIO config it might be tightly coupled, but from the user point of view it should not be.

This thread came from the your suggestion that it belongs like one of the RGBA view toggles. I disagreed because it doesn't. It should be read in context. That is, False Colours are *tightly coupled* to the reference space and view decisions in use, as well as variant in use.

But this is what I don't understand. The filmic config breaks the decoupling we have in place,

The "decoupling" or desire to is what makes the current configuration an absolute nightmare. Take VD16 or the RRT. Botched because they are based on different assumptions about the reference. It is broken logic, not decoupling.

by having "sRGB EOTF" and "BT.1886 EOTF" view transforms which only make sense for specific display devices, not for all. What I mean by decoupling is that all the options listed in View Transform should be available and make sense for all Display Device options, so that users can pick them independently.

The sRGB EOTF and the BT.1886 EOTF are of course required if you are going to be forced to have mixed content etc. Also, IIRC from early testing, some things in Blender go completely batshit when you have anything *but* the sRGB EOTF in as the first default. Texture painting was one such area IIRC.

The terminology was added because it is A) correct within the context and B) clearly labels the precise change between the views. That is, Filmic is close to being "just another transfer function" contrasted against the sRGB transfer function. It was intended to be educational as much as descriptive.

That said, even if it didn't, you would need those transforms there for folks to be able to use cheated albedos and such from display referred imagery.

Also, regarding "not for all" I am unsure of your phrase here. It applies to display referred content on BT.709 and REC.2020, which loosely covers two different display types. They haven't been stuffed into areas where they don't belong.

So, the mythical "decoupling" is what happens when you ram transforms that don't belong together into the same set. That isn't decoupling. We can talk about decoupling transforms, but the amount of surgery required to really pull it off is deep.

If you are grading and you have a dual head setup with profiled monitors this fails. If you have a MacBook Pro 2016 and a BT.709 display this fails. It can't work as far as I can tell, but perhaps you can see something I can't.

I don't see the problem with selecting e.g. "Filmic" as the View Transform for a scene, and then having a different Display Device for each monitor. When would you select e.g. "Filmic" for one monitor and "RRT" for another?

Your order is backwards. Views are a subset of Displays.

Anyways, a super simple example is dual head where one display is HDR and the other isn't. Both would be under the same display type (REC.2020) while the transfer functions would be different.

Sure we could enforce this cooky hierarchy, but then when a smaller studio or pipeline decides to use ACES or an alternate configuration, everything goes sideways.

For temporary viewing in an image editor I can understand it. But to me it seems 99% of the time the scene level view transform should be shared for all displays, so at least by default the user should not have to deal with a separate view transform for displays and file saving.

Again, see above. Given that OCIO doesn't enforce correction / transfer curve positions etc., they may end up anywhere including on the base view transforms.

Except good old EXRs don't permit transforms within the current design.

EXRs are required to have a linear color space, and we can do conversions between the reference space and other linear spaces for reading/writing EXR files. I don't see the problem there, they can work like other image files but with fewer valid color spaces.

I don't see the problem there either but someone did.

Anyways, in terms of extremely short term critical things now having wandered through these labyrinth like pathways:

• OCIO node. This would literally solve nearly every broken bit overnight via a workaround where no such design exists.
• Fix Cycles. This is sort of darn important in this discussion and puts Stockner's Cycles patch front and center.
• Begin picking away at the few remaining pinch points in the UI. See curves, colour managed pickers, colour ramps, etc.

I think the OpenColorIO design and existing implementations and configurations are clear, color spaces and transforms are not the same thing. Being able to specify an absolute color space rather than a transform relative to some other color space is critical for making exchanging of image files between applications work.

This is the interpretation I see in other OCIO configurations, I don't understand why filmic needs to deviate from that and start interpreting color spaces as if they were transforms. It means using terminology inconsistent with other applications and makes compatibility between Blender versions and other applications harder.

I understand the hierarchy of displays and view transforms, and the implementation must take that into account when loading other configurations and allow setting a separate view transform for each display used. But for Blender's default OCIO configuration, we should make switching between displays as painless as possible, which means making their view transforms as consistent as possible.

I know there's a coupling here in the underlying system, and I think that's one of the weaknesses of the OCIO being originally aimed at use in production studios where the entire pipeline is under control and the configuration can be geared to that. But for most of our users it's poor UI design and we should smooth over it where we can.

In D2547#59759, @Brecht Van Lommel (brecht) wrote:

I think the OpenColorIO design and existing implementations and configurations are clear, color spaces and transforms are not the same thing. Being able to specify an absolute color space rather than a transform relative to some other color space is critical for making exchanging of image files between applications work.

What part of Filmic doesn't do this exactly? Seriously, it is essentially modeled after the ACES set, and growing along the same lines.

The "absolute" color space you are concerned about is already there. You are seemingly trying to explain this to someone that has a pretty good grasp of OCIO and how it is used.

So please, go back and read the reasoning. I am confident that you will eventually see why the terms are laid out as such. With that said, as things move forwards, further transforms will be added.

This is the interpretation I see in other OCIO configurations,

Look at ACES. There is no way you have looked at it and will make that statement. Nuke is a no-go as it is essentially a lowest common denominator and is a decrepit beast, largely because no house is using the default and no one cares.

I don't understand why filmic needs to deviate from that and start interpreting color spaces as if they were transforms. It means using terminology inconsistent with other applications and makes compatibility between Blender versions and other applications harder.

Terminology is deadly accurate. If you have a problem with that, I can't help you.

Terminology consistent with other applications... Like "Default" for a view. Yes. Sounds pretty consistent. Or RRT. Or VD16. C'mon...

I understand the hierarchy of displays and view transforms, and the implementation must take that into account when loading other configurations and allow setting a separate view transform for each display used. But for Blender's default OCIO configuration, we should make switching between displays as painless as possible, which means making their view transforms as consistent as possible.

Go nuts. Keep the rubbish then. Just don't use Filmic. Solved.

I know there's a coupling here in the underlying system, and I think that's one of the weaknesses of the OCIO being originally aimed at use in production studios where the entire pipeline is under control and the configuration can be geared to that. But for most of our users it's poor UI design and we should smooth over it where we can.

Go nuts. Have fun.

As someone that can speak from a position of experience at this point, I don't see folks confused or lost or otherwise. I see folks using the proper terms now, with proper implications understood.

If you are hell bent on keeping things along status quo, no one is stopping you. Go ahead. Make up some configuration and keep it littered with the corpses of dead shit. I am not going to stop you or care.

If you want to move forward in a sane way, then I'm happy to talk about it. What you are proposing though is simply more of the same crap madness and that bores me.

I think the filmic transform is very important. I have looked into the ACES config in detail and I believe what I am proposing is consistent with it, but maybe I'm misunderstanding it then.

If we look at the "Utility - sRGB - Texture" color space in the ACES config, it converts from a wide gamut reference space to linear sRGB with a matrix transform, and then to sRGB with the sRGB EOTF. What I'm proposing is that we do the same for image textures when we adopt wide gamut. If the intention for filmic with wide gamut is to do the same as ACES here, that's fine with me.

This color space name also does not contain "EOTF", but that's more of a detail and I don't care too much about that, it's the same behavior of the color space that matters most. The tricky thing about the naming is that it affects compatibility, and if we do change image texture color spaces names we need to change the existing configuration to match, so that it is possible to switch between filmic without breaking textures. Backwards compatibility for that can be solved with versioning code though.

The ACES configs doesn't really have a display device and view transform distinction. It can be setup to either use multiple displays with one view transform for each, or one display with multiple view transforms. For applications like Maya that don't support view transforms, the multiple displays configuration is used. That same config would work in Blender if only the displace device settings is different between monitors, since there is only one view transform per display anyway.

I'm not sure if there's an other OCIO config that you have in mind for this part, my interpretation of display device and view transform distinction is mostly based on the SPI OCIO configs, which have two displays (sRGB and DCIP3) with the same 3 view transforms each (Film, Log, Raw).

In D2547#59799, @Brecht Van Lommel (brecht) wrote:

I think the filmic transform is very important. I have looked into the ACES config in detail and I believe what I am proposing is consistent with it, but maybe I'm misunderstanding it then.

If we look at the "Utility - sRGB - Texture" color space in the ACES config, it converts from a wide gamut reference space to linear sRGB with a matrix transform, and then to sRGB with the sRGB EOTF. What I'm proposing is that we do the same for image textures when we adopt wide gamut. If the intention for filmic with wide gamut is to do the same as ACES here, that's fine with me.

Yes. That is absolutely the intention. We pay a cost on the number of clearly labeled transforms however.

Remember that currently Filmic was designed to get everyone on the learning path. That means that it was designed to peel apart all of the bulk "sRGB" misuse and get folks thinking about the transforms.

Case in point, if we stick to a "Where it is going" type of thinking, we would actually be naming "Filmic with Contrast" combinations to "Power 2.2 with BT.709 primaries", as that is that is in fact how you tag the output images with an ICC for it to display 1:1 under Filmic. Or, with another tweak, it would in fact be called "sRGB" as you would tag it with the sRGB ICC profile.

So the idea is to grow the configuration slowly enough, with enough limited choices, that folks are willing to A) use it, and B) ask the right questions and learn what the EOTF is. This is also extremely important if Blender ends up adopting colour managed UI elements, as we need to have the folks choosing the proper selection of curves for their chosen need. Moving forward, the definition under the wide gamut primaries for example, would be more closely aligned with ACES, including potential variant versions where applicable. This latter example would include REC.2020 outputs for example, where we would have both HDR10, as well as BT.1886.

While a seemingly minor detail, there are extremely far reaching implications.

This color space name also does not contain "EOTF", but that's more of a detail and I don't care too much about that, it's the same behavior of the color space that matters most.

Because the actual ODT for sRGB is in fact via the target to be combined with the Display Device currently. Moving forwards, this would evolve to properly describe the destination transform / output.

HPD put all of the view transforms under the same banner as it is an ACES config. It was a purposeful decision to avoid the large clumping knowing that results, by keeping the choices manageable per display device. I also actually believe it is more logically consistent, as well as being one of the methods discussed for OCIO to provide display device metadata information.

The tricky thing about the naming is that it affects compatibility, and if we do change image texture color spaces names we need to change the existing configuration to match, so that it is possible to switch between filmic without breaking textures. Backwards compatibility for that can be solved with versioning code though.

No. Not in a properly implemented system. The proper method, and one I am hoping we move forward with, is to use the role enforced by ociocheck. If Blender hunts for the role "data" for example, it always finds the correct data role for a particular configuration, assuming it has passed ociocheck. That will almost always be of the is_data = true transform type. Those roles prevent the hard coded elements to rely on hard coded expected roles.

In theory, this would also allow for a seamless shift from using Filmic to ACES, or future ACES or another configuration altogether.

The ACES configs doesn't really have a display device and view transform distinction. It can be setup to either use multiple displays with one view transform for each, or one display with multiple view transforms. For applications like Maya that don't support view transforms, the multiple displays configuration is used. That same config would work in Blender if only the displace device settings is different between monitors, since there is only one view transform per display anyway.

See above. There was also a logic to HPD's decision. I believe that his decision however, is entirely unfit for the folks that are being exposed to these concepts for the first time.

As a result, Filmic chose a bit of a middle ground with the existing granularity from the current configuration and how ACES formats the views in the 1.0.3 variant. There are also some tweaks in the generation of ACES that can change labelling and such based on how an application sorts and presents transforms. It is a bit of an unwieldy mess at the moment in many applications.

I'm not sure if there's an other OCIO config that you have in mind for this part, my interpretation of display device and view transform distinction is mostly based on the SPI OCIO configs, which have two displays (sRGB and DCIP3) with the same 3 view transforms each (Film, Log, Raw).

SPI's configs are *extremely* old. Even within Filmic, there have been some discussions to put an optional "all views + looks" configuration for some applications that don't support looks.

It is essentially close to the ACES transforms in spirit, with the added clustering under display devices which is solely determined by chromaticities of the display type primaries. There are some tricky nuances in there for things like Apple's DCI-P3 variant for example, but it short term holds up semantically.

The idea of education is quite real. One can look to the spread of Filmic's core concepts to Blender Stack Exchange and even BlenderArtists as an example of a core culture managing to help each other out. I firmly believe it was helped by clear terminology that is Googleable. Without that core group of people growing the support base, it would have resulted in a sole point of failure, and failure of Filmic.

Using that experience, it would seem prudent to carry education / conceptual education forward to avoid and alleviate the pressures on a poor fistful of developers. Blog posts and such discussing matters would even be of a tremendous help here.

Ok, I think we have really different ideas about UI design here, I don't think we're going to agree about what the best solution is. I strongly prefer names that indicate purpose rather than implementation, orthogonality of functionality whenever reasonably possible, and find image texture color space compatibility between .blend files created with different configs to be absolutely required.

Other developers will have to weigh in to make a decision here.

Also, a technical detail, which license are you releasing the filmic configuration under? It needs to be GPL compatible to be included with Blender, so that means something like GPL like most of Blender, Apache, BSD, public domain, ..

In D2547#59836, @Brecht Van Lommel (brecht) wrote:

Ok, I think we have really different ideas about UI design here, I don't think we're going to agree about what the best solution is. I strongly prefer names that indicate purpose rather than implementation, orthogonality of functionality whenever reasonably possible,

Think that through.

If we strictly think about your description here, literally every single transform under the views for Filmic would be "2.2 BT.709", as that is the actual purpose of each transform.

and find image texture color space compatibility between .blend files created with different configs to be absolutely required.

You are ignoring my point about roles.

Also, a technical detail, which license are you releasing the filmic configuration under? It needs to be GPL compatible to be included with Blender, so that means something like GPL like most of Blender, Apache, BSD, public domain, ..

It's numbers. I'm hoping that one can't copyright numbers, but who knows in the modern era.

In D2547#59842, @Troy Sobotka (sobotka) wrote:

Think that through.

If we strictly think about your description here, literally every single transform under the views for Filmic would be "2.2 BT.709, as that is the actual purpose of each transform.

What I mean by purpose over implementation is :

• I want to display the render on my monitor, which uses color space X
• I want to correctly read the image texture file, which has color space Y
• Render output is intended for television standard Z
• The render should have a filmic look with smart adaption
• The render should not use any smart adaption

I'm not talking about the purpose of the transform, but about what the user wants to achieve.

It's numbers. I'm hoping that one can't copyright numbers, but who knows in the modern era.

I'm not a lawyer, but if the GitHub repo explicitly says it's in the public domain, that should avoid any possible confusion.

In D2547#59842, @Troy Sobotka (sobotka) wrote:

You are ignoring my point about roles.

All I'm saying is that rendering an asset created with a different config should work whenever possible. If we achieve that compatibility with roles, fine. I'm not sure that they do since I don't think we'd have a role for every possible image color space? For documentation and tutorial however, it would be best if all the configs used the same naming.