My mistake, i'm still working with the 1.1 release.
Thinking about it i remember a discussion a few months back in which we
discussed the fact the the lines and the channels were not specified
using the same convention and that the change could raise a
compatibility issue if the end channel was included.
On 05/31/2013 05:25 PM, Larry Gritz wrote:
I think we may be looking at different branches?
In master (what will become 1.2), it reads:
/// Read multiple scanlines that include pixels (*,y,z) for all
/// ybegin<= y< yend, into data, using the strides given and
/// converting to the requested data format (unless format is
/// TypeDesc::UNKNOWN, in which case pixels will be copied in the
/// native data layout, including per-channel data formats). Only
/// channels [chbegin,chend) will be read/copied (chbegin=0,
/// chend=spec.nchannels reads all channels, yielding equivalent
/// behavior to the simpler variant of read_scanlines).
virtual bool read_scanlines (int ybegin, int yend, int z,
int chbegin, int chend,
TypeDesc format, void *data,
stride_t xstride=AutoStride,
stride_t ystride=AutoStride);
This was one of the few places that were start/number, whereas almost every
other range specifier was [begin,end), so at some point we switched it so that
ranges always work the same way throughout the API.
On May 31, 2013, at 8:20 AM, Michel Lerenard wrote:
From the header:
/// Read multiple scanlines that include pixels (*,y,z) for all
/// ybegin<= y< yend, into data, using the strides given and
/// converting to the requested data format (unless format is
/// TypeDesc::UNKNOWN, in which case pixels will be copied in the
/// native data layout, including per-channel data formats). Only
/// channels [firstchan,firstchan+nchans) will be read/copied
/// (firstchan=0, nchans=spec.nchannels reads all scanlines,
/// yielding equivalent behavior to the simpler variant of
/// read_scanlines).
virtual bool read_scanlines (int ybegin, int yend, int z,
int firstchan, int nchans,
TypeDesc format, void *data,
stride_t xstride=AutoStride,
stride_t ystride=AutoStride);
I checked the cpp file, the implementation is coherent with the header.
Maybe you are getting confused because it doesn't work the same to specify
lines, where you do have to use ystart and yend ?
On 05/31/2013 05:03 PM, Larry Gritz wrote:
I think it's begin/end, not begin/number. So it would be
file->read_scanlines(spec.width, spec.height, 0, i, i+1, spec.format, out_data);
Unless it's not working properly?
On May 31, 2013, at 12:01 AM, Michel Lerenard wrote:
Colin,
quite simple:
for (int i=0; i< spec.nchannels ; i++){
file->read_scanlines(spec.width, spec.height, 0, i, 1,
spec.format, out_data);
//...do whatever you want with out_data
}
'i' tells you need the i-th channel, the 1 after that you want to read only one
channel.
This snippet reads entire channels one after the other.
On 05/30/2013 10:48 PM, Larry Gritz wrote:
You can't request the channels be returned and not interleaved.
But there are varieties of read_scanlines and read_tiles that let you select a channel range
(including just one channel), so you could do it with one call per channel. Look in imageio.h for
the calls with "chbegin" and "chend" in the argument lists.
On May 29, 2013, at 5:13 PM, Colin Doncaster wrote:
Hi there -
What is the default buffer layout when using read_image(TypeDesc::FLOAT, data)?
It appears to be interleaved channels ( rgbargba... ), if that's the case is
it possible to request the data to NOT be interleaved ( rrrrggggbbbb... )? It
appears that we can define stride lengths but for dimensions of the whole
image, not the channels themselves.
Thank you!
--
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
--
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
--
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
