No worries on the reply time, I think this might work and I'll give it a
shot when I get back to the office after the holiday.
You're correct I only need to preserve what I read and the bit pattern
doesn't really matter, so if I can just leverage setting the channelformats
on the spec I should be good to go. I think what's confusing the internals
is that I'm setting all my numpy arrays dtype to be type "B" but have a
different size in bytes (so for a half array it would be
numpy.array(someBuffer , dtype = numpy.dtype(('B', 2))) ) I don't have the
exact code handy but I'll go through and see what I can figure out on
Monday and get a clearer answer.
Thanks Larry!
~Andrew
On Thu, Nov 28, 2019 at 3:04 PM Larry Gritz <[email protected]> wrote:
> Sorry for the delay in replying.
>
> I see, you are correct. When we switched to pybind11 (the patch is from 14
> Nov 2017, and has been in release 2.0+), it changed from Unknown meaning
> "raw native format bit pattern" to "one type that is adequate for any/all
> of the native channel types".
>
> I think that this was because the pybind11 change moved the pixel buffer
> objects passed back and forth from the read_* and write_* methods from
> being simple python 1d arrays into numpy ndarrays. In the old python
> arrays, it was just bytes, so it could be anything. In the numpy layout,
> the channels of a pixel are the lowest dimension of the array, and I don't
> think they are allowed to be different types.
>
> Before I dig in deeper and potentially upturn everything in the
> implementation, let's see if we can get things to work for you with what we
> have.
>
> Ultimately, you just want to allow a pixel buffer read from one file to be
> written to another, while preserving the original per-channel data types
> from the input, right? But you don't really care what the in-memory
> representation is, as long as the output file is right?
>
> Or is that not enough, and you really do need the raw bit pattern in the
> python script itself?
>
> Let's assume for the moment that it's enough that you can write the same
> mixed channel types as you read. I think you just need to make sure that
> the output imagespec correctly conveys the per-channel types. For example,
> this code will NOT BE CORRECT:
>
> myinput = ImageInput.open("input.exr")
> inspec = myinput.spec() # Note: inspec.format is a single "ok for
> any channel" data type
> buf = myinput.read_image(format="unknown")
>
> outspec = ImageSpec(myinput.width, myinput.height, myinput.nchannels,
> myinput.format)
> myoutput = ImageOutput.create("output.exr")
> myoutput.open("output.exr", outspec) # Not enough information! Lost
> the per-channel types!
> myoutput.write_image(buf)
>
> But the following change should work:
>
> ...
> outspec = ImageSpec(myinput.width, myinput.height, myinput.nchannels,
> myinput.format)
> outspec.channelformats = inspec.channelformats
> ...
>
> I'm just typing this off the top of my head, I haven't tested it
> literally. I'm pretty sure it should work, though, because there's a spot
> in the testsuite where this is required (
> https://github.com/OpenImageIO/oiio/blob/master/testsuite/python-imagebuf/src/test_imagebuf.py#L137).
> It's not exactly this construct, but because an ImageBuf can only hold one
> data type, underneath it's doing the same one-type-to-per-channel-types
> output as we're talking about.
>
> Might this accomplish what you need with the current semantics?
>
> -- lg
>
>
> On Nov 19, 2019, at 11:11 AM, Andrew Gartner <[email protected]>
> wrote:
>
> Hey Larry (and anyone else who may be able to help),
>
> Just moved to OIIO 2.0 and realized I've got issues with how i was using
> write_scanlines from python now.
>
> Prior to 2.x I had been passing oiio.UNKNOWN to the call as I had been
> treating all my pixel data as raw char*'s under the hood. I was responsible
> for making sure it was interleaved and sized properly. This was super
> helpful if i had an exr that mixed full and half floats in the same part
> and I needed to swap a channels' data for some reason.
>
> Now I'm getting size mismatches between the buffers I've read in as raw
> data and when I try to rewrite them with write_scanlines as I think the
> python buffers are trying to infer a type/size and getting confused.
>
> Is there any way to restore this or work around it? I'm trying to knock
> together an example file so hopefully i'll have that shortly.
>
> Cheers,
>
> ~Andrew
> _______________________________________________
> 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
