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....@...

In OIIO 1.6, if OCIO is disabled (support not compiled at build time, or no OCIO configuration file is found at runtime), all it knows how to do is convert between sRGB or Rec709 and linear.

BUT... if OCIO support is compiled in and a config is found at build time, it 100% relies on OCIO for color space conversions, so if you use color space names not recognized by your OCIO config, it doesn't transform the values. 

I suspect that this is what's happening. You have an OCIO config file somewhere? (Presumably? Or else you probably wouldn't be asking about this on ocio-dev?)

If this is correct, I believe you have four choices:

* Use color space names corresponding to color spaces in your active OCIO config.

* Switch to an OCIO config that contains the color spaces you want to transform among.

* Disable OCIO by removing any config files and/or making sure you don't have an "OCIO" environment variable.

* Switch to OIIO master branch (the in-development 1.7 of the future), which has changed the behavior so that if OCIO doesn't recognize the color space names, it will still fall back on its inherent knowledge of sRGB <-> linear conversion. (This is not uncontroversial! But I think it's the common-sense thing to do.)

On Aug 19, 2016, at 7:14 PM, er...@... wrote:

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-d...@....
For more options, visit https://groups.google.com/d/optout.

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

--
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....@...

On Aug 19, 2016, at 11:38 PM, er...@... wrote:

 Still, I wish there was an error or a warning telling me I'm using colorspace names that don't exist. 

There is, you just weren't checking it:

import OpenImageIO

srcBuf = ImageBuf(src_path)
colorBuf = ImageBuf()
ok = OpenImageIO.ImageBufAlgo.colorconvert(colorBuf, srcBuf, 'sRGB', 'linear')

if not ok :

    print colorBuf.geterror()
OpenImageIO.ImageBufAlgo.make_texture(OpenImageIO.MakeTxTexture, colorBuf, dst_path)

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