Re: [Gimp-developer] patch for scale-region.c

2008-08-30 Thread gg
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



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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] patch for scale-region.c

2008-08-30 Thread Alastair M. Robinson
Hi :)

Geert Jordaens wrote:

 The code is not interpolating rather resampling (supersampling in case 
 of lanczos and bicubic) in the case of scaling down.

OK - perhaps I'm misunderstanding the approach taken here, then.

As with interpolation, the Lanczos/Bicubic functions are being used to 
fit a parametric function to the original discrete samples, yes?

The question is how is this function then used?  Is a single sample 
taken from it for each sample of the scaled-down image, or is the 
function integrated over an appropriate interval for each sample?

I'd assumed, perhaps incorrectly, that the former approach was being 
used, and if so, then a simple box-filter should be more accurate; if 
the latter, however, then I'd expect the results to be better than a box 
filter.

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] patch for scale-region.c

2008-08-30 Thread Alastair M. Robinson
Hi :)

[EMAIL PROTECTED] wrote:

 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.

I think these are aliasing artifacts caused by high-frequency components 
in the original image - unless you take steps to remove frequencies 
higher than the target sample rate before resampling a signal, aliasing 
will result.  And as you noted, it affects my code too.

Reducing that effect required some form of low-pass filtering before 
scaling - to remove the high frequency components which can't be 
represented in the lower-resolution image.

Here's another version of the 3% reduction image, with a 33 radius (100% 
/ 3%) gaussian blur applied before the reduction:

http://www.blackfiveservices.co.uk/3PercentPreBlur.png
I also note that my original 3% version was one pixel narrower than 
Sven's, so here it is again:
http://www.blackfiveservices.co.uk/3Percent.png

 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.

I suspect that's just the result of a cleaner, single-stage reduction 
with the aliasing artifacts on top.

 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.

Chances are it would be low-pass to some degree, so arguably a 
beneficial side-effect, even if a designed filter would be an improvement!

All the best,
--
Alastair M. Robinson

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


Re: [Gimp-developer] Proposal for 2.6 splash screen.

2008-08-30 Thread Villu Villuvillu
A splash screen proposal from me, too:

http://i262.photobucket.com/albums/ii93/peculiarapparat/Gimpsplashy.png

Done (obviously) fully in GIMP.

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