Feature request: One click ACES scene conversion button please

[^Lele^]

You're paying the price for using OSL, ACEScg has nothing to do with the slowdown.

[^Lele^]

1 - Rendering in ACEScg is by definition harder to compute, in our tests it takes from 10-20-30% longer, depending on the scene (but not 400%).
2 - We recommend the default one or if you have OCIO config setup the first option. Please send us a scene that you are having issues with so that we can recommend a solution.
3 - We use standard OSL maps for the material conversion and sometimes V-Ray will crash, any complex shader can crash any renderer. Nothing that we can do about, we log a few bug reports: 1, 2
4 - We apply only one lookup table layer to convert from ACEScg to sRGB color space the final image. You should turn off/delete any other previous color correction layers as they behave differently in ACEScg.

ACESsg is a much better color space to work with, from the test renders to the post production.
We build AColorManager for us and the artists so that we can focus on creating better images without wasting time on technical setups or configs.

I would say this post is an exercise in contradiction.
You wish there were no technical setups or configs to deal with, when in fact -and by your own admission- you are forced to forgo a number of features, and move around a number of others, to accomodate the wider gamut.
Free to do so, of course, along with developing your own pipeline and LnR toolset around it, but this is also why i don't feel we should be shouting about it from the rooftops, much less so as a one-click solution.

It's supported, it's as simple and adaptive as we can make it right now (some things may or may not improve in the future, depending on how various DCCs go about it, along with the growth of the ACES standards.), i'd call our job done as it's *not* a necessary feature to get good renders out.

Once again, it's just my take on this, at the present: devs (and users.) may and likely will disagree.

[Muhammed_Hamed]

1 - Rendering in ACEScg is by definition harder to compute, in our tests it takes from 10-20-30% longer, depending on the scene (but not 400%).

This shouldn't happen, you are doing something wrong
Don't use OSL for converting bitmaps to ACES, the V-Ray Bitmap is faster at this, the conversions are part of V-Ray's core and doesn't require OCIO configuration

[Muhammed_Hamed]

I think automatically converting scenes/assets to ACES should possible, V-Ray for SketchUp has a workflow planned on adapting ACEScg for rendering. If there is time tomorrow I will make a video on this

[^Lele^]

Oh, SU has ACES color pickers?

[Muhammed_Hamed]

They use the same color picker as the Frame buffer I think. Better than Max's native(shows the linear float values at least), this picker will be adjusted further, they are putting effort to this direction as part of their V6 planning, and some internal discussions. The workflow will be fully automated with no user control, just a checkbox in render settings.
I guess the fact that all V-Ray editors in SketchUp are our own, so it easier to decide how we go about ACES. Unlike Maya, where we adapt to Maya's native color management, or Max that lacks any native color management/color picking.

[atanasbak]

Don't use OSL for converting bitmaps to ACES, the V-Ray Bitmap is faster at this, the conversions are part of V-Ray's core and doesn't require OCIO configuration

Yes of course V-Ray Bitmap is faster, but it's not universal solution to convert old sRGB material. If you have:

sRGB Bitmap -> Color Correction -> Diffuse slot of V-Ray material

and you convert it to:

ACEScg V-Ray Bitmap-> Color Correction -> Diffuse slot of V-Ray material

then the color correction now is performed in different wider color space and it's not the same as the original.

With our script we have:

sRGB Bitmap -> Color Correction -> sRGB to ACEScg OSL map -> Diffuse slot of V-Ray material

where the correction is applied as in the original in sRGB color space and then the result is converted to ACEScg. Not only that but with the OSL map you have the option to blend between both color spaces (if you want to simulate more vivid colors).

With out tool you can select OCIO map, with conversion part of V-Ray's core and have this setup:

sRGB Bitmap -> Color Correction -> V-Ray OCIO map -> Diffuse slot of V-Ray material

but in this solution you can not mix sRGB and ACEScg color spaces easily.

This is the logical solution for me.

[Muhammed_Hamed]

and you convert it to:

ACEScg V-Ray Bitmap-> Color Correction -> Diffuse slot of V-Ray material

then the color correction now is performed in different wider color space and it's not the same as the original.

It will never be the same whether you convert before or after the Color correction. Your decision to do it this way is an artistic one

Some mathematical operations because of the nature of linear algebra and matrices are dependent on the given RGB colourspace primaries, i.e., on the colourspaces basis. The same operations performed in different RGB colourspace will yield different tristimulus values once converted back to CIE XYZ color space. For example multiplication, division and power operations are RGB colourspace primaries dependent while addition and subtraction are not

Not only that but with the OSL map you have the option to blend between both color spaces (if you want to simulate more vivid colors).

An artistic decision as well, this doesn't give you access to more vivid or saturated colors. This is mostly about the display device now

This is the logical solution for me.

Fair enough, the performance hit in this case is on OSL, not on ACES as you put it above
What about a V-Ray material, with no maps in diffuse something like a fully saturated flat red color picked by an artist. Does this red get converted to ACEScg?

[atanasbak]

I would say this post is an exercise in contradiction.

I'm not as good with the words as you are .
Do you care to test a simple scene and compare the result?

[atanasbak]

1 - It will never be the same whether you convert before or after the Color correction. Your decision to do it this way is an artistic one
2 - What about a V-Ray material, with no maps in diffuse something like a fully saturated flat red color picked by an artist. Does this red get converted to ACEScg?

1 - I disagree, the conversion of the colors of the textures will be exactly the same, as if you bake the texture and load in V-Ray Bitmap
2 - We convert these color with the OSL map or V-Ray color map, it will be pointless to convert old scene with sRGB red as diffuse color and render the plane 255 0 0 color in ACEScg.

[Muhammed_Hamed]

1 - I disagree, the conversion of the colors of the textures will be exactly the same, as if you bake the texture and load in V-Ray Bitmap

If you bake the color correction to your diffuse map, load it in V-Ray bitmap with RGB Primaries = sRGB. You are telling V-Ray to perform a gamut conversion from Linear sRGB to Linear ACEScg, your bitmap is gonna look different in ACEScg. You are not getting the same feel or saturation you set when you color corrected the map..say if this is a skin tone, it will look different.
You are not getting access to more saturated colors either, the Output Transform will clip it all to your monitor's color space at the end.
This is not how Look-Dev works, you will need to get the look approved again. There is no science to your choice here, it is an artistic choice

2 - We convert these color with the OSL map or V-Ray color map, it will be pointless to convert old scene with sRGB red as diffuse color and render the plane 255 0 0 color in ACEScg.

So a simple material with fully saturated red in diffuse, gets converted to V-RayColor node attached to a V-Ray material?
If your tool does that now, congrats!
Just ditch OSL and this could be a viable solution in production

[^Lele^]

I meant to say in-app color picker.
The default windows approach of sampling the screen.
As it is currently in Max, it creates monsters the second one tries to sample an ACEScg primaries-defined color.
This is but one of the current standing issues with the approach, and one we can't fix ourselves, but need fixed by the DCCs we reside in.

Once the color pipeline, f.e. in Max, was laid down anew, with ACEScg able to run throughout the application, then the color picker would *have* to become exceptionally complex, taking into account what is being picked, and with which intent, and the user would have to define those, making for huge scope for mistakes (you're picking some part of the screen, but what is it? UI? Rendered Sample? Rendered Image? With which ODT? Are you picking the scene linear, the displayed? But what would you like to see it as? And on and on the list goes.).

As there is no direct way to match an incoming sRGB color rendition (i.e. the way it looks on an sRGB display under LWF conditions.) under ACEScg -that i know of-, this is a show-stopping problem for anyone working under strict directions (a brand, f.e., wanting a specific color exactly represented. Not "prettier", or "more saturated", but exactly as expected.).
Changes here have to come from ACES and the academy themselves, assuming there is any scope at all (not a given.) to make the sRGB part of the gamut that overlaps with the wider one somewhat linear enough (currently, it's not linear, but under arbitrary contrast curve, studied so to make things look prettier, more filmic, not exact in respect to a reference. This is mentioned a few times in acescentral and the ACES spec docs.).

So, we're currently behind from the DCCs side, and there are fundamental issues marrying the wider gamut with the rest of the sRGB world we all live in under the current ACEScg specs.
This is why i say we should not promote the workflow as either universal, or one-click: we'd be selling (figuratively speaking) hype, while crippling perfectly valid users' workflows.
VFX companies with RnD departments and solid pipelines are a much better fit for this kind of tech to be implemented end-to-end, and for those we already provide most of the tools they need, and they are good enough to write themselves whatever may be amiss.

[fixeighted]

I learned the word 'tristimulus'. Thank you.
That's quite enough for a Sunday I think

[piotrus3333]

heh, too late to control the aces hype. it’s already everywhere. along with confusion and misconceptions.

one click solution? engine or script doing it for you? look at users of Corona - enjoying wide RGB internal colour space from the beginning - and in 2022 still mostly no idea what is what. gamuts? primaries? why bother, they need aces and thats that.

I consider it very straightforward in max. flip a switch, make the engine understand the intent behind your inputs and Bob’s your uncle. enjoy aces. not a fan of flipping switches? do not worry, wait a bit for Autodesk to sort it out.

regarding the plugin mentioned previously - the mixing seems pretty weird to me - but whatever works, people, whatever works.. and thank you for sharing. commercially or not.

[atanasbak]

regarding the plugin mentioned previously - the mixing seems pretty weird to me - but whatever works, people, whatever works.. and thank you for sharing. commercially or not.

Yes of course, having a discussion and options is always a plus For skies, car paint and similar you can achieve interesting artistic look with mixing (not recommended for strict ACES workflow).