OK, let me see if I have this straight. If you read_image(oiio.FLOAT) of a half image (on disk), you get floats back?
But if you read_image(oiio.HALF) of a half image, you get what appears to be an array of floats, but they are actually packed half values? HP, do you agree that it would be sensible that if you did read_image(oiio.UNKNOWN), which is basically the convention we use in C++ to ask for original raw data, Python should give you back an unsigned char array back with the ray data and let you sort it out? What is the best behavior for if you ask for oiio.HALF data, but there is no half data type? Should it promote to float? Return halfs in an unsigned char array? Return halfs in an unsigned short array? Would any of those fixes break your existing software that obviously tries to work around this odd behavior? > On Feb 17, 2016, at 3:49 PM, Haarm-Pieter Duiker <[email protected]> > wrote: > > If you're up for using numpy, this will get you the half float values without > too much extra work: > oiioFloats = inputImage.read_image(oiio.HALF) > oiioHalfs = np.frombuffer(np.getbuffer(np.float32(oiioFloats)), > dtype=np.float16) > > One note, the current OIIO Python implementation doesn't promote the halfs to > float on read. The 'float' values in the returned buffer are actually each > two concatenated half values, and the float buffer will have half as many > entries as you would expect. > > Example usage for reading here: > https://github.com/hpd/CLF/blob/master/python/aces/filterImageWithCLF.py#L126 > <https://github.com/hpd/CLF/blob/master/python/aces/filterImageWithCLF.py#L126> > and the reverse for writing: > https://github.com/hpd/CLF/blob/master/python/aces/filterImageWithCLF.py#L193 > <https://github.com/hpd/CLF/blob/master/python/aces/filterImageWithCLF.py#L193> > > HP > > > > > > > > On Wed, Feb 17, 2016 at 3:25 PM, Larry Gritz <[email protected] > <mailto:[email protected]>> wrote: > In C++, you can just call read_scanlines and pass format=UNKNOWN to get back > the raw data in its original format. > > The problem is that in Python, there is no 'half' so it's not quite sure what > to return. > > I kinda like the decoupling of the raw reads (read_native_*) which are the > part overloaded by the individual format readers, from the app-callable > read_*. So perhaps rather than exposing read_native_*, we should just modify > the Python bindings for read_* to notice that if the native raw data is not a > type representable in Python, to return it as an unsigned character array? > > > > On Feb 17, 2016, at 2:55 PM, Andrew Gartner <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hey all, > > > > Apologies if this has come up before, but I'm curious if anyone had > > considered exposing ImageInput.read_native_scanlines() on the python side > > before. The reason I ask is mainly because the half datatype doesn't exist > > in the native python array class which OIIO uses for python reads. > > Currently the python array will punt and for anything to float (which I'd > > rather avoid). > > > > I had put together an implementation in OIIO 1.5 that simply took the pixel > > size as a parameter and exposed read_native_scanlines that way and that > > allowed me to get the right data properly into either numpy or a raw char > > python array. However, I'd rather not be forked off like that as it's a > > headache trying to remain current with the mainline, plus others may find > > it useful. > > > > Does anyone think exposing the function in general makes sense? I'm happy > > to send the implementation if anyone cares to see it as well. > > > > Cheers, > > > > ~Andrew > > > > -- > 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
