Sven Neumann wrote:
> Hi,
>
> On Thu, 2008-08-28 at 22:38 +0200, Geert Jordaens wrote:
>    
>   
>> What are your doubts with the new code? Why would a simple box-filter be 
>> better for decimating?
>>     
>
> My doubts with the current approach are manifold:
>
> The current code has decimation routines, but they are only suited for
> the special case of scaling down by a factor of 0.5. There are two
> problems with this:
>
>  (1) The code actually uses the special decimation routine not only
>      if scaling down by 0.5 in both directions, but also if the scale
>      factor is 0.5 in just one direction (and different in the other).
>
>  (2) If scaling down by 50%, a special algorithm is used (the said
>      decimation routines), but a very different algorithm is used when
>      scaling down by other scale factors (say 51%). This introduces
>      a discontinuity and gives quite unexpected results.
>
> The other grief I have with the current code is the way that the
> decimation routines are implemented. Let's have a look at the cubic
> interpolation code, the lanczos code has the same issue. What the code
> does is it calculates four weighted pixel sums for the neighborhood of
> the four source pixels that surround the center of the destination
> pixels. It then averages these four pixel sums. This is quite
> inefficient as exactly the same operation could be done faster and with
> less errors by calculating one larger pixel sum using an appropriate
> weighting matrix.
>
> My patch addresses these issues the following way:
>
> The decimation routines are replaced by a straight-forward 2x2 box
> filter. It also introduces special decimation routines to decimate in X
> or Y direction only.
>
> As already explained in my previous mail, the decimation routines are
> only used for the pre-scaling steps. As soon as the image is close
> enough to the final size, the chosen interpolation routine is used. This
> gives continuous results for all scale factors as there is no longer any
> special casing for scaling down by 50%.
>
> The main problem with the code in trunk is though that I think that the
> results of the new code are too blurry. Please have a look at the tests
> that I published at http://svenfoo.org/scalepatch/. And please try the
> patch and do your own tests.
>
> I will be away over the weekend. Hopefully a few people can do some
> tests in that time so that we can decide how to proceed early next week.
>
>
> Sven
>
>
>
>
>   
Thanks for the answers on my questions. I'd like to comment on them.

1. I agree that there is some optimisation to be done, I had already 
started a 1D version of the scale-region though did not find the time to 
test it completely.
2. The whole point of doing the scale by 2 was that in case of 
decimating a standard (integer) precomputed filter can be applied.
This a advantage for filters like bicubic and lanczos. The final scale 
step had to use the interpolation code.
 
As for testing the patch no luck here, I'm renovating my house (partly) 
this weekend.

Geert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to