So I'm proposing: 1. If you ask for a (non-UNKNOWN) format that exists in Python, it converts to and returns an array of that format.
2. If you ask for UNKNOWN, or a format that doesn't exist, it returns the raw data in an unsigned char array. There is a variation: 2a. If you ask for UNKNOWN, and all channels are the same format and it's a type that exists in Python, return that type. 2b. If you ask for UNKNOWN and it's a "mixed type" file, or a single type but one that doesn't exist in Python, or the type you ask for doesn't exist in Python, return raw data packed into an unsigned char array. > On Feb 17, 2016, at 4:10 PM, Andrew Gartner <[email protected]> wrote: > > Yea the C++ implementation works well with oiio.UNKNOWN, I kinda miss that in > the python side to be honest. Right now it looks like things revert back to > spec.format if oiio.UNKNOWN is supplied to read_scanlines, that can be > problematic if you have multiple formats in a single image so I've avoided it. > > @Larry, to you question about returning an unsigned char array, I like the > idea on principle in that it preserves the decoupling as you said. I'm > wondering if there would be any weirdness if you had to grab multiple > channels of an image that had different data types one of which isn't > representable in python? Would it default to just unsigned char yet again in > that case? > > @Haarm: interesting, I didn't realize they were concatenated/packed like > that! I just saw the 'f' in the python array and assumed I was seeing > promoted values :) I'm still scratching my head over the multiple format > reads though, same as for Larry's idea. > > Thanks for the replies, Cheers, > > ~Andrew > > > > On Wed, Feb 17, 2016 at 3:49 PM, Haarm-Pieter Duiker <[email protected] > <mailto:[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] <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
