Thanks Larry for the help! :) And no worries, it can't be worst than me inverting the source and destination in my OP example :shame: I just assumed the first argument was the source I guess :/
I added the from argument and now it works! I do agree though that it should default to the value that has the role of "linear" for a given OCIO config. Good idea! Thanks a million for your help and sorry for the dumb argument inversion. Cheers! On Fri, Nov 30, 2018 at 10:46 AM Larry Gritz <[email protected]> wrote: > Ugh, botched again. And it was ok the first time, I see that assignment > was the prior statement. > > Sheesh, don't let me read technical email on my phone early in the morning > prior to coffee. > > > > -- > Larry Gritz > [email protected] > > > On Fri, Nov 30, 2018, 7:43 AM Larry Gritz <[email protected] wrote: > >> Oh no, I misquoted in my prior email. There was one spot where I wrote : >> >> >> dstBuf = OpenImageIO.ImageBuf() >> OpenImageIO.ImageBufAlgo.ociodisplay( dstBuf, srcBuf , 'sRGB' , 'Film', >> 'lnf' ) >> >> But it should have been >> >> >> OpenImageIO.ImageBuf() >> OpenImageIO.ImageBufAlgo.ociodisplay( dstBuf, srcBuf , 'sRGB' , 'Film', >> 'lnf' ) >> >> You want to either supply dstBuf and srcBuf as params and the return >> value (if you even check it) is a success bool, OR just pass srcBuf and the >> return value is dstBuf (OIIO 2.0 only). Not my weird mix of both. >> >> >> -- >> Larry Gritz >> [email protected] >> >> >> On Thu, Nov 29, 2018, 11:44 PM Larry Gritz <[email protected] wrote: >> >>> 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]> 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]> 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]> 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]> wrote: >>>>> >>>>> Have you tried using ImageBufAlgo.colorconvert() instead? >>>>> >>>>> On Wed, Nov 28, 2018 at 4:14 AM Stephen Mackenzie <[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]> 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] >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> -Daniel >>>>> >>>>> _______________________________________________ >>>>> Oiio-dev mailing list >>>>> [email protected] >>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> -Daniel >>>> _______________________________________________ >>>> 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 >>>> >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ > Oiio-dev mailing list > [email protected] > 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
