OK, I like your plan. Would you care to do the two merges?
-- lg
On Jun 24, 2011, at 10:29 AM, Jeremy Selan wrote:
>> 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
>
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
