GNOME Bugzilla – Bug 10466
I have some pb with rotation
Last modified: 2009-08-15 18:40:50 UTC
Package: gimp Version: 1.1.20 Name........: Martin Email.......: jpmartin@iroise.com Platform....: linux 2.2.14 Mandrake 7.0 GIMP Version: 1.1.20 GTK Version.: 1.2.6 WM/Version..: kde 1.1.2 or E 0.16.3 -- Other system notes: -- -- Problem description: When i take a small picture (20X20) with a zoom 1600%, i have some problem with rotation. I have some pixels who disappear ! The picture is a 0.0 (RGB) 1600% (i read the indication of gimp !) It is not beautiful when i do a rotation of 90 deg ! -- -- How to repeat: Take a 20X20 RGB picture. Rotate it with a angle of 90 deg ! -- -- Other comments: The Gimp 1.0.4 do that very well ! -- ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 10:51 ------- This bug was previously known as bug 10466 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=10466 Originally filed under the gimp product and general component. The original reporter (jpmartin@iroise.com) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, egger@suse.de.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Fixed this in CVS HEAD. Not closing the bug because I'm still thinking about if and how to backport this to stable... 2002-02-19 Michael Natterer <mitch@gimp.org> Fixed #10466 (disappearing pixels when rotating by 90 deg): * app/core/gimpdrawable-transform.c: when transforming backwards to find the destination line's sub-pixel source coordinates, we need to transform the pixels _center_, not it's upper left corner. * app/core/gimpdrawable-transform-utils.[ch]: added gimp_drawable_transform_matrix_rotate_center() which takes double center coordinates instead of an integer pixel bounding box. * app/tools/gimptransformtool.[ch]: use double instead of int for all coordinates except the original bounding box. * app/tools/gimprotatetool.c: use double whenever touching the "center" value, so it can be sub-pixel positioned.
Good that I didn't backport it yet... 2002-02-20 Michael Natterer <mitch@gimp.org> Oops, yesterday's "fix" for #10466 made it even worse :) * app/core/gimpdrawable-transform.c: need the 0.5 offset to the pixel's center only for INTERPOLATION_NONE, as the LINEAR and CUBIC algorithms already know about their errors. * app/tools/gimpperspectivetool.c * app/tools/gimpscaletool.c * app/tools/gimpsheartool.c: some more s/gint/gdouble/ so the tools can detect pointer motions again...
Has this been backported yet? I'm sorry, I currently just have 1.2.3 available and cannot doublecheck, but this should be fixed before 1.2.4 reaches the world...
Here's a patch against current CVS STABLE branch that solves this particular problem. There are some issues pending in the HEAD branch, but that's the subject for a different report.
Created attachment 16242 [details] [review] Solves rotation center problems in 1.2 CVS
Note that the problem will persist with odd-sized images because the rotation center must be an integer and thus can't be in the middle of a pixel. So it would be very good to complement this patch with a backporting of the gint-to-gdouble changes that Mitch did, at least for the rotation center.
The patch is surely an improvement, please commit.
Partial fix submited (works for even-sized images). Will work for all kinds of images when (if) the center coordinates are converted to gfloat. I'm leaving this report open; please close if that last issue is a WONTFIX. 2003-05-05 Pedro Gimeno <usr352@wanadoo.es> * app/transform_core.c (transform_core_do): Deal with the pixel centers properly. Fixes bug #10466 for even-sized images. The change has been ported to 1.3 as well: 2003-05-05 Pedro Gimeno <usr352@wanadoo.es> * 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.
We don't want to backport the integer to double conversion from the HEAD branch. The remaining issue will not be fixed in 1.2. Closing this report as FIXED.
The (partial) fix is part of the stable release 1.2.4. Closing this bug.