Re: ImageBufAlgo make_texture colorspace change


er...@...
 

I'm using OpenImageIO-1.6.14-cp27-cp27m-win_amd64.whl which I downloaded from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ . I found it too much of a pain to build the source for Windows. This didn't come with a config.ocio file, but I saw in the documentation: "If OCIO is not enabled (or cannot find a valid configuration, OIIO will at least be able to convert among linear, sRGB, and Rec709." 

I ran the oiiotool commands Larry suggested. 
For gray.tif,I get:
Stats Min: 0.500000 0.500000 0.500000 (float)
Stats Max: 0.500000 0.500000 0.500000 (float)
Stats Avg: 0.500000 0.500000 0.500000 (float)

For gray.exr, I get:
Stats Min: 0.500000 0.500000 0.500000 (float)
Stats Max: 0.500000 0.500000 0.500000 (float)
Stats Avg: 0.500000 0.500000 0.500000 (float)

So there is something wrong, but I don't know how to fix it.


On Friday, August 19, 2016 at 9:38:13 AM UTC-7, Larry Gritz wrote:
Phrases like "looks lighter in Nuke" always make me suspicious, there are too many ways things can go wrong.

Let's start from first principles.

oiiotool -pattern fill:color=.5,.5,.5 256x256 3 -o gray.tif
oiiotool -stats gray.tif

That should report min/max/average all 0.5.

Now run your conversion script on gray.tif, and 'oiiotool -stats' the resulting exr. What is the value? It *should* be 0.214041 everywhere if the conversion happened properly. If that is the case, then the problem is about how it is read or displays in Nuke.

There was a time when OIIO would, in cases where an OCIO config found, have color conversions *only* depend on OCIO. Color names that were not installed color spaces in your OCIO configuration would be errors and no color transformation would happen. If your output exr has values 0.5, that's probably the problem -- your OCIO configuration simply has no sRGB or linear color spaces defined.

IIRC, newer OIIO actually is a little smarter, in that if an OCIO exists but doesn't know how to do the requested transformation, it will see if the conversion is one of a few that it knows how to do regardless, and sRGB <-> linear is among them. But it needs to be a relatively recent OIIO for it to do that, if OCIO doesn't define those spaces.


On Aug 18, 2016, at 5:47 PM, er...@... wrote:

Hi,
I'm using the Python bindings for OIIO to convert images into textures. I'm having an issue converting a .tif into a .exr texture. The .exr is in sRGB colorspace instead of linear. The .exr looks lighter in Nuke than the .tif. I tried to force the colorspace change, but it didn't work either. Here are two ways I tried to make the texture:

import OpenImageIO

srcBuf = ImageBuf(src_path)
config = OpenImageIO.ImageSpec()
config.attribute('maketx:incolorspace', 'sRGB')
config.attribute('maketx:outcolorspace', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, srcBuf, dst_path, config)


and 

import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)


I don't get any errors, but nothing changes. Am I using the wrong colorspace names? I don't know where to find them since they aren't listed in the documentation.

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

--
Larry Gritz
l....@...


Join ocio-dev@lists.aswf.io to automatically receive all group messages.