GNOME Bugzilla – Bug 576123
Scaling with interpolation "none" introduces unexpected offset
Last modified: 2009-03-24 12:31:13 UTC
Please describe the problem: When I scale an image with interpolation "none", the result is not as expected, In particular, the first column and row are about half the scaling factor, and the final column and row are about one and a half the scaling factor. Columns in between are the proper width. Examples: http://pages.infinit.net/leware/scaleNone.png These are screen captures of what GIMP is showing me. On the left, we have a 3x3 image, scaled 3200%. The boundaries between the pixels fall, as expected, at 0, 32, 64 and 96. On the right, the 3x3 was scaled to 96x96 (3200%), with interpolation = none. I would have expected the same result as on the left, but no. The boundaries are shifted 15 towards 0. The first row is 17 pixels wide instead of 32 (why not 16 is a sub question here), and the last row is 47 wide. What is the reason for this?! I stumbled on this problem while writing a script, and had to hack it to get the desired results. Just curious, no big show stopper. Thanks. Steps to reproduce: 1. Scale a (small) image with interpolation "none" 2. Look at the resulting image. 3. Actual results: http://pages.infinit.net/leware/scaleNone.png (right side) Expected results: http://pages.infinit.net/leware/scaleNone.png (left side) Does this happen every time? Yes Other information: Nothing specific to add. Except that debugging scripts in the Windows GIMP is painful. The slightest bug (eg. undefined variable) crashes GIMP. But that's another thread (which I'm sure folks are aware of).
Well, I'm using the latest SVN version of GIMP, and cannot reproduce this; the 3200% zoomed view is the same as 3200% upscaling with interpolation 'None'. Consider upgrading to the latest in the 2.6 series (2.6.6) and checking if it still happens. For the moment, consider scripting using the Python interface (Gimp-Python) instead. It is definitely superior to Script-Fu in debugging, especially since when you edit the script, your changes will be used the next time the script is called (and of course, if you mess up the script, the only thing that could crash is the plugin itself (usually harmlessly), without effecting your ability to continue to run and edit it)
This has long been fixed. Please do always update to the latest stable release before you report a bug. *** This bug has been marked as a duplicate of 556248 ***
I'm impressed, that was quick turnaround! I will upgrade and see if that fixes things (it will, I'm sure). Then I'll remove the hack from my script. > For the moment, consider scripting using the Python interface > (Gimp-Python) instead. I thought script-fu was *the* scripting language of GIMP, and so I made the effort to learn it (and my son kept telling me Lisp is the best language ever :-)). I knew none of the options (being an awk/sed fan essentially). I had read the comment that said that a script problem wouldn't take down GIMP, I guess that was only true for things other than script-fu. Actually, it wasn't all that painful, and my script now works fairly well (it's another 'engrave'). > This has long been fixed. But it seems it was only a few months ago that I downloaded GIMP, and I surely didn't select (intentionally) an older release. I guess things move fast! Actually, I was more expecting a response along the lines of "this is how it works, and here's why", given that this behavior was still there after years of GIMP being around. Possibly it's a recent bug. > *** This bug has been marked as a duplicate of 556248 *** I had seen this bug, but didn't realize it might be the same underlying problem. Anyway, either way not a problem, doesn't stop me from enjoying working in GIMP. Many thanks!