For all those who would like to expose either templated versions, or versions with non-float types...
Do you have any specific clients of the API in mind? Can you provide details? -- Jeremy On Fri, Jun 29, 2012 at 4:54 PM, Larry Gritz <[email protected]> wrote: > Another possibility: write the functions as templates (as we have), call them > only for <float> variations, leave them where they are (not a separate > header), but then they are "shovel ready" if we ever want to expose them in > some other way, or for people to copy into their own code. > > So functionality like "over" would look like this: > > // Fully type-specialized version of over -- internal to imagebufalgo.cpp > template<class Rtype, class Atype, class Btype> > void over (ImageBuf &R, const ImageBuf &A, const ImageBuf &B, ROI roi) > { > ImageBuf::ConstIterator<Atype, float> a (A); > ImageBuf::ConstIterator<Btype, float> b (B); > ImageBuf::Iterator<Rtype, float> r (R, roi); > ... etc ... > } > > // Note: no more over_R and over_RA cluttering things up > > // Type-neutral wrapper, exposed in public API: > bool ImageBufAlgo::over (ImageBuf &R, const ImageBuf &A, const ImageBuf &B, > ROI roi, > int nthreads) > { > if (R.spec.format != FLOAT || A.spec.format != FLOAT || B.spec.format > != FLOAT) > return false; // only work on float bufs > ... > over<float,float,float> (R, A, B, roi); > return true; > } > > > Now, this way would be float-only for now, easy to add other type support > later if we changed our minds, easy to expose the specializable template by > moving it to a header file, easy for people to COPY the specializable > template to their app (it's open source, after all) if some isolated user > needs it. > > > > On Jun 29, 2012, at 3:55 PM, Chris Foster wrote: > >> On Sat, Jun 30, 2012 at 5:41 AM, Larry Gritz <[email protected]> wrote: >>> Still, I am haunted by a key question: does the support of all the >>> types merely seem nice and general to us idealists, or does anybody >>> actually want and need such functionality? >> >> Ah, simplicity vs generality... always a hard call :) >> >> Given that the non-float code isn't currently used by oiio, it's pretty >> tempting to go with the float-only option. OTOH, I'm sure there's plenty >> of OIIO users who never contact us so it's pretty hard to assess whether >> anybody wants this feature. >> >> >> Here's a further option we haven't considered: Expose versions of the >> IBA operations with explicit types (but in a separate header >> imagebufalgo_templates.h or something). For example: >> >> template<typename RPixelT, typename APixelT, typename BPixelT> >> bool over_typed (ImageBuf &R, const ImageBuf &A, const ImageBuf &B, >> ROI roi = ROI(), int threads = 0); >> >> >> A float implementation of over() exposed by imagebufalgo.h would then >> look like >> >> #include "imagebufalgo_templates.h" >> bool over (ImageBuf &R, const ImageBuf &A, const ImageBuf &B, >> ROI roi, int threads) >> { >> return over_typed<float, float, float>(R, A, B, roi, threads); >> } >> >> >> Pros: >> * Makes simple usage simple, complicated usage possible. >> * Let's users of the API instantiate *exactly* the set of >> specializations they're interested in. >> * Reduces implementation complexity by removing the code >> which deals with the cross product of types. >> >> Cons: >> * Forces (at least some of) the implementation details into a >> public header. Ugh! >> >> >> I'm not sure whether this is nice or ugly. Either way, it's an extra >> option to consider. >> ~Chris >> _______________________________________________ >> 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
