> 1. Merge into 0.10, or not? I'd hate to set the precedent of breaking the external ABI in a stable build. But, it's so early in the 0.10 lifetime that I'd hate to see them diverge so soon. (And I want to use this change in a stable 0.10 build asap).
How about meeting half way? We could tweak this commit a tiny bit (for 0.10 only), so we could maintain ABI compatibility with the last 0.10 version, but also have updated functionality. The only API call that's changed is imagebufalgo::resize. I would recommend we leave it signature alone for 0.10, and just start ignoring the filterwidth parameter. The code for maketx would be unchanged. (This is why I hate default args in C++, it would have been easier to have both the old and new signatures co-exist, but in this case its not an option). I've mocked up the changes here, and confirmed it all works: https://github.com/jeremyselan/oiio/tree/js-filter-0.10 The other nice part of this approach is that the old signature is still forwards compatible with new code, so future master -> 0.10 cherry picks should merge cleanly. -- Jeremy On Thu, Jun 23, 2011 at 4:54 PM, Larry Gritz <[email protected]> wrote: > https://github.com/OpenImageIO/oiio/pull/108 > > This eliminates the silly 'width' argument to maketx --filter : now you just > specify the filter name, and it chooses the appropriate width. Also > augmented the Filter classes with some static methods that let an application > query what filters are available and some vital stats about each of them > (including a recommended width, whether it is scaling or windowing, and so > on.), and some very minor cleanup to ImageBufAlgo::resize to eliminate a > redundant parameter. > > Oops, I forgot to post this to the mail list. It's already got a LGTM from > Jeremy, but I wanted to give others a chance weigh in. There are actually > two outstanding issues that might merit some discussion: > > 1. Merge into 0.10, or not? It's got a very minor change to the > ImagBufAlgo::resize function (eliminated a redundant parameter) and of course > a change to the command line arguments of maketx. Of course, both are new > items themselves, so maybe changing them is not going to cause pain to anyone. > > 2. Right now, the same filter is used for both the MIPmap generation as well > as the upscale to power of 2. On one hand, in an ideal world you'd use > different filters for these -- perhaps a lanczos3 for the MIP generation > (downsampling) and Blackman-Harris or bspline for the upsampling. But I > don't know if you'd ever really notice a problem if you used the same for > both, and the pow2 upsampling is both optional and not particularly > recommended. So I'm tempted to live with this limitation (same filter for > both), but if somebody complains and has an example texture that it doesn't > work well for, I can later add a --upresfilter or something to allow that to > be separately specified. Any objections? > > -- > 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
