GNOME Bugzilla – Bug 120490
Scale tool produces wrong output (misses parts of image)
Last modified: 2004-04-10 11:37:04 UTC
Scaling a layer when you need to scroll the window in order to get the size needed forces GIMP to display only part of a scaled image after transformation.
Sorry, I don't understand anything in this bugreport. Setting to NEEDINFO until the reported rephrases.
Suppose you have an image say 30x1000. Naturally, you zoom it, and it doesn't fit in a window. You select part of and try to scale across all 1000 points or centimetres or whatever. As mentioned before, you need to scroll the window to view all the image. So here is what I have done: 1) I moved the marker (square one - indicates an angle of selection during scaling) 2) Then I scrolled the window a bit. 3) I had to repeat these two steps 2 or three times until the marker have reached the desired position. 4)Then I pressed the 'Scale' button. So the image has scaled, but there were some gaps left in the scaled part, not filled with the color. I test it about 5-10 times on various image sizes.
You used the Scale tool with Interpolation set to None. The empty gaps you got are caused by this setting. Use Linear or Cubic to get rid of them.
I tried it with various types of interpolation. By the way, Interpolation set to None works fine when you do not have to scroll the window.
Guess we need to reopen the report then and the reporter will have to try to come up with a better explanation of what he thinks is going wrong here.
The fact that scrolling is involved suggests this could be a duplicate of bug #116765. Eugene, would you check if the bug is still there in 2.0pre2 (as soon as it is out, probably tomorrow).
We are waiting for feedback from the bug reporter here.
Still getting almost the same error:( The main difference is that now it misses only the beginning of the selection. Here goes step-by-step procedure: 1) Create empty image with alpha channel, say 1000x10px 2) Zoom until you need to scroll 5 or 6 screens in order to view the entire image. 3) select a rectangle from the beginning (left side) of the image and fill it with gradient. Like this: [xx ], where xx - the filled part. 4) now select scale tool, set it to bicubic and try to scale the selected area (filled with gradient) to the entire image. I.e. try to achieve this: [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] Naturally, you have to scroll the screen to move the scale mark to the right side of the image. 5) Instead of expected image, you'll get something like: [ xxxxxxxxxxxxxxxxxxxxxxxxxxx] Note the missing part in the beginning of the image.
I can reproduce this behaviour with current CVS. And you don't need to zoom in or out to reproduce it
We can bump this to 2.0.1 if we don't manage to fix before 2.0.
Bumping a bunch of bugs which won't block the 2.0 release to 2.0.1. Dave.
There apparently is a wrong 0.5 px offset lurking somewhere. Scaling a 50 pixel wide image to a width of 1000 px results in a 9-10 pixel displacement (= 0.5 * scale factor 20) at the left, s, and the right edge fades (also for about 10 pixels) into transparent, as if there would be taken half of a transparent source-pixel into account. Interpolation-type = None does not show this behaviour.
Comparing a scaled layer (layer->scale layer) with the results from the scale tool shows, that the "inner" image content is scaled correctly (no 0.5 offset), it is just the border handling that is wrong.
Created attachment 26382 [details] [review] patch for app/core/gimpdrawable-transform.c Attached is a patch that seems to solve this problem. The code is exceptionally complex, though, and is used for all of the transform tools, so my confidence is not high that it does not cause something else to break.
The addition of 0.5 was not present in the original code that was introduced with revision 1.61 as part of a patch to fix bug #109817. It was added with revision 1.63 as part of a commit from Pedro with the following comment: * app/core/gimpdrawable-transform.c (gimp_drawable_transform_tiles_affine): Fix copy'n'paste slip in coordinates calculation for supersampling code. Transform the pixel centers properly. Fixes bug #10466. Applying the attached patch bears the risk to reopen this bug.
After some testing I could not reproduce bug #10466 either with or without the patch, so it seems like an enhancement. Probably my introduction of the -0.5 offset in the surrounding pixels was bogus. As Bill says, the code is quite complex, and I'm not confident about its correctness either patched or unpatched. My intention was to shift the source coordinates to the pixel centers but I observed the introduction of a bias which I tried to correct. After applying the patch the transform behaves as expected under several testing conditions. I made rotation/scaling/shearing tests with this image: http://bugzilla.gnome.org/attachment.cgi?id=25422&action=view and an odd-sized version, plus the testcase described in comment #8.
I'd say we commit it then.
I've applied Bill's patch; closing this bug now. Please reopen if something is still wrong; I may have missed something. 2004-04-10 Pedro Gimeno * app/core/gimpdrawable-transform.c (gimp_drawable_transform_tiles_affine): Applied patch from William Skaggs that addresses bug #120490. * app/sanity.c (sanity_check): Modified the message that reports an old version of Fontconfig in an attempt to make it more informative.