After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 592628 - Scale Image adds asymmetric artifacts to image edges
Scale Image adds asymmetric artifacts to image edges
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
2.6.6
Other All
: Normal normal
: 2.8
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2009-08-21 21:03 UTC by Anders Kaseorg
Modified: 2018-01-02 22:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Partial fix (749 bytes, patch)
2009-08-22 14:55 UTC, Massimo
committed Details | Review
Testresults with 2.8.4 (24.90 KB, application/binary)
2013-03-19 18:38 UTC, gedon
  Details

Description Anders Kaseorg 2009-08-21 21:03:59 UTC
Create a 3×3 white image and color the center pixel black, then scale the image up to 9×9.

• With Linear interpolation, a gray pixel (#e2e2e2) is present at the top left corner.
• With Cubic interpolation, there are many gray pixels along the top and left edges.
• With Sinc (Lanczos3) interpolation, the top and left edges are colored not-quite-white (#fefefe), while the bottom and right edges are white (#ffffff).

Now create a 9×9 white image and color the center 3×3 block black, and scale the image down to 3×3.

• With Linear, Cubic, or Sinc interpolation, the pixels on the top and left will be much lighter than the pixels on the bottom and right.

The latter problem can be reproduced with larger images and doesn’t only happen on the edge; it suggests that the entire image is being shifted down and right by some subpixel offset.

I’m using gimp 2.6.6-1ubuntu2 on Ubuntu Karmic amd64.
Comment 1 Massimo 2009-08-22 14:55:00 UTC
Created attachment 141422 [details] [review]
Partial fix

The first part of this bug report is easily fixed 
with the attached patch: there are a couple of cast 
of a double to int that should be changed with two 
calls to 'floor', the first rounds toward zero the 
second toward -infinity.

The second requires more work. The actual code
performs the decimation by initially halving 
repeatedly the image, but doesn't cope well with odd 
sizes. What you observe is the same you'd obtain 
if your initial image was 8x8 with the black square 
in the same position.

Patch against 'app/paint-funcs/scale-region.c' of 
release 2.6.7.
Comment 2 Martin Nordholts 2009-08-22 14:55:50 UTC
What can we do to help you start using git?
Comment 3 Martin Nordholts 2010-05-16 08:28:19 UTC
Review of attachment 141422 [details] [review]:

This kind of patching needs to come with test cases, otherwise we will reintroduce the original issue when fixing problems that this fix (pessimistically presumed) introduces.
Comment 4 Michael Natterer 2012-01-08 21:26:31 UTC
Massimo, what about the patch here? Should it go into git master?
Comment 5 Akhil Laddha 2012-02-22 10:03:48 UTC
Massimo, Martin, ping
Comment 6 Massimo 2013-01-27 16:01:38 UTC
Review of attachment 141422 [details] [review]:

This patch was committed to the branch gimp-2-8:

commit e09233f08074212db8994bfffbca6ec3ecbefe32
Author: Massimo Valentini <mvalentini@src.gnome.org>
Date:   Sat Oct 13 14:56:47 2012 +0200

    Bug 592628: Scale Image adds asymmetric artifacts to image edges
    
    first problem described.
Comment 7 gedon 2013-03-19 18:38:26 UTC
Created attachment 239297 [details]
Testresults with 2.8.4
Comment 8 Massimo 2013-03-20 11:18:24 UTC
(In reply to comment #7)
> Created an attachment (id=239297) [details]
> Testresults with 2.8.4

That pdf is wrong.

When upscaling 3x3 -> 9x9
With linear interpolation the central (5th) row contains:

255 255 170 85 0 85 170 255 255

as expected.

With Cubic and Lanczos the 3rd,7th rows/columns are not uniform 255
and the four corners having a different background suggest they're
wrong. But the point is: when you reconstruct and resample a downsampled
box signal, you don't get the box signal, you get an oscillating signal.
Having chosen white and black (255,0) for the original, you are missing
that values greater than 255 are approximated with 255 and values less
than 0 with 0. If you repeat the experiment with light and dark gray
(192,64) you'll see the typical ringing artifacts expected around hard
edges.
Comment 9 Michael Natterer 2014-09-10 22:22:20 UTC
Will this ever be fixed? I suggest we close it as OBSOLETE because that
code is completely gone in master. So unless somebody has the intention
of fixing it... Opinions?
Comment 10 Michael Natterer 2018-01-02 22:38:53 UTC
Closing as OBSOLETE as I suggested 3 years ago... Nobody will ever
fix this in 2.8.