I will get the default space fix into the 2.0 release and also backport it to the next 1.8 update. Here's the PR, if you are curious: https://github.com/OpenImageIO/oiio/pull/2085
> On Nov 30, 2018, at 10:57 AM, Etienne Fleurant <[email protected]> > wrote: > > 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] > <mailto:[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] <mailto:[email protected]> > > > On Fri, Nov 30, 2018, 7:43 AM Larry Gritz <[email protected] > <mailto:[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] <mailto:[email protected]> > > > On Thu, Nov 29, 2018, 11:44 PM Larry Gritz <[email protected] > <mailto:[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] >> <mailto:[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] <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] <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
