OK. Your original example used dstBuf without declaring it. And when calling
ociodisplay, the dst is first, src is second, you were backwards. I'm not sure
if that was your problem, but I'm going to proceed as if those were just typos
in your example cut-and-paste into the email.
With those fixes (and substituting my own files, and adding some error
checking), I get this:
#!/usr/bin/env python
import OpenImageIO
import os
print os.getenv( 'OCIO' ) # ---> prints '<SOME_PATH>/spi-anim/config.ocio'
inputPath = 'tahoe.tif'
outputPath = 'out.tif'
srcBuf = OpenImageIO.ImageBuf( inputPath )
dstBuf = OpenImageIO.ImageBuf()
OpenImageIO.ImageBufAlgo.ociodisplay( dstBuf, srcBuf , 'sRGB' , 'Film' )
print ('did conversion')
if dstBuf.has_error :
print ('error:', dstBuf.geterror())
dstBuf.write( outputPath )
print ('did write')
And I'm getting the following error:
/Users/lg/.ocio-configs/spi-anim/config.ocio
did conversion
('error:', "DisplayTransform error. Cannot find inputColorSpace, named
'Linear'.")
did write
So I don't get a crash, but I do get the ociodisplay call failing (it does help
to check for errors).
So what's happening is that because you aren't supplying a "from" color space
to ociodisplay, it's just assuming that it's whatever the input image has for
its "oiio:ColorSpace" metadata. Which for me, and apparently for you, is empty
because it doesn't have any idea (filename doesn't contain a color space name,
and tiff doesn't ordinarily have a specific color space unless it's got some
embedded exif data saying it's sRGB). So what does it do if you don't give a
"from" parameter, and the input image doesn't know what color space it's in? It
throws up its hands and says "Linear."
Which is where things really go awry, because there's no color space named
"Linear" in spi-anim/config.ocio.
There is "lnf", which is our name for floating point scene-referred linear.
So on your side, I think you will be ok if you change your call to
dstBuf = OpenImageIO.ImageBuf()
OpenImageIO.ImageBufAlgo.ociodisplay( dstBuf, srcBuf , 'sRGB' , 'Film', 'lnf' )
Or, use whatever color space name you know the input to be in. Maybe it's not
lnf.
Incidentally, if you are switching to OIIO 2.0 anyway, you probably want the
spiffy new more pythonic syntax,
dstBuf = OpenImageIO.ImageBufAlgo.ociodisplay( srcBuf , 'sRGB' , 'Film', 'lnf' )
# you don't need to pre-declare dstBuf
Now, that seems like a dumb error on my part. I think that something I can
change to make this behavior less surprising is that the fallback should not be
the literal word "Linear", but in fact should be whatever color space in the
config has the *role* of scene_linear. That way, the default "from" parameter
being empty will be more useful.
Also... oh boy, this is not my day... at one point in this mess, I tried this:
dstBuf = OpenImageIO.ImageBufAlgo.ociodisplay( srcBuf , 'sRGB' , 'Film',
from='lnf' )
and I got this response:
File "./test.py", line 9
dstBuf = OpenImageIO.ImageBufAlgo.ociodisplay( srcBuf , 'sRGB' , 'Film',
from='lnf' )
^
SyntaxError: invalid syntax
Um... This is because "from" is a keyword!
I never considered this. I need to make sure that the python bindings never try
to make a named parameter be a python keyword! I will make some changes to fix
this, in yet another change. These are piling up.
So, is this enough to get you unstuck for now?
> On Nov 29, 2018, at 3:30 PM, Etienne Fleurant <[email protected]>
> wrote:
>
> Hi Larry,
>
> Unfortunately it still seems to be broken. I'm still getting a segmentation
> fault with the same code snippet that I posted in my OP.
> I'm trying with 2.0.1-RC1 built with OCIO 1.1.0.
>
> Still built on CentOS 7
>
> I would really appreciate if you could take a look at this, we would really
> appreciate it. Sorry for the lack of info, that's the only error info I'm
> getting.
>
> I you need the source image I'm using to re-create the issue or any other
> info, please let me know!
>
> Thanks in advance.
>
> On Wed, Nov 28, 2018 at 1:47 PM Larry Gritz <[email protected]
> <mailto:[email protected]>> wrote:
> 2.0 is now a release candidate, aiming to be the official release on Dec 1 if
> nothing critical is found to be broken.
>
> If upgrading to 2.0 is a possibility and solves the problem, that's certainly
> the easiest for me. :-) But I totally understand if somebody needs this
> fixed before they are ready to throw the switch (there are some API changes,
> the swtich from 1.8->2.0 requires a little preparation), I am happy to try to
> backport a fix.
>
> Tip:
>
> oiiotool --help
>
> will show you (at the bottom) all the available color spaces in whatever OCIO
> configuration it finds. That doesn't necessarily explain seg faults (which
> should never happen), but it can help you diagnose if color transforms
> produce other errors or don't turn out like you think. Sometimes people
> realize it's not finding the ocio config file they intended, or that their
> config doesn't know about the color space they are requesting.
>
> -- lg
>
>
>> On Nov 28, 2018, at 7:06 AM, Daniel Flehner Heen <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> We use ocioconvert all the time to apply/bake "view luts" (which do primary
>> conversion when needed) and it works like a charm. Currently running 1.8.14,
>> but worked with 1.8.5 before we upgraded.
>> Might be worth a shot testing it. If not only to narrow down what's failing.
>> If not, I hope 2.0 works for you :)
>>
>> On Wed, Nov 28, 2018 at 2:02 PM Etienne Fleurant <[email protected]
>> <mailto:[email protected]>> wrote:
>> As far as I know, you can't bake an OCIO color profile using colorconvert.
>> You can only use aforementioned ociodisplay function to do that.
>>
>> Etienne
>>
>> On Nov 28, 2018, at 03:03, Daniel Flehner Heen <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> Have you tried using ImageBufAlgo.colorconvert() instead?
>>>
>>> On Wed, Nov 28, 2018 at 4:14 AM Stephen Mackenzie <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> Yes, I had the same issue described here. The pybind11 work being done for
>>> then-oiio-1.9-alpha fixed it for me, so I've just been awaiting the oiio-2
>>> release as a solve.
>>> YMMV.
>>>
>>> On Tue, Nov 27, 2018 at 9:00 PM Etienne Fleurant
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hi,
>>>
>>> We are getting a seg fault using ImageBufAlgo ociodisplay in python. We're
>>> using:
>>> oiio 1.8.10
>>> compiled on CentOS 7 64bit
>>>
>>> Here's a code snippet of what I'm doing:
>>>
>>> print os.getenv( 'OCIO' ) # ---> prints '<SOME_PATH>/spi-anim/config.ocio'
>>> inputPath = '<MY_PATH>/test_for_ocio.tif'
>>> outputPath = '<MY_PATH>/output.tif'
>>> srcBuf = OpenImageIO.ImageBuf( inputPath )
>>> OpenImageIO.ImageBufAlgo.ociodisplay( srcBuf , dstBuf , 'sRGB' , 'Film' )
>>> dstBuf.write( outputPath )
>>>
>>> ---> outputs : Segmentation fault (core dumped)
>>>
>>> I'm able to make it work through oiiotool though:
>>> oiiotool '<MY_PATH>/test_for_ocio.tif' --iscolorspace 'lnh' --ociodisplay
>>> 'sRGB' 'Film' -o '<MY_PATH>/output.tif'
>>>
>>> but ultimately I'd like to make it work in python. It's a bit hard to debug
>>> since I have no idea why it's seg faulting...
>>>
>>> By the way, I also tried adding:
>>> srcBuf.specmod().attribute( 'oiio:ColorSpace' , 'lnh' ) after my srcBuf
>>> declaration above to no avail.
>>>
>>> That was to replicate what I have in my oiiotool example, since if I omit
>>> this from that command line, I was getting the following error:
>>> oiiotool ERROR: ociodisplay : DisplayTransform error. Cannot find
>>> inputColorSpace, named 'Linear'.
>>>
>>> Maybe I'm having a similar error with python resulting in the seg fault,
>>> but I'm not sure.
>>>
>>> I'm using the spi-anim config with this example.
>>> Any help would be appreciated. I could send an example files if needed.
>>>
>>> Thanks in advance
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>>
>>> --
>>> -Daniel
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>
>>
>> --
>> -Daniel
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>
> --
> Larry Gritz
> [email protected] <mailto:[email protected]>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
