GNOME Bugzilla – Bug 170760
Setting guides to arbitrary sub-pixel positions
Last modified: 2018-05-24 11:29:06 UTC
The ability to select a guide and actually type in its desired position would be much appreciated. Also, the guides seem a little misaligned when you zoom in real close and look at the rulers, the readout at the bottom says its at 170.0 px but when you look at the ruler it seems like its actually at 170.17, slightly off.
I've checked this with 25600% zoom and the guides are not the slightest bit misaligned. An offset of 0.17 would be really noticeable at this scale. I've also seen no offset at any level in between. There is a menu entry in the Image menu that allows guides to be added at precise (pixel) locations, or at a certain percentage of the image width. What's missing is the ability to move the "active guide" - there is no PDB function for getting this guide (I don't know if such a guide exists at all). Maybe the summary of this request should be adjusted to refelct what really has to be done.
There is no active guide. That's only a visual thing on the display done by the move tool.
I'm going to resolve this as NOTABUG on the grounds that (1) the guides are not actually misaligned, and (2) you can get a guide to a specified location by dragging the existing one off the image and using the menu entry described in comment #1 to generate a new one. It may be worth noting, though, that if the alignment tool attached to bug #147437 makes it into GIMP, it will eventually have the ability to align existing guides with various things using user-specified offsets. If in spite of comment #1 you still think the guides are not being drawn in the right place, please provide a screenshot that shows it, and feel free to reopen this bug report.
Created attachment 39110 [details] image of wrong guides
Comment on attachment 39110 [details] image of wrong guides the ruler and guides seem a little wrong zoomed in at 25600%, see the attatched pic, the readout at the bottom says its 25.0 and its clearly not. Also, the guides sometimes do this annoying thing where it wont allow me to move it to say 50.0, but will keep jumping to either 49.9 or 50.1 . You should be able to move guides smaller distances than 0.1....
Guides are actually located between pixels rather than centered on pixels, so when a guide says 25.0, it is actually located at 25.5. This is assuming that the units are pixels -- if your units are something else, please say so. Anyway, I agree that this is a bit confusing, and as another bug report points out, for some purposes (mainly paint tools) it is not what you want. For selection tools, it is exactly what you want. Could you explain why you want to move guides fraction-of-a-pixel distances, given that any operation you do acts on whole pixels? I can imagine reasons, but I would like to understand your reasons.
I am working in mm, sorry about that, I meant mm not px. I want it perfect cause Im going to be stting up a label and the guy Im doing it for wants perfection.
Ok, so this is an enhacement request for being able to set guides at aribtrary positions depending on the currently selected unit.
I don't see how this relates in any way to the unit. This is a request to place guides at sub-pixel positions.
You cannot set anything in GIMP to sub-pixel positions, so what's the point of being able to place guides there?
Path anchors can have sub-pixel positions, and so can paint application points.
OK, the thing I am really concerned with is the fact that when I set a guide at 100.0 pixels, mmm, whatever, when I zoom in and look, the guide is obviously not at exactly 100.0 mm px etc. I dont really want to set guides at 100.5, but when I set it at 100.0, it should be exatly 100.0, no matter how close I zoom in. And when I am moving a guide, it should not skip values, like I said, annoyingly not allowing me to set it at 100.0, but only 99.9 or 100.1, which is useless.
I cannot reproduce this. No matter how far I zoom in, the guides are always between pixels. Real world units are a different issue. Matthew, do you really see guides which at not at exact *pixel* positions?
The problem is that the guides are not at exact mm positions. That's why I changed the summary... If guides could be assigned arbitrary unit, e.g. "20 mm", GIMP could always choose the closest pixel representation. It would have to communicate that this is not the exact location, though. However, the higher the ppi value, the more accurate it could be.
I was referring to comment #12. The reporter makes no difference between pixels and other units. Just wanted to be sure.
Anyway, it seems a matter of doing 26 - gint position; 26 + gdouble position; in app/core/gimpimage-guides.h (and changing XCF loading code to deal with this). I've been trhoug the guides code lately - I could test this, but can't generate a patch from here - all the files that touch guides are modified in my tree.
The main question is what happens to selection tools (i.e., rect select), which were coded with the assumption that guides would be located at half-integer-pixel locations.
And we would need some kind of guide snapping - it is useful to snap to whole or half (or other specific fractions of) the unit. Different bug for this, though.
Comment #17: All code asumes that guides are in between pixels, not at half-integer positions. In case there is any confusion: the pixel located at (0,0) extents from [0.0..1.0[ in both dimensions and it's half-way position is at (0.5,0.5)
I set the document units to mm. Just look at the attatchment i posted earlier. The readout says that the guide is at 25.0 mm. that doesnt look like 25.0 mm to me. Is it really that hard to get the real world measurements and the pixel measurements working in tandom?
Since it is completely trivial, you will certainly send us a patch that fixes it.
There are two ways to "fix" this now: - make the value in the staus bar more precise (24.0314159 mm) - implement sub-pixel or real world unit guides as described
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/138.