RSS/Atom feed Twitter
Site is read-only, email is disabled

Fractional coordinates

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

Fractional coordinates Henning Makholm 15 Jun 01:35
  Fractional coordinates Nathan Carl Summers 15 Jun 11:25
Henning Makholm
2002-06-15 01:35:09 UTC (almost 22 years ago)

Fractional coordinates

I have submitted a bug (#84145) and a couple of patches about pixel rounding when drawing straight lines. The debate in the bugzilla comments seem to be about to turn into a design argument about subpixel positioning, which I think it would be more convienient to have through a mailing list than a bug-tracking system.

The current status of the Gimp:

1. The position for a mouse button press is converted to a floating-point value i such a way that the FP coordinates refer to the upper-left corner of the area on the image that is covered by the actual display pixel the mouse is pointing to (with the displayed zoom and all that).

2. The paint tools (pencil, paintbrush, eraser, & friends) simply use these floating-point coordinates for the center of the brush.

3. Consequence of (1) and (2): When one paints a single click with the paintbrush and a 1x1 brush in 1:1 zoom mode, what one actually gets thanks to brush subsampling is a block of four image pixels each being painted by 25%.

4. The same floating-point coordinates are used as endpoints of the lines that are drawn when Shift is pressed.

5. For the preview line, the endpoints are rounded to nearest pixel centers (which can be easily seen in zooms greater than about 500%), but this rounding is not performed when the paintcore actually draws the line.
(There's another bug with the preview lines, but that is on the order of one display pixel, not an image pixel).

6. As a consequence of (1) and (4), SW-NE lines drawn in 1:1 zoom will get displaced by one pixel to the NW relative to the ideal line between of the centers the user actually clicks on.

7. As a consequence of (1) and (5), the user does not always get the line he is hoping for when he tries to draw a line in highly zoomed mode (because the preview line does not look like the subpixel position of the mouse is important when the button is clicked).

Here are some opinions about this:

a. The current behavior is clearly not internally inconsistent. Something has to be done. We need some kind of consensus about what "something" actually is, though.

b. I think of (1) as a bug in and of itself. The FP-coordinates that a mouse position is translated into should be the coordinates of the image point beneath the *center* of the display pixel. Would anything break if this is fixed generally? I.e., does anyone depend on the ability to point the mouse exactly on an image-pixel boundary?

c. The painting tools that do not subsample their brush will instead round the brush center to the nearest pixel center each time a brush "dab" is drawn. There seems to be little argument that the also ought to round the endpoints of a straight line to pixel centers before computing the intermediate points on the line.

d. Apparently there are people who want to be able to draw straight lines between non-pixel-centers with the tools that do subsample brushes.

e. On the other hand, I personally think it is also important to be able to draw anti-aliased lines between image-pixel centers without having to succumb to finger cramps because the *display* pixel smack in the middle of the desired image-pixel must be hit precisely in with a pointing device. Some mice are a pain to position more precisely than 2-3 pixels, and exactly a zoom mode is what one would hope could mitigate that for precision editing.

f. Possible ways to reconcile (d) with (e) would include - Adding a tool option that says whether line endpoints (and even non-shift keypresses?) get rounded to pixel centers or not. But down that way lies madness, or what? - Defining a modifier key (meta?) to mean "round mouse positions to image-pixel center". Which would mean that to draw a 15-degree-constrained straight line between pixel centers one would need holding down *three* modifiers. Both these designs seem to be somewhat lacking in elegance.

Thoughts, anyone?

Nathan Carl Summers
2002-06-15 11:25:05 UTC (almost 22 years ago)

Fractional coordinates

On 15 Jun 2002, Henning Makholm wrote:

b. I think of (1) as a bug in and of itself. The FP-coordinates that a mouse position is translated into should be the coordinates of the image point beneath the *center* of the display pixel. Would anything break if this is fixed generally? I.e., does anyone depend on the ability to point the mouse exactly on an image-pixel boundary?

It would certainly change how guides work. Not a big deal, because guides can be changed to go to the center of the pixel. I'm mostly just bringing this up so that it won't be overlooked. ;)

Rockwalrus