I merged into master. I'm going to let it sit in master for a few days, and if
nobody complains, then I'll backport it to RB-1.6.
-- lg
> On Feb 23, 2016, at 2:36 PM, Larry Gritz <[email protected]> wrote:
>
> Passes travis for me. I'll do a few more tests when I get a chance and merge
> if it seems ok.
>
>
>> On Feb 23, 2016, at 1:09 PM, Larry Gritz <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Sometimes the Travis builds fail for spurious reasons (for example, a node
>> in their cloud inexplicably fails to install one of the required packages).
>>
>> I'll double check it or attempt to force another build to be sure, before
>> merging.
>>
>> Thanks for the update.
>>
>>
>>> On Feb 23, 2016, at 1:02 PM, Andrew Gartner <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hey Larry,
>>>
>>> I pulled it down and so far I've at least been able to confirm that passing
>>> oiio.UNKNOWN into read_scanlines() from python returns the expected uint8
>>> buffer with mixed formats in the image. I'm going to move forward swapping
>>> my code over. I haven't tested the other changes in behavior, but I'll try
>>> to do so after my code is all patched up.
>>>
>>> Also looks like the Travis CI build failed on this PR so I don't know if
>>> that would hold up review/merging but I figured I'd bring it up in case it
>>> fell under the radar.
>>>
>>> ~Andrew
>>>
>>> On Mon, Feb 22, 2016 at 3:03 PM, Andrew Gartner <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> Sounds good, I'm going to patch it in now and test. I'll try to get you
>>> results as soon as I can. busy week already and it's only Monday.
>>>
>>> Cheers,
>>>
>>> ~Andrew
>>>
>>> On Mon, Feb 22, 2016 at 2:38 PM, Larry Gritz <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> I think that PR is against master, though if you download it as a patch I
>>> would expect it to be applicable to the head of 1.6.
>>>
>>> You should also be able to pull it into your master and then cherry-pick it
>>> into your 1.6 if that's easier for you to test.
>>>
>>> In any case, if it's approved, I will certainly merge it (or the
>>> equivalent) into both branches.
>>>
>>>
>>>> On Feb 22, 2016, at 2:32 PM, Andrew Gartner <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Thanks much Larry, I'll give it a whirl. just out of curiousity, is that
>>>> commit for the 1.6 branch(es) or just master (which I guess is 1.7 at this
>>>> point)? I haven't been following the tags super close. I can certainly
>>>> make it work either way just wondered.
>>>>
>>>> Cheers,
>>>>
>>>> ~Andrew
>>>>
>>>> On Fri, Feb 19, 2016 at 10:26 PM, Larry Gritz <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>> OK, here is the proposed implementation:
>>>> https://github.com/OpenImageIO/oiio/pull/1362
>>>> <https://github.com/OpenImageIO/oiio/pull/1362>
>>>>
>>>>
>>>>> On Feb 19, 2016, at 6:40 PM, Andrew Gartner <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Hmm, good point, forgot about this. uint8 would be weird default on the
>>>>> python side.
>>>>>
>>>>> I like the oiio.FLOAT default idea better than the others as it will
>>>>> probably be more obvious what happened in their code should they happen
>>>>> to be using the read without supplying the format.
>>>>>
>>>>> It may break things but it breaks them the "least" in my opinion.
>>>>> Requiring the argument for every call is probably better long term but
>>>>> we're already changing behavior with supplying oiio.UNKNOWN so we should
>>>>> probably confine the real changes to those folks as best we can.
>>>>>
>>>>> Just my two cents.
>>>>>
>>>>> TL;DR: I'd go with oiio.FLOAT as a default
>>>>>
>>>>> ~Andrew
>>>>>
>>>>> On Fri, Feb 19, 2016 at 4:52 PM, Larry Gritz <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>> OK, just one more wrinkle.
>>>>>
>>>>> For a script that passes no format at all, the default is/was UNKNOWN,
>>>>> but that changes behavior. Before, it would return an array based on
>>>>> spec.format (the "widest" format of the channels). But now, it means to
>>>>> return a uint8 blob of packed native data, which is "advanced usage" for
>>>>> sure, and possibly not a good default.
>>>>>
>>>>> I propose changing the parameter default to oiio.FLOAT, which gives a
>>>>> sensible behavior for apps as well as making it very likely that old apps
>>>>> will continue to work in some kind of sensible way.
>>>>>
>>>>> Another way to go is to require the argument to be passed. That will
>>>>> break old Python scripts, but will force everything to be explicit moving
>>>>> forward.
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 19, 2016, at 11:49 AM, Haarm-Pieter Duiker
>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>
>>>>>> Two thumbs up! (packed into one float thumbs up)
>>>>>>
>>>>>> HP
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 19, 2016 at 10:21 AM, Andrew Gartner
>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>> Yep, I'm good with that.
>>>>>>
>>>>>> Thanks again for teasing this apart Larry/HP
>>>>>>
>>>>>> ~Andrew
>>>>>>
>>>>>> On Fri, Feb 19, 2016 at 10:09 AM, Larry Gritz <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>> OK, that sounds reasonable. So we have:
>>>>>>
>>>>>> * If you ask for a specific type, convert and return an array of that
>>>>>> type. If you ask for HALF, the half bit pattern gets returned in a
>>>>>> uint16 array, since there is no true half type.
>>>>>>
>>>>>> * If you ask for UNKNOWN (explicitly "give me raw data"), it returns an
>>>>>> array of unsigned chars containing the raw data.
>>>>>>
>>>>>> Everybody can live with that?
>>>>>>
>>>>>>
>>>>>>> On Feb 19, 2016, at 8:08 AM, Haarm-Pieter Duiker
>>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>
>>>>>>> Of the options "pass half values disguised as an unsigned short array"
>>>>>>> feels the cleanest to me. You keep the right number of components in
>>>>>>> the array, if you have any checks for that, and the data to be convert
>>>>>>> to halfs is already grouped appropriately.
>>>>>>>
>>>>>>> Converting to halfs is also a one line call to numpy:
>>>>>>> np.frombuffer(np.getbuffer(np.uint16(uint16Value)), dtype=np.float16)
>>>>>>> Ex.
>>>>>>> https://github.com/hpd/CLF/blob/master/python/aces/clf/Common.py#L92
>>>>>>> <https://github.com/hpd/CLF/blob/master/python/aces/clf/Common.py#L92>
>>>>>>>
>>>>>>> HP
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 18, 2016 at 4:06 PM, Larry Gritz <[email protected]
>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>> In C++, asking for UNKNOWN just copies the native format data and
>>>>>>> leaves it for you to sort out. But to C++, a buffer is a buffer, you're
>>>>>>> passing it a void* in any case.
>>>>>>>
>>>>>>> In Python, it's dynamic typing, so read_image RETURNS an array, and it
>>>>>>> has to be an array of some type. Which type?
>>>>>>>
>>>>>>> I think we all are coming to agree that if you ask for UNKNOWN,
>>>>>>> probably the most analogous thing (to C++) is to return an unsigned
>>>>>>> char array, filled with the raw data, and leave you to sort it out.
>>>>>>> That's as close to "untyped raw buffer" as we can get.
>>>>>>>
>>>>>>> If you *ask* for HALF, it's nonsensical, because you can't make an
>>>>>>> actual half array in Python. You could promote and convert it to float.
>>>>>>> Or you could return raw values in unsigned char array (like if you'd
>>>>>>> passed UNKNOWN). Or, yeah, another possibility is to pass half values
>>>>>>> disguised as an unsigned short array?
>>>>>>>
>>>>>>> I'm not super fond of the last choice.
>>>>>>>
>>>>>>> Right now, we do something stupider than any of those -- which is to
>>>>>>> pack raw half values into a buffer, but the buffer advertises itself as
>>>>>>> being a float array. That clearly needs to change. It was never
>>>>>>> intentional; I just never thought carefully about that case because I
>>>>>>> never imagined anybody asking for a type that didn't exist in Python.
>>>>>>>
>>>>>>> So, current proposal on the table:
>>>>>>>
>>>>>>> * If you ask for a type that can be a valid Python array type, convert
>>>>>>> and return an array of that type.
>>>>>>>
>>>>>>> * If you ask for UNKNOWN (explicitly "give me raw data") or HALF
>>>>>>> (implicitly so, because it doesn't exist in Python), it returns an
>>>>>>> array of unsigned chars containing the raw data.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Feb 18, 2016, at 3:36 PM, Haarm-Pieter Duiker
>>>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>>
>>>>>>>> Returning a series of unsigned 16 bit ints for a call with the type
>>>>>>>> half feels like a nice middle ground. The consumer will have to know
>>>>>>>> that halfs aren't natively supported in Python, and how to convert
>>>>>>>> from unsigned short to half, but that doesn't feel like a large burden.
>>>>>>>>
>>>>>>>> I can't speak to the expected behavior of the UNKNOWN in Python. I
>>>>>>>> haven't used that path in Python or C++.
>>>>>>>>
>>>>>>>> HP
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 18, 2016 at 1:23 PM, Larry Gritz <[email protected]
>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>> I don't have especially strong feelings about this one way or the
>>>>>>>> other.
>>>>>>>>
>>>>>>>> Just returning a raw data byte array matches the C++ behavior more
>>>>>>>> closely, no argument there.
>>>>>>>>
>>>>>>>> On the "con" side, perhaps I was thinking of compatibility? We're
>>>>>>>> really talking about changing the meaning of oiio.UNKNOWN from "use
>>>>>>>> spec.format" to "return raw data", which differ in the case of mixed
>>>>>>>> channel types.
>>>>>>>>
>>>>>>>> Are there Python programs out there that pass UNKNOWN (or pass
>>>>>>>> nothing, defaulting to UNKNOWN) and rely on getting the right kind of
>>>>>>>> array back that matches spec.format?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Feb 18, 2016, at 12:58 PM, Andrew Gartner <[email protected]
>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>>
>>>>>>>>> "Second, I could collapse 2a and 2b, and just say that if you ask for
>>>>>>>>> UNKNOWN, you get an array of uint8 back with the native raw data"
>>>>>>>>>
>>>>>>>>> Just out of curiosity, what are the drawbacks to doing this? I admit
>>>>>>>>> I like having some way of getting at the raw data at any time (hence
>>>>>>>>> my original method of exposing the native calls). That allowed me to
>>>>>>>>> check my imagespec and regardless of whether I had a mixed format
>>>>>>>>> image or all half data I could get everything in one read call.
>>>>>>>>> Granted I'm used to keeping track of and manipulating the strides of
>>>>>>>>> those arrays in bytes just out of old habit (and C++ usage) so maybe
>>>>>>>>> I'm the minority opinion.
>>>>>>>>>
>>>>>>>>> Even so, your current thinking still works if that's where the
>>>>>>>>> consensus is I'm happy to use it as such.
>>>>>>>>>
>>>>>>>>> Thanks again
>>>>>>>>>
>>>>>>>>> ~Andrew
>>>>>>>>>
>>>>>>>>> On Thu, Feb 18, 2016 at 12:21 PM, Larry Gritz <[email protected]
>>>>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>>> I think that the only format that we can encounter as pixel data,
>>>>>>>>> which does not exist in Python arrays, is 'half'.
>>>>>>>>>
>>>>>>>>> So let me rephrase my current thinking:
>>>>>>>>>
>>>>>>>>> 1. If you ask for a specific type (except HALF), you'll get a Python
>>>>>>>>> array of that type holding the converted values.
>>>>>>>>>
>>>>>>>>> 2. Otherwise (i.e., you ask for UNKNOWN or HALF), you will get the
>>>>>>>>> native (raw) data.
>>>>>>>>> (a) If all channels are the same data type and it's anything but
>>>>>>>>> half, you'll get the data as a Python array of that type.
>>>>>>>>> (b) Otherwise (half, or mixed channel types), you'll get the data as
>>>>>>>>> a Python array of unsigned bytes.
>>>>>>>>>
>>>>>>>>> Note that (1) is the easy case to deal with: ask for the type you
>>>>>>>>> want, let it do the conversion. If you go for option (2) by asking
>>>>>>>>> for native data, you get a blob and it's up to you to figure out what
>>>>>>>>> to do with it.
>>>>>>>>>
>>>>>>>>> There are two other choices we could make. I'm not inclined to at the
>>>>>>>>> moment, but would be happy to do so if people think it's helpful.
>>>>>>>>> First, if you ask for HALF, I could have it return float. Second, I
>>>>>>>>> could collapse 2a and 2b, and just say that if you ask for UNKNOWN,
>>>>>>>>> you get an array of uint8 back with the native raw data, even if it
>>>>>>>>> happened to be all channels of the same type, a type that you could
>>>>>>>>> have made into a Python array of the right type.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Feb 17, 2016, at 11:16 PM, Haarm-Pieter Duiker
>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>>>>
>>>>>>>>>> Picking this up a little later in the day. Sorry about that. Adding
>>>>>>>>>> quotes from earlier in the thread just so it's clear what I'm
>>>>>>>>>> responding to.
>>>>>>>>>>
>>>>>>>>>> The current status:
>>>>>>>>>> "
>>>>>>>>>> If you read_image(oiio.FLOAT) of a half image (on disk), you get
>>>>>>>>>> floats back?
>>>>>>>>>> "
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>> "
>>>>>>>>>> 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?
>>>>>>>>>> "
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>> The proposal:
>>>>>>>>>> "
>>>>>>>>>> 1. If you ask for a (non-UNKNOWN) format that exists in Python, it
>>>>>>>>>> converts to and returns an array of that format.
>>>>>>>>>> "
>>>>>>>>>> This is the current behavior, no?
>>>>>>>>>>
>>>>>>>>>> "
>>>>>>>>>> 2. If you ask for UNKNOWN, or a format that doesn't exist, it
>>>>>>>>>> returns the raw data in an unsigned char array.
>>>>>>>>>> "
>>>>>>>>>> It feels like this is two proposals (Trying not to clash with your
>>>>>>>>>> earlier 2a and 2b):
>>>>>>>>>> 2c. If you ask for UNKNOWN, return raw data in an unsigned char array
>>>>>>>>>> 2d. If you ask for a format that doesn't exist, return raw data in
>>>>>>>>>> an unsigned char array
>>>>>>>>>>
>>>>>>>>>> 2c. feels right. It should work for the case of typical RGB or RGBA
>>>>>>>>>> images but also for multi-layer EXRs. The consumer can convert the
>>>>>>>>>> channels to their intended types using methods from the ImageSpec.
>>>>>>>>>> I'd suggest that asking for UNKNOWN lead unequivocally to a raw
>>>>>>>>>> unsigned char array. Supporting the special cases described in the
>>>>>>>>>> 2a and 2b listed earlier would require additional logic on the
>>>>>>>>>> consuming code side to account for those cases. Feels like a recipe
>>>>>>>>>> for lots of brittle special case logic.
>>>>>>>>>>
>>>>>>>>>> 2d. is less clear. How is the change in behavior from returning real
>>>>>>>>>> values for known types to returning raw char array data for unknown
>>>>>>>>>> types signaled to the consumer? Is this still something that
>>>>>>>>>> programmers have to just know a priori? How is this different from
>>>>>>>>>> the current behavior?
>>>>>>>>>>
>>>>>>>>>> I suppose the list of types known to OIIO but not Python is finite
>>>>>>>>>> and likely to shrink over time. Having special cases like we have in
>>>>>>>>>> that example code, isn't such a big deal in the mean time, but then
>>>>>>>>>> that's just saying the the current behavior is fine.
>>>>>>>>>>
>>>>>>>>>> Hope that's helpful in some way. Aside from agreeing that adding an
>>>>>>>>>> UNKNOWN option is a good idea, we're still left without a good way
>>>>>>>>>> to consume half data without accounting for it explicitly.
>>>>>>>>>>
>>>>>>>>>> HP
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 17, 2016 at 4:35 PM, Andrew Gartner
>>>>>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>>>> 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]
>>>>>>>>>> <mailto:[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] <mailto:[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]
>>>>>>>>>>> <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]
>>>>>>>>>> <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>
>>>>>>>
>>>>>>> --
>>>>>>> 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] <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>
>>>
>>> --
>>> 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
>
> --
> Larry Gritz
> [email protected] <mailto:[email protected]>
>
>
> _______________________________________________
> 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
