Hi,
after spending quite some time with the new scale code, I have some
doubts about the way that it is scaling down. So here's a patch that I
am playing with at the moment:
http://sven.gimp.org/misc/gimp-decimate.diff
This patch applies against SVN trunk. It only changes the current
behavior w
Sven Neumann wrote:
> Hi,
>
> after spending quite some time with the new scale code, I have some
> doubts about the way that it is scaling down. So here's a patch that I
> am playing with at the moment:
>
> http://sven.gimp.org/misc/gimp-decimate.diff
>
> This patch applies against SVN trunk. It
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 speci
Hi,
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 th
Hi
Sven Neumann wrote:
> 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
Alastair M. Robinson wrote:
> Hi
>
> Sven Neumann wrote:
>
>
>> 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 continu
Sven Neumann wrote:
> 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
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 t
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
>> f
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
f
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
On Sat, 30 Aug 2008 19:35:20 +0200, Alastair M. Robinson
<[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. Th
Hi,
while I see your points and I appreciate your comparisons of the
results, fact is that the current code has bugs that are fixed by my
patch. The most apparent problem is that the current code is using the
2-dimensional decimation routines even when downscaling only in one
direction. To see thi
Hello Sven:
> ... To see this, create a new image, apply a standard grid on it
> using Filter->Render->Patterns->Grid and scale it down in one direction
> by a scale factor smaller than 0.5. The one pixel wide grid lines will
> become blurry. I don't think this is acceptable and so far the only
>
On Sat, 06 Sep 2008 00:22:58 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> while I see your points and I appreciate your comparisons of the
> results, fact is that the current code has bugs that are fixed by my
> patch. The most apparent problem is that the current code is using the
> 2
Hi,
On Mon, 2008-09-08 at 10:04 +0200, [EMAIL PROTECTED] wrote:
> Clearly trapping the special case of only scaling in one dimension is a
> worthwhile optimisation. That would seem to be a separate issue from
> fundementally changing the scaling algo. Could I suggest you break these
> two c
16 matches
Mail list logo