Is getting the processor for a LOG->LINEAR CPU conversion generally pretty fast after the first one? ie. internally will OCIO cache this processor based on the current config, or is this something I

Ah yes I forgot about that role. I do actually draw a color hexagon and hue sweep. Right now I just do them by plotting them pixel by pixel. Are you saying ROLE_COLOR_PICKER could come in handy

I wouldn't be too concerned with it. My expectation is that the image processing + getProcessor calls would dwarf by many orders of magnitude the PackedImageDesc allocation time. But if you're

Yah, it's generally helpful to run the color picker swatch through the display transform. The simplest solutions I'd recommend is to create an additional color processor (that you hang onto between

I realized I'm creating and destroying a PackedImageDesc once per scanline. Rather than a simple wrapper around some image pointers this class allocates an implementation class. This got me thinking

Anyone have any recommendations on how to deal with color pickers and HDR viewing spaces? Right now we just have a normal non-managed picker that tends to never match the actual color picked from the

Cool. It was "easy" once I realized the FileTransform replaced the display/view/colorspace stuff. Here is the code in C++: if (fileTransform) { OCIO::GroupTransformRcPtr group =

> Ah, this was easier than it looked. Note I skipped the display, view, and input color-space options when a simple LUT is selected. Is that the preferred way to do it? Yup. The input colorspace,

Ah, this was easier than it looked. Note I skipped the display, view, and input color-space options when a simple LUT is selected. Is that the preferred way to do it?

This makes sense conceptually, but those operations boil down to a lot of different transforms that are hidden inside the DisplayTransform, each calling some (internal?) functions to build things

Oh - I think that is EXACTLY what I was looking for! (wasn't aware the GroupTransform could do this). Thanks!

Oh! One other alternative implementation. When in 'Simple Lut' mode, instead of using the displaytransform, just use a group transform and add the normal view components in the canonical order. g =

... ... Ugh is right. Maybe I'll just wait until there is way to combine them logically in the API. :-)

Before I dive into this - does "simple LUT mode" bypass the usual DisplayTransform or is there a way to combine the FileTransform (LUT) with the DisplayTransform? In other words, does anything get

New thought - one workaround for the moment would be to dynamically add a new colorspace for the user specified lut. This is definitely not ideal (I'd much rather extend DisplayTransform), but this

I've just add the Mari source for the OCIO integration to the repo (with permission from the Foundry, of course) ;) https://github.com/imageworks/OpenColorIO/tree/master/src/mari/1.4v1 As far as I can

Paul, It's simple enough as the display transforma are just specified as colorspaces. I suspect that the swizzling is being done outside of ocio. You can just apply the standard image manipulation

I saw in the Mari OCIO demo video they were able to load up a LUT and combine it with other display controls (gain/exposure). I can see how the LUT can be loaded using the FileTransform but how is it

Aha - that makes complete sense. Thanks for explaining it in different terms.

Looks like Katana may have some competition soon for that second-place spot!