I did noticed it, but it doesn't bother me that much (i am using these
functions). I thought there was a good reason behind it.
I think it would be better to harmonize the parameters, and drop the
range version. Having both will complicated things, the signatures being
the same we'd need to have different function names.
I'm not sure people using OIIO have all switched to 1.1.0 (or yet know
the version is out), so I vote for the solution you're proposing: change
things right now. Hopefully this API modification will be seen as a
feature of the new version.
As for breaking this code, I hope people using the library have
subscribed to the ML and will notice this thread.
On 11/14/2012 07:13 AM, Larry Gritz wrote:
Does it bother anyone that the ImageInput::read_* functions, the varieties that
let you specify a channel subset, look like this:
virtual bool read_tiles (int xbegin, int xend, int ybegin, int yend,
int zbegin, int zend,
int firstchan, int nchans, TypeDesc format,
void *data, stride_t xstride=AutoStride,
stride_t ystride=AutoStride,
stride_t zstride=AutoStride);
The x, y, and z extents are given as [begin,end) ranges, but for some reason
that escapes me now, the channel subset is given as a first channel and number
of channels.
ROI and ImageBuf::get_pixel_channels both specify channel subsets as
[chbegin,chend), in keeping with how we specify spatial ranges everywhere else.
I hadn't fully noticed this discrepancy until today, and now that I have, I
can't unsee it or stop thinking about it. It's bugging the crap out of me.
My inclination is to apologize profusely for tagging 1.1.0 immediately before
contemplating an API change, ask for a do-over, quickly change it to
chbegin/chend, and vow not to mix metaphors for in any future API calls (always
begin/end ranges).
I'm not sure how often anybody is actually using the channel subset versions of
these calls. But note that specifying firstchan=0,nchans=nchannels gives the
same behavior as specifying chbegin=0,chend=nchannels. So it's very likely
that this wouldn't break anyone's code.
Which is the lesser evil, changing the API but having a uniform way to specify
ranges (spatial or channel), or allowing it to continue with different ways in
different interfaces and different methods for spatial versus channel ranges?
Arguments pro or con?
--
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
