That would certainly take care of things for me. Hopefully not too much of an impact on others as well.
~Andrew On Wed, Feb 17, 2016 at 4:20 PM, Larry Gritz <[email protected]> wrote: > 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]> 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 >> and the reverse for writing: >> >> 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]> 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]> >>> 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] >>> >>> >>> _______________________________________________ >>> 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 > > > -- > 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
