Re: patch for scale-region.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


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

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux