Use of OCIO maker config removes AgX output transform in Blender 4.1/4.2

[marklio]

If I set OCIO env var to an OCIO maker config, the AgX view transform will not be present as an available output transform. Presumably, this is because the base is a Blender 3 config. I tried loading the 4.x config, but OCIO maker errors with "1: ERROR: Failed to load configuration: is not an ETF OCIO Maker-generated config."

Is there a workaround? I'd be happy to fix it with some guidance on what needs to happen.

[cessen]

As mentioned in https://github.com/EatTheFuture/image_tools/discussions/15, Blender's AgX variant first needs to be recreated in OCIO Maker before this can happen.

I've made some good progress on that in agx.rs already, but it doesn't match exactly yet.

Another approach would be to simply bundle the same LUTs that are used in Blender, but I don't really want to do that because (1) I already did that with Filmic, which bloated OCIO Maker's size more than I wanted, and (2) the AgX LUTs are significantly larger than Filmic's so they would bloat it even more. I'm also just really hesitant to include any more transforms in OCIO Maker that can't be properly reproduced.

Having said that, if all you want is a good approximation of Blender's AgX, you can already get that by using the Custom configuration base rather than Blender 3.0. Custom currently includes the transform from agx.rs linked above. However, keep in mind that the Custom configuration base doesn't make any attempt whatsoever to be compatible with other aspects of Blender's default OCIO config. It's just its own thing. It should also be considered experimental, and may change in backwards-incompatible ways in the future.

(You can also play with the Toney tonemapper in the Custom config if you want. For example, Toney (Filmic) is very similar to Blender's variant of AgX.)

[marklio]

Thanks. Sorry, I completely missed the discussion in #15 somehow. I've been crash coursing the OCIO config and Rust to get a handle on this. The functionality I (and I think others based on the question in #15) were expecting is something like "Add my cameras' color spaces to Blender", so it was surprising that anything else changed. I'm looking for portability of .blend files, and this color management stuff seems to preclude that as an option, which is also surprising.

Just so you don't misunderstand, let me reiterate how freaking awesome these tools are. Thanks for building them!

I thought maybe I could get what I wanted by just adding the colorspace entries that OCIO Maker creates to Blender's ocio config (and copying the LUTs over), but this doesn't seem to produce anything similar, and I don't yet understand why. Any pointers to why the same color space entry would produce different results would be hugely appreciated.

[cessen]

The functionality I (and I think others based on the question in https://github.com/EatTheFuture/image_tools/discussions/15) were expecting is something like "Add my cameras' color spaces to Blender", so it was surprising that anything else changed.

Yeah, and to be fair that's not an accident. That is the experience I want people to have. It's just that providing that requires reproducing Blender's config in OCIO Maker first. I did that for Blender 3.x, but not yet for Blender 4.x. I'll up the priority on that.

I thought maybe I could get what I wanted by just adding the colorspace entries that OCIO Maker creates to Blender's ocio config (and copying the LUTs over), but this doesn't seem to produce anything similar, and I don't yet understand why.

OCIO configs aren't easy to wrap your head around (and the format is also poorly documented). So they're not easy to write/modify by hand. That's another reason for making OCIO Maker in the first place: to put that within reach of normal people.

In any case, I don't know for sure why that didn't work in your case, but my suspicion is that it's because in Blender 4.0 they changed the reference color space for their config. The reference space is the space that all other color spaces in the config use as an intermediate to convert between each other, and it's assumed that each color space's transforms are converting to/from that space.

Oh, also, I forgot to respond to this:

I tried loading the 4.x config, but OCIO maker errors with "1: ERROR: Failed to load configuration: is not an ETF OCIO Maker-generated config."

That's because OCIO Maker doesn't handle arbitrary OCIO configs.

OCIO configs are extremely flexible in a lot of ways (though very inflexible in others), and trying to support everything that an OCIO config could possibly represent would make OCIO Maker's UI just as complex and convoluted as OCIO configs are in the first place. So instead, OCIO Maker supports a specific, very structured subset of what OCIO can more generally do, and which in practice supports most of what people want to do anyway.

[marklio]

Is it simply not feasible to take the existing Blender config and have a strictly additive operation to add the colorspaces? Like don't treat the OCIO config as the persistence medium for the setup, but rather some more strict OCIO maker config, and then an operation that adds color spaces to the blender OCIO config and producing a disposable config as output. It doesn't seem practical for you to have to invest significant time in the tool to absorb changes for any theoretical future Blender release.

In this alternative model, it seems like the work would be to determine the "reference color space" for a given Blender release and augment the LUTs produced by lutmaker to produce correct colors in that reference color space. That seems like much less work than the complexity of reproducing the representation of the new configs. If I can understand how to produce a working colorspace entry for a blender 4.x config, I might take a stab at prototyping an approach, but you have an enormous head start on understanding OCIO and colorspaces in general :)

[marklio]

(thanks for taking the time to give the explanations above, BTW. All makes total sense.)

[cessen]

I started work on the Blender 4.x config before leaving on vacation. And basically everything is working except AgX. I'll continue work on it after I get back.

Is it simply not feasible to take the existing Blender config and have a strictly additive operation to add the colorspaces?

I think that indeed might be feasible (though a little awkward) for configs that specify their relationship to either ACES2065-1 or CIE XYZ (which Blender's config does). And it's something I could look into in the future.

However, ultimately the intention of OCIO Maker (although it's not there yet) is to make fully custom configs, rather than modify existing ones. I realize that may seem a little at odds with what I said about the experience I want people to have with the Blender base configs, but that's kind of specific to Blender: most software doesn't have a default OCIO config that they expect their users to use.

[marklio]

most software doesn't have a default OCIO config that they expect their users to use.

I agree that this seems to be at the heart of this.