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
<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 <andrewgart...@gmail.com> 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
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
