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
