Aces

[sharktacos]

Here's the Maya scene if you'd like to have a look. It is using ACES 1.0.3 with the input color space set to ACEScg.

[^Lele^]

Ah-ah, this is getting eminently interesting, thanks a lot for the scene!

[^Lele^]

Here's the Maya scene if you'd like to have a look. It is using ACES 1.0.3 with the input color space set to ACEScg.

Umh, i'd need a link to the exact config.ocio file you used, or the file itself, even.
I'd run the risk of not using the right stuff.

[^Lele^]

Based on what i could try, anyway, you are failing to load the OCIO descriptor on the shader.
Here it errors with :

// Error: OCIO exception: Error: Loading the OCIO profile 'E:/xxxxxxxxx/config.ocio' failed. yaml-cpp: error at line 494, column 24: illegal map value //

So you're indeed one transform less.
Maybe, eheh.

[sharktacos]

Umh, i'd need a link to the exact config.ocio file you used, or the file itself, even.
I'd run the risk of not using the right stuff.

Here you are: https://github.com/imageworks/OpenCo...ter/aces_1.0.3

The config is applied in the VFB, and also in a VrayTexOCIO. You will need to change the file path on both of these to point to where the config is saved on your computer.

[^Lele^]

Yes it's what i used, then you ARE erroring out on loading the ocio config on the shader, for whatever reason.
Or so the scene you sent me does on my maya 2017 and latest stable 3.6 (and previous v-ray versions too, for that matter).

[sharktacos]

Yes it's what i used, then you ARE erroring out on loading the ocio config on the shader, for whatever reason.
Or so the scene you sent me does on my maya 2017 and latest stable 3.6 (and previous v-ray versions too, for that matter).

Any idea why? It's just a vrayTexOCIO connected to the diffuse color of a vrayMtl. Pretty basic.

[^Lele^]

Ok, i think i found what my issue on loading was ("saving as..." produced an HTML file, no wonder it messed up...).
Now the descriptor works, and i see where your issue was: you never added the ocio descriptor to the specular, regardless of your setup choice of descriptor operations (at least on the blue sphere. maybe other shaders had it on.).
Then, it's in theory just a case of picking the right transforms to, in essence, still display a screen-linear image.
Have fun with the latter! ^^

[sharktacos]

Ok, i think i found what my issue on loading was ("saving as..." produced an HTML file, no wonder it messed up...).
Now the descriptor works, and i see where your issue was: you never added the ocio descriptor to the specular, regardless of your setup choice of descriptor operations (at least on the blue sphere. maybe other shaders had it on.).
Then, it's in theory just a case of picking the right transforms to, in essence, still display a screen-linear image.
Have fun with the latter! ^^

Were you able to reproduce the error? I'll try that out on Monday, but I'm pretty sure the error would be there even if the spec was off. The big white dot is not coming from spec/reflections, but from the diffuse color.

[^Lele^]

Were you able to reproduce the error?

Not really, no.
I finally managed to reload the config without resetting the rollout selections, i think, and all i keep getting is a very linear relationship between parts (as it should be when it works, i'd guess.).
I can't say the Display part of OCIO has any effect whatsoever in the display output, no matter my choices, so perhaps i'm locked in linear-sRGB and do not know (N.B.: the sRGB isn't needed, i left it on to further skew the possible issues).



EDIT: What matters was missing: an error on the implicit load of the transform lut (spi1d), which i never downloaded.
Am now cloning the whole repo and trying again (it'd explain why i was stuck to linear.)

[^Lele^]

Ok, so now that the OCIO config and relative listed luts load properly, i see what the problem is: when you expose up, the VFB clips at 1, whichever component comes first (your not-quite-pure blue then had red seep in when exposed up enough.).
That is due to the choice of input colorspace (ACEScg), while for example using "role_data" leaves it unclipped (And exposing correctly pushes it past 1.0).
I made a few changes to the maps too, those which made sense to my linguistic intelligence (or lack thereof...), as reading the documentation provides splendid transform matrices to and from spaces, and little else.
Namely: input is "scene_linear" (your base texture/color state); this converts the input to ACES (ACES Transform ID : ACEScsc.ACEScg_to_ACES) output is "matte_paint" for the OCIOtextures (that converts the colors to sRGB. Bitmap Textures will need different settings.).
For the VFB: as i said, ACEScg seems to clip, so i tried Data which gave me back a linear image (likely what you do not want from all this. ^^), but also "role_reference", and likely others.
If you transform the view to sRGB through OCIO, then have the vfb's own sRGB off.
Feel free to experiment further, i really have no working experience of this: as i said, on my TD watches there was always only a strictly linear relationship between scene and screen.
Compositors could do what they pleased AFTER my renders were done.
Which is likely why i never made it big, eh, i'm sure of this. ^^

p.s.:Also, out of safety, i'd keep off "Linear Workflow" (wow. been a while.), as that adds another step of sRGB transform to inputs, but only in specific shader channels.

[sharktacos]

Yeah I'm pretty confused by the input/output on the vrayTexOCIO because the color spaces are themselves doing an in/out. The ACES "role_scene_linear" color space is in: ACEScg out:ACES2065-1. The "role_matte_paint" color space is in: ACES2065-1, out: sRGB. So if these are then put into the input/output of the vrayTexOCIO we get three conversions: AcesCG to ACES2065 to sRGB.

I of course get converting from sRGB to scene-linear (where the rendering takes place). What I don't get is how that would be done with the vrayTexOCIO since it has the input and output.

So I'm thinking it should be (big maybe here) input: "Input - Generic - sRGB - Texture" (sRGB to linear) and output: "role_scene_linear" (ACEScg to ACES2065-1).

Also, as far as the VFB goes, I'm pretty sure you want to be in ACEScg rather than data. If ACEScg is indeed clipping I think... again my head hurts with all of this so I could be wrong... that perhaps something is wrong.

I guess we need to confirm what the proper workflow should be for ACES in Vray. Honestly the whole idea of using a vrayTexOCIO for a color pot (not a texture) seems like not the best way to work from a "user interface" perspective.

[^Lele^]

It never was a good workflow.
But not something one can apportion to the render engine.
It speaks volumes to me that the makers of the standard can provide for zero workflow suggestions besides the glaringly inefficient and obvious, but it was no different 5 years ago with the 1.0 standard (which had a slew of show-stopping issues to boot, in the maths and concepts. Reeks of high castle syndrome.).
Further to this, the only thing that sticks to my mind about ACES is this: the CG part is left ALONE, any transform happening away from the VFB, into post when normalising inputs (to whatever a show needs).
I'll keep ignoring this ACES thing until it'll hit me on the face as a production need. Which is likely when i'd quit the job, anyway. ^^

[sharktacos]

So an update: I opened the scene in Maya 2017, turned off "linear workflow" and removed the vrayTexOCIO. I then applied the ACES color management in the Maya prefs (render space: ACEScg, view transform: ACES RRT v1.0, input color space sRGB). In the image below you can see that in the VFB (left sphere) has the blownout diffuse, while the Maya Render View (right sphere) does not.




The VFB is using the OCIO config, while the Render View is using Maya's Syncolor.

I tried using the OCIO config in the Maya Color Management prefs and got the same result (i.e. I got the error). So it seems that there is something wrong with the view transform on the OCIO config.

[sharktacos]

of course I need the OCIO config for Nuke, and in Nuke I get the same error with that OCIO config. So I'm sort of thinking there is something wrong with the OCIO config. Unfortunately I don't see how it's possible to get the Maya Syncolor .ctf files to convert into something that OCIO could understand.