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
