Hi Larry Do you know how I could get my hands on an image that contains the equivalent of 16bit linear unique pixel values per rgb channel, or more? I guess it takes 4kx4k at 16bpp to get there. I could also work with 32bit floats
Thanks Larry Chris Spence Reverator 6815 Biscayne Blvd, Suite 103-191 Miami, FL 33138 Tel: 305 757 1330 i...@reverator.com www.reverator.com > On Oct 16, 2020, at 3:27 AM, Larry Gritz <l...@larrygritz.com> wrote: > > Yeah, this is a bit tricky. The APIs very much want to assume that although > channels may be stored in a planar or separate fashion in the file > (RRRRR...GGGGG.....BBBBB), that you will want to read them into memory > buffers with "contiguous" pixels (RGBRGBRGB...). So there is no API call that > directly reads an image (or scanline or tile) into separate channel buffers, > nor any per-channel strides that would let you force that to happen with a > single call. > > Perhaps this is an oversight. On the other hand, given that it's hard for me > to recall anybody asking for this in the last 12 years, it may have been the > right assumption in general. > > The easy solution is to read it into a temporary buffer and then rescramble > it to separate out the channels. We have some helper functions to make that > easy, look in imageio.h for the convert_image() function (and also > parallel_convert_image). You would basically call this once for each channel, > constructing the strides for src and dst so that they coalesce the R's, G's, > and B's together into their separate buffers. > > There is an obvious performance penalty (of the extra copy step). If that's > really critical for anybody, then we could consider adding "separate" > versions of the API calls that instead of one data pointer would take a > data[], one per channel. That would probably be a lot of work, though not > exactly rocket science. Like I said, the lack of requests for this over the > years is strong circumstantial evidence that it's not an important enough > case to enough people to justify the work or the extra API complexity, though > if lots of people chime in that they have wanted this, I could be convinced. > > -- lg > > >> On Oct 15, 2020, at 4:09 AM, Jan Hettenkofer <j...@hettenkofer.net >> <mailto:j...@hettenkofer.net>> wrote: >> >> Hello all, >> >> I am struggling to read images into a buffer that organises channels >> in a planar memory layout (i.e. all red scanlines before all blue >> before all green etc...). It appeared to me like specifying the >> strides for `ImageInput::read_image` would be the thing to do here. >> However, upon playing with it for a while I realised that it seems >> to be impossible to specify the stride for the channel values within >> a pixel. >> >> For example the following results in the red channel correctly set >> but all the other channel values set to 0 (untouched from the >> default initialisation I suppose): >> >> ``` >> std::vector<T> img_data(spec.width * spec.height * spec.nchannels); >> >> auto column_stride = sizeof(img_data[0]); >> auto row_stride = column_stride * spec.width; >> // initially I assumed that the z-stride would be the one to use >> // to rearrange the channels - now I realise that this is only >> // relevant for volumetric images >> auto slice_stride = row_stride * spec.height; >> >> // helpers::type_to_typedesc<T> returns the OIIO typedesc >> // corresponding to T >> file->read_image(helpers::type_to_typedesc<T>(), >> img_data.data(), >> column_stride, >> row_stride, >> slice_stride >> ); >> ``` >> >> I suspect that in this case green and blue values are written but >> then immediately overwritten by the red channel in the next two >> pixels. >> >> I could of course just accept the interleaved memory layout and then >> copy the pixels into the right place afterwards. >> >> Another way might be writing a clever adapter that "looks" like an >> array to OIIO but actually just re-routes the writes to a real buffer >> with modified positions. However, this would strongly couple my code >> to implementation details of `read_image`. >> >> Is there a method to specify a planar memory layout for the target >> buffer in order to avoid such workarounds? >> >> Thanks a lot in advance for your help! >> >> With kind regards, >> Jan Hettenkofer >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > > -- > Larry Gritz > l...@larrygritz.com <mailto:l...@larrygritz.com> > > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
