On Fri, 29 Aug 2008 21:33:45 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:

> Hi,
> On Fri, 2008-08-29 at 14:15 +0200, Sven Neumann wrote:
>> I also started to play with some enhancements on top of the patch we are
>> discussing here. Using a steep gaussian filter instead of the plain box
>> filter seems to be a good compromise. It's better at suppressing Moire
>> patterns, at the cost of introducing a little blur. I have not yet
>> finished this patch though and it has some issues. It works for the most
>> common cases though and if someone is interested, it can be downloaded
>> here: http://sven.gimp.org/misc/gimp-decimate-2.diff
> In the meantime this patch has evolved and now also includes decimation
> routines that only scale in one direction. But currently I am still in
> favor of the first patch (gimp-decimate.diff).
> Long-term we should try to get rid of the multi-pass scaling approach
> and instead implement the scaling properly. But for 2.6, I'd like to
> suggest that we apply gimp-decimate.diff.
> Sven


I have not looked at this code in a while so I can't comment on how it  
does what it currently does, so I will only comment on the results you  

I have compared the results by opening the images in separte tabs in Opera  
at 200% which allows them to be viewed in exactly the same position and  
switch back and forth with one click. This allows a direct comparison  
without moving the eye. Any differences become instantly obvious. This  
seems to be the most effective way for the brain to react to differences.

Having looked at the 3% reductions which are probably the most critical  
(and make the most use of the binarly division in your patch) I not sure  
the results can be seen as superior.

Comparing Lanczos 3% old vs patched: lefthand building roof has bad moire  
effects that totally obscure underlying detail. Both sets of trees have  
much less obvious staircasing in the current code. There is an overall  
impression of sharpness in the new code but this seems really to be just  
high contrast artifacts with a lack of intermediate tones.

Observations are generally the same for the 3% cubic.

Similarly, a quick check on 50% cubic , old and patched, again at 200%.  
Just looking at the top left corner there are two dots. The current code  
renders them nice and round whereas the patch shows fairly ugly artifacts.  
Admittedly, these artifacts are high contrast but I see that as a defect  
not a feature. Surely creating the grey tones necessary to smooth out the  
pixelisation is the aim of decimation code.

Interestingly the blackfive code (thanks for sending the that algo  
Alistair) seems even harsher but does give some impression of sharpness by  
apparently accentuating edges.

If this is considered from an analytical , data processing perspective I  
can't imaginge what the frequency responce of this multipass approach must  
look like. It's hard to see how multipass binary division plus a final  
decimation filter can preserve more information than one, well designed  

Just a final obsevation to throw into the mix: I took the 3% lanczos and  
gave it 25% sharpen. The result is almost identical in overall appearance  
and contrast to the patched lanczos 3% but without the articfacts. I'm not  
sure what conclusions to draw from that but it's an interesting result.

My weekends scheduled for finishing a P.V. panel heliostat, so back to  
work now.


Gimp-developer mailing list

Reply via email to