Hi, On a slightly related note, is there any chance of an ImageCache::get_pixels() variant which specifies a channel range, in addition to the ImageInput methods under discussion? I'm using OIIO for a simple compositing tool which prefers to operate channel-by-channel - the ImageCache is great for speeding up repeated access to the same images but currently forces the loading of all the channels at once which isn't ideal for my scenario. If such a variant was supported, is the implementation of the ImageCache such that all channels would be loaded anyway, and get_pixels() would just be skipping data, or would channels only be loaded as and when requested?
As to the original question, I personally would be more than happy to deal with a change to specifying channels as a begin/end range in return for API uniformity, but I don't think the argument that it's unlikely to break code is a particularly strong one. It seems to me that one of the most natural uses for those calls it to request one channel at a time for a process that prefers to operate that way, in which case firstchan!=0 and nchans==1 would be rather likely. Cheers... John ________________________________________ From: [email protected] [[email protected]] on behalf of Michel Lerenard [[email protected]] Sent: Wednesday, November 14, 2012 1:04 AM To: [email protected] Subject: Re: [Oiio-dev] API question with channels 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 _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
