On Fri, 29 Aug 2008 21:33:45 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:
> 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.
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
Gimp-developer mailing list