Hi Larry, Yes, that’s the way. Thanks for dealing with me. You’re very supportive considering how crazy busy you’re are with OIIO related stuff.
Chris Spence Digital Devoid, Inc. 7300 Biscayne Blvd, Suite 405 Miami, FL 33138 Tel: 305 757 1330 [email protected] www.digitaldevoid.com > On Oct 19, 2020, at 2:31 PM, Larry Gritz <[email protected]> wrote: > > I would recommend just constructing it yourself, from C++ or python fill a > buffer with all the values you want, then write it out as an image. > > -- lg > > >> On Oct 16, 2020, at 12:43 PM, reverator <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 >> >> [email protected] <mailto:[email protected]> >> www.reverator.com <http://www.reverator.com/> >> >> >> >> >> >>> On Oct 16, 2020, at 3:27 AM, Larry Gritz <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>>> [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 > > -- > Larry Gritz > [email protected] <mailto:[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
