On Fri, 29 Aug 2008 21:33:45 +0200, Sven Neumann <sven@xxxxxxxx> 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 > > Hi, 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 posted. 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 filter. 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. regards. _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
