Objects are half a pixel off

[macosxp]

I've noticed this problem in Inkscape 0.47 (on Mac OS X) that sometimes objects are half a pixel off, vertically or horizontally or both. This makes it so that an object with integer-value dimensions and positioning can have blurry edges and look blurry even when exported as PNG.

[su_v (suv-lp)]

Objects in Inkscape do not snap to full pixel values by themselves: you have to take care of this yourself, if it matters (e.g. by snapping to grid -- using a second grid offset by half a pixel, or snapping the bounding box instead of the nodes to the default grid):
<http://wiki.inkscape.org/wiki/index.php/FAQ#How_to_suppress_antialiasing.3F>

Inkscape now includes the 'Pixelsnap' extension (Extensions > Modify Path) which allows to adjust objects to avoid anti-aliasing effects when exporting to bitmap (doesn't work for text objects):
<http://code.google.com/p/pixelsnap/>

[macosxp (ariel18)]

Well, as I stated, I had set the pixels to full pixel values myself.

PS I tried Pixelsnap and it didn't set the object to a full pixel position correctly.

[su_v (suv-lp)]

>> noticed this problem problem in Inkscape 0.47
> Inkscape now includes the 'Pixelsnap' extension (…)

'now' means current stable version: Inkscape 0.48
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48#New_and_improved_extensions>

[su_v (suv-lp)]

> Well, as I stated, I had set the pixels to full pixel values myself.

Can you attach a sample file?

[su_v (suv-lp)]

> Well, as I stated, I had set the pixels to full pixel values myself

… and tell the steps you used to "set the pixels to full pixel"?

[macosxp (ariel18)]

I only notice it from time to time, but yeah I'll keep this thread in mind for next time.

[su_v (suv-lp)]

The method used to "set the pixels to full pixels values" might matter.

Snapping nodes or bounding box corners to the grid works well and keeps the nodes / paths with integer stroke width aligned to the pixel grid [1]. There are however some known issues when changing the position or dimensions of a selection by entering numeric values in the entry fields on the select tool controls bar (or in the 'Transform…' dialog): for example a precise value might only stick after entering it three or more times; or changing the width or length (of horizontal or vertical lines) also effects the x and y coordinate.

[1] the concept of what snaps to what is important, as well as the type of bounding box used (Visual -- default, includes stroke width, or Geometric). A rectangle with a stroke width of 1 px node-snapped to the grid is still anti-aliased on export to PNG because each edge of the stroke is 0.5 px offset from the path centerline and the rendered path not aligned with the pixel grid.

[macosxp (ariel18)]

I do have an update to this bug. It applies to embedded/linked raster images, not vector ones.

[Pablo Trabajos (pajarico)]

> It applies to embedded/linked raster images, not vector ones.
That's kinda odd. It should happen to *both* vectors and bitmaps. In fact it shouldn't be related to the type of object but rather its position and size (as ~suv pointed out in comment #7).

Please macosxp, provide a sample file. Meanwhile I'm setting this as "Incomplete". Feel free to revert the status after you've provided the information.

[su_v (suv-lp)]

In hindsight possibly the same underlying cause (copy&pasted vector objects are pasted as bitmaps on osx due to bug #307005) as in Bug #675438 in Inkscape: “Copy and paste produces changes”.

[Pablo Trabajos (pajarico)]

So maybe there two bugs here? One about half pixel offset, the other about forceful rasterizing of copy and pasted objects.

Related to the first:
Bug #170356 “Suppress antialiasing artefact at the object boundary”
Bug #170392 “Advanced antialiasing control & font hinting”
Bug #561857 “[wish] new "boxmodel" for grid alignment (1pixel border issue)”

[su_v (suv-lp)]

> So maybe there two bugs here?

We won't know until there's an example SVG file attached to allow further investigation (yes, I should have asked for it before adding my initial comments).

macosxp wrote on 2010-12-12:
> It applies to embedded/linked raster images, not vector ones.

Note that the upper left corner of an image needs to be at an integer-value position (the other corners and the width/height values don't really matter if the bitmap image has the original size from importing). Any scaling of the bitmap image will additionally change the precision of its content (affected by the preference setting for oversampling of bitmaps).
If on the other hand the affected bitmap images had not been pasted or imported intentionally, see bug #675438 (comment #2).

macosxp wrote on 2010-11-07:
> I tried Pixelsnap and it didn't set the object to a full pixel position

There's also a known bug in PixelSnap (apparently transform attributes of a parent node (e.g. the layer group after resizing the page) are not correctly considered):
<http://www.inkscapeforum.com/viewtopic.php?f=5&t=6309#p29192>
<http://code.google.com/p/pixelsnap/issues/detail?id=9>

[su_v (suv-lp)]

Clarification:
> the upper left corner of an image needs to be at an integer-value position

This refers to the coordinates as stored in the SVG source (origin top left corner of the page, values in px, y-axis pointing downwards).

[macosxp (ariel18)]

I'm adding some files for reference. imported_lines.svg is the file that has an embedded png file. screenshot.png shows how it looks in Mac OS X Snow Leopard, Inkscape 0.48.1, where the image appears 0.5 pixels off vertically when viewed at 100%. lines.png is the raster file used as an example. Note that if I try to export the page, even though it looks blurred (due to being 0.5 pixels off) when viewed in Inkscape, it exports properly. However, this could be a problem when working with raster images and the designer tries to make it look proper in Inkscape only to find that his image exports blurry.

[macosxp (ariel18)]

"In hindsight possibly the same underlying cause (copy&pasted vector objects are pasted as bitmaps on osx due to bug #307005) as in Bug #675438 in Inkscape: “Copy and paste produces changes”."

This is different. The problem with objects being pasted as bitmap was annoying, but I had updated my own X11 preferences as per https://launchpadlibrarian.net/36209214/XQuartz-clipboard-preferences.png to deal with that. This is different and doesn't have to do with copy/paste, this has to do with imported raster images. Note that I say imported rather than embedded because linked images have the same problem (appearing 0.5 pixels off vertically at 100% zoom on Mac OS X).

[su_v (suv-lp)]

fixed version (manually snapped top left corner of the imported image to the SVG pixel grid (moved to new layer))

Underlying issue: the document page was resized to the imported image without having it aligned to the pixel grid first:

  <g
     inkscape:label="Layer 1"
     inkscape:groupmode="layer"
     id="layer1"
     transform="translate(-240,-799.36218)">

which then causes the image to be off of the SVG pixel grid if rendered as SVG on-canvas (but not when exported to PNG because both the page size and the image have integer pixel sizes):

    <image
       y="799.36218"
       x="240"
       id="image3289"
       xlink:href="data:image/png;(…)"
       height="40"
       width="300" />

AFAIU the problematic value triggering the on-screen antialiasing are both y-values (for the layer transform as well as the image y-coordinate).

[su_v (suv-lp)]

'Extensions > Modify Path > PixelSnap…' as shipped with Inkscape 0.48.1 does work with the example file attached in comment #14 and in my tests causes precise rendering of the bitmap image on-canvas as well as in exported bitmaps (page & drawing area).

[macosxp (ariel18)]

While PixelSnap does make it appear correct in the live preview, all it does is set the y position to 0.362, so I don't understand how that can be a solution. I also don't fully understand what the underlying issue is. Maybe I was just starting out with a messed up file (I have a custom default svg file open on load), so I will look into that. But, it seems weird to me how the problem could happen in the first place. Is there an Inkscape bug here that others could potentially have a problem with as well?

[su_v (suv-lp)]

> I also don't fully understand what the underlying issue is.

Inkscape uses two coordinate systems:
1) SVG coordinate system: origin in the upper left corner of the page, y-axis pointing down (left-handed system)
2) GUI coordinate system: origin lower left corner of the page, y-axis pointing up (right-handed standard Cartesian system)

If the page height is modified (or the complete page area gets resized to selection/drawing) the GUI origin is kept "fixed", and all drawing content keeps the relative distance to the lower left corner of the page as displayed on-canvas.
As a consequence, the SVG origin needs to be 'moved' (or all objects need to be translated relative to the SVG origin): the top-level layers and objects are moved relative to the SVG origin at the time of their creation (the layers for example, which are basically regular SVG groups, get a 'transform' attribute which translates the content of the group so that it matches the new position of the SVG origin in relation to the GUI origin).

If the page height is not an integer value, this will have the consequence that the integer pixel values as displayed in the GUI will not represent integer pixel values if expressed in SVG coordinates (in the end that's how the values are stored in the SVG source). Thus objects which have their upper left corner aligned to the visual pixel grid in the GUI are not necessarily aligned to the SVG pixel grid.

The current implementation of GUI vs SVG coordinate system is legacy code from SodiPodi, difficult to fix without breaking the rendering of old files and tracked elsewhere (bug #170049).

[su_v (suv-lp)]

'Preferences > Bitmaps: Oversample bitmaps' (default 2x2) does also influence the rendering of embedded / linked bitmap images on-canvas: with your example file, the narrow 1px-wide lines in the bitmap (not aligned to the SVG pixel grid) rendered with default oversampling (2x2) shows extreme blurriness at 100%, no oversampling or a higher rate does improve the rendering on-canvas at zoom level 100%.

[su_v (suv-lp)]

With regard to oversampling, see also:
<http://www.inkscapeforum.com/viewtopic.php?f=5&t=7613>
<http://article.gmane.org/gmane.comp.graphics.inkscape.user/10890>

[su_v (suv-lp)]

- <http://www.inkscapeforum.com/viewtopic.php?f=5&t=7613>
+ <http://www.inkscapeforum.com/viewtopic.php?f=5&t=7613#p29399>