Sorry, my thinking is very "master-centric." Of course, 1.1 is the branch we
officially endorse for commercial use.
-- lg
On May 31, 2013, at 8:32 AM, Michel Lerenard wrote:
> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
