correct workflow for openColorIO in Vray

[dere...@gmail.com]

As I understand it, one needs to have an openColorIO viewer applied to the render, and also have an OCIO input transforms applied to the diffuse textures. I applied the OCIO to the render in the Vray VFB (using spi-anim), and used a  VrayTexOCIO node on the diffuse textures set to  "colorspace" mode with the "in" set to dt16 and "out" set to Inf. FWIW, the textures are actually 8-bit png filles.

Just wanted to confirm that this is a correct/viable workflow. 

[Sean Cooper]

This is an acceptable workflow, with the caveat that dt16 is only intended to be used with the vd* viewing transform. Essentially the dt* colorspace assumes that the textures are supposed to look the same after going through the viewing transform (with the additional criterion of not violating the 0.0-1.0 linear value diffuse values). So that's why dt* is the viewing transform with scaled to 1.0. Other pipelines simply invert the sRGB display characteristics and deal with the differences going through the viewing transform, made easier with real-time feedback to the texture painter with OCIO enabled texture packages. 

If that's confusing just let me know, this was a short response as I'm on my mobile. 

On Apr 17, 2017 9:03 PM, <dere...@gmail.com> wrote:

As I understand it, one needs to have an openColorIO viewer applied to the render, and also have an OCIO input transforms applied to the diffuse textures. I applied the OCIO to the render in the Vray VFB (using spi-anim), and used a  VrayTexOCIO node on the diffuse textures set to  "colorspace" mode with the "in" set to dt16 and "out" set to Inf. FWIW, the textures are actually 8-bit png filles.

Just wanted to confirm that this is a correct/viable workflow. 

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Derek Flood]

Thanks Sean, I think I understand the first part. Could you explain this part?

"Other pipelines simply invert the sRGB display characteristics and deal with the differences going through the viewing transform, made easier with real-time feedback to the texture painter with OCIO enabled texture packages."

that's where I got a bit lost.

[Derek Flood]

Let me make my question a bit more specific: When you say "real-time feedback to the texture painter with OCIO enabled texture packages" I imagine you mean a program like Mari which works with OCIO color management?

Would the idea of this alternative pipeline be to set Mari to use OCIO color management (for spi-anim that means 8 bit diffuse textures are vd8) for painting the textures, but then in the render still doing an SRGB to linear conversion on the diffuse textures prior to rendering?

[Sean Cooper]

Sorry, yes "real-time" just meaning a viewport that is OCIO managed like Mari.

For spi-anim, you would set your diffuse color textures to be "dt8" (which stands for diffuse texture 8-bit), and would linearize using dt8 -> lnf as well.

On Wed, Apr 19, 2017 at 5:42 PM, Derek Flood <dere...@gmail.com> wrote:

Let me make my question a bit more specific: When you say "real-time feedback to the texture painter with OCIO enabled texture packages" I imagine you mean a program like Mari which works with OCIO color management?

Would the idea of this alternative pipeline be to set Mari to use OCIO color management (for spi-anim that means 8 bit diffuse textures are vd8) for painting the textures, but then in the render still doing an SRGB to linear conversion on the diffuse textures prior to rendering?

[Derek Flood]

Thanks Sean, I guess then I'm not sure what you mean by "Other pipelines simply invert the sRGB display characteristics." Would you mind clarifying?