Hi Friends,
I'm working on a project for a member in another topic. It involves importing a BMP image, and using it to draw a sort of template over top of it. The BMP was supposed to be the A4 doc size, and since my default template is in the landscape orientation, I had to change it to portrait orientation. If I don't make that change, the problem does not occur.

So the SVG is provided below, and the BMP as well, in case you need to test in another file. The BMP has been imported and embedded (not with the extension, but when imported). Open Align and Distribute dialog, and set it to Align Relative to Page. Then click Center on Vertical Axis and again on Center on Horizontal Axis. No problem.

Now open Document Properties and change the orientation to portrait. And now click the same buttons in Align dialog. See how the BMP becomes blurred? Sometimes when I try it, the blurring happens when just one button in the dialog is clicked, and other times, I have to click both buttons to make it happen. And in my several trials, the blurring is sometimes worse than other times. Sometimes it's barely noticable. But it seems to happen every time.

Since the problem doesn't happen if the page orientation has not been changed, I think it might be related to the transform attribute related bugs. The blurring of the BMP appears to resemble some of the rendering bugs I've seen. But since it doesn't happen in the document until the page orientation has changed, it seems not to be a rendering problem. But I'll leave it to ~suv and other experts, to sort out the details.

Oh, well it seems BMP format is not allowed for upload, so maybe you can extract it from the SVG is necessary.

Hi brynn,
I was not able to reproduce the issue which you have described in your post.

Just in case..
- New file in A4 size / landscape
- Import/embedded .bmp
- Align Relative to Page
- Changed orientation
- Align Relative to Page

here is the screenshot

and file


p.s.
I tried to use as much as possible similar .bmp as in your file. Originally, file size is 8,41MB.

Inkscape 0.48.2
Win7 32bit

I have found related topic, downloaded Rally100%.bmp and still it wont blur ,)
Let me know if I can be of any assistance on that matter/topic.

Interesting. Perhaps it was fixed, if it's even a bug in the first place?

It's all about bitmap images being aligned to the pixel grid of the SVG file…

brynn wrote: The BMP was supposed to be the A4 doc size, and since my default template is in the landscape orientation, I had to change it to portrait orientation. If I don't make that change, the problem does not occur.

We already know that your custom default template has a top-level layer transform right from the beginning - could you attach it here so that others trying to reproduce it can start with the same conditions?
(I am just assuming here that it is based on the default A4 page but with changed orientation, i.e. it might already have a non-integer offset (in px), even if you later adjust the document dimensions to integer px values. The DINA page sizes are based on other units than px and cannot be expressed as integer pixel values: for example, A4 is 744.09448819 x 1052.3622047 px).

brynn wrote:So the SVG is provided below, and the BMP as well, in case you need to test in another file. The BMP has been imported and embedded (not with the extension, but when imported). Open Align and Distribute dialog, and set it to Align Relative to Page. Then click Center on Vertical Axis and again on Center on Horizontal Axis. No problem.

Now open Document Properties and change the orientation to portrait. And now click the same buttons in Align dialog. See how the BMP becomes blurred? Sometimes when I try it, the blurring happens when just one button in the dialog is clicked, and other times, I have to click both buttons to make it happen. And in my several trials, the blurring is sometimes worse than other times. Sometimes it's barely noticable. But it seems to happen every time.

Basic Math:
The image has the size of 726 x 987 px, the document size of your attached file is 1000 x 700 px.

If you center the image relative to this page size, it is bound to be not fully aligned to the pixel grid (ignoring any layer transforms for now):
landscape page:
orientation changed to portrait:
Either way, it would make sense to apply 'Extensions > Modify Path > PixelSnap' to align the bitmap image with the (vertical) pixel grid, after centering it on the page.

GUI versus SVG coordinate system:
The 'crispness' of embedded or imported bitmap images depends mostly on the absolute position of its upper left corner in the final SVG coordinates. The current situation of having two coordinate systems (GUI vs SVG) hides this fact from the user. Additionally, the GUI and SVG origins can be offset by a non-integer px distance. As far as I understand, one goal of the externally developed extension 'PixelSnap' is to take care of this and allow adjusting the position of the bitmap image precisely to the actual SVG pixel grid.

In your attached sample SVG file, the layer 'Layer 1' always has a transform attribute (with landscape page, it is 'transform="translate(0,-352.36218)"', changed to portrait it is 'transform="translate(0,-52.36218)"'), which moves its content vertically by -352.36218 px (or -52.36218 px) - this is relative to the SVG coordinate system i.e. the content is moved upwards by 352.36218 px (or 52.36218 px) with regard to the coordinate system as displayed in the GUI. Depending on the document height, this can have the effect that when displayed in Inkscape on canvas at zoom level 1:1, none of the content is vertically precisely aligned to the pixel grid of the SVG (if the height is not an integer pixel value, the pixel grid based on the GUI origin and the pixel grid based on the SVG origin don't precisely match). And it can introduce some small differences (probably related to rounding differences and varying internal precision in different parts of the code), even if the modified height of the document page later was set to an integer px value.

Example:
Small rounding errors/differences apparently introduced when calculating the actual position of the upper left corner of the bitmap image with regard to the SVG coordinate system (compensating any parent transforms):
y coordinate of the bitmap image (as displayed in the XML editor) + y component of the translate() transformation of the parent layer

Image centered to landscape page (transformation of 'Layer 1' is "translate(0,-352.36218)"):
Image centered to page after changing page orientation to portrait (transformation of 'Layer 1' is "translate(0,-52.36218)"):
-> apparently for the second case, the antialiasing of horizontal lines is much more noticeable than in the first case. I can confirm that varying the page height and centering the image vertically after that can result in slightly different degrees of antialiasing as long as the image remains in the same (transformed) layer after resizing the page. Of course the actual rendering of the bitmap image on canvas also depends on the current zoom level, as well as the preferences setting for oversampling of bitmaps (default is 2x2). Above notes refer to zoom level 1:1 (100%), and default oversampling 2x2.

However…
In my tests with your example SVG file, in most cases it was sufficient to make sure that the X and Y coordinates of the embedded bitmap image as displayed in the controls bar of the select tool are set to integer px values (e.g. after centering the image on the page), and not to half-pixels (e.g. "6.5" for Y). Or running 'Extensions > Modify Path > PixelSnap' after centering…
I.e. despite the (ominous) transformation of the parent layer, combining simple math and the available controls in the GUI in most cases allows to position the bitmap image so that it renders without any blurred (antialiasing) effects at zoom level 100% - without diving into internals (transform attributes, different coordinate systems, etc). And if that fails, PixelSnap can help ;)

@ ~suv

Thank you for this thorough explanation. I`ve almost forgot about snapping to pixel (might be cause I have not changed settings in Inkscape for a long time) and it is god to bare this in mind, especially when not by own computer and error appears.

Oh wow! Thanks ~suv

Well first, I solve my problem by just not using the Align and Distribute dialog. I reported the anomaly in case it might be a bug. So that fact that I don't understand the explanation very clearly should not necessarily reflect on me.

So I think what I understand is that because of the BMP document's dimensions in relation to my page size, centering the BMP to my page size causes it not to be aligned with a "pixel grid"?

Either way, it would make sense to apply 'Extensions > Modify Path > PixelSnap' to align the bitmap image with the (vertical) pixel grid, after centering it on the page.

I thought this PixelSnap extension was used to make exported bitmaps display properly on webpages. But you're saying that in the Inkscape document, there's an unseen pixel grid? And that PixelSnap is used to align raster images to the unseen Inkscape pixel grid? And because centering it on my page size, takes it out of alignment with the pixel grid, the BMP image is distorted?

I don't think I still understand though, because I can move that BMP image around on my Inkscape canvas at will, and it always remains crisp. And surely my moving it randomly, it doesn't always stay aligned with a "pixel grid"? Why doesn't it become blurred when my moving it around doesn't keep it aligned with the pixel grid?

And why, when I use Align dialog (as I instructed earlier) does it permanently blur the BMP? Why if (and incidentally, my default Inkscape grid is a pixel grid ) I first use the Align dialog, and the BMP gets blurred, if I snap it to my visible pixel grid, doesn't it get crisp again?

Oh, oh, oh....is it because my visible pixel grid is aligned to my page size, which is different from the not visible pixel grid? So if I use PixelSnap to align the BMP to the unseen pixel grid, would the image become crisp again?

But I still don't understand why simply moving the BMP around on the canvas would not create this problem as well?

We already know that your custom default template has a top-level layer transform right from the beginning - could you attach it here so that others trying to reproduce it can start with the same conditions?

That's what I attached. It's my custom default with the image imported, and nothing more (or less). Or do you mean the actual default.svg doc?

And slightly off topic, but related to some of my confusion about the transform attribute (layer-group or group)..... I've created the custom default doc for 2 reasons -- 1 to avoid that stupid 35% zoom of the original default doc, and 2 because I almost never use the A4 size in the first place. I understand that changing the page orientation to landscape causes the transform attribute to be added to layer Layer 1 (and I suppose any other new layers?). And that's the source of many of these bugs that are related to the transform attribute. Now recently you've told me that the transform attribute is supposed to be added when you change the page orientation, and that some of these bugs related to the transform attribute are caused by various different things not using the transform attribute properly.

So, until the bugs are fixed (and who know how long it might take), is there any way for me to have a landscape orientation without the transform attribute? If I open my default.svg doc and remove that attribute, won't it just change the orientation back to portrait?

And so finally -- it's not a bug, right? Or do you still need another attachment to be sure?

brynn wrote:I understand that changing the page orientation to landscape causes the transform attribute to be added to layer Layer 1 (and I suppose any other new layers?).

Newly added layers will not have that attribute (until you change the page size again, after having added new layers).
That's why one of the recommended workarounds e.g. for the 'Tiled clones' issue is to add a new layer, move the original tile to that new layer (or create it on the new layer), and keep working on that layer for the tiled clones.

brynn wrote:So, until the bugs are fixed (and who know how long it might take), is there any way for me to have a landscape orientation without the transform attribute?

Yes. Open the template file itself, remove the 'transform' attribute of the empty layer(s) present in your template file, save, quit. See also for example the last paragraph in this earlier comment.

brynn wrote:If I open my default.svg doc and remove that attribute, won't it just change the orientation back to portrait?

No. The page orientation is determined by the ratio of page width / height which is stored globally for the document, not per layer.

Then why is the transform attribute added to the layer? I thought I understood from an earlier topic, that it was supposed to be there. (I can find the other topic if necessary. It's entirely possible that I took the wrong conclusion. This is all so complicated )

brynn wrote:Then why is the transform attribute added to the layer? I thought I understood from an earlier topic, that it was supposed to be there.

Technically it is necessary because changing the page height (or resizing it e.g. to content or selection) changes the distance of all objects in each of the top-level layers to the origin of the SVG coordinate system in the upper left corner of the (resized) page. If a layer is empty (like in a new document, or a newly added layer), there are no objects which would have a different distance to the SVG origin, and no transformation is needed.

Otherwise - maybe at this point we ought to agree to disagree? Honestly, I'm at my wits' end how to explain it, and I do get the impression that you are still looking for the proof that the bug is how Inkscape changes the page size, and not underlying issues in various parts of the code to handle transforms on parent groups (not limited to Inkscape layers) properly.

To successfully use Inkscape as a GUI vector editor, it is not necessary to dive into technical aspects like your last question. If you think it would be an asset to you as user to have more insight into e.g. transformations as they are stored in the SVG file - learning the basics of the SVG file format might be a first step (it was for me). I also learned to better understand what is going on by playing with simple SVG files (few objects with known x and y values in GUI and SVG coordinates) & watching changes live in the XML Editor as well as testing such files by externally editing them in a text editor (like Notepad) and viewing the results in Inkscape (and/or a web browser). One major hurdle was to grasp that when working with Inkscape's GUI, there are two different coordinate systems (GUI, SVG) in play, and that Inkscape needs to keep them in sync when e.g. making changes which affect the relationship between the two (like changing the page height does).

Otherwise - maybe at this point we ought to agree to disagree?

For me, it's not a matter of agreeing or disagreeing. I'm just trying to understand. I don't know enough about it to be able to form any kind of opinion, with which I might agree or disagree. I'm just trying to sort out the cause and effect. For example, changing the page orientation causes the transform attribute to be added for the layer-group. But removing the attribute does not cause the page orientation to be reversed. It seems illogical. That's all.

Perhaps this explains it?

....when working with Inkscape's GUI, there are two different coordinate systems (GUI, SVG) in play, and that Inkscape needs to keep them in sync when e.g. making changes which affect the relationship between the two (like changing the page height does).

....and I do get the impression that you are still looking for the proof that the bug is how Inkscape changes the page size, and not underlying issues in various parts of the code to handle transforms on parent groups (not limited to Inkscape layers) properly.

NO, not at all! I don't know enough about any of this to be able to prove or disprove anything. Or even to WANT to prove or disprove anything. I'm just trying to understand. I'm just trying to understand.

If you say the root or the cause of all these bugs are "underlying issues in various parts of the code to handle transforms on parent groups (not limited to Inkscape layers) properly" I believe you. I'm in no position to agree or disagree. As far as I'm concerned, you're the expert!

Please look for a PM shortly. Thanks again for your help

brynn wrote:

~suv wrote:Otherwise - maybe at this point we ought to agree to disagree?

For me, it's not a matter of agreeing or disagreeing. I'm just trying to understand. I don't know enough about it to be able to form any kind of opinion, with which I might agree or disagree. I'm just trying to sort out the cause and effect.

Sorry, my fault - should have gone to bed instead of venting here in the forum.
I'll try to reduce the technical details next time and to provide more practical advice (if I have some).