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
