Can not prevent resize canvas from blurring rasterized images.

[rawalanche]

Hi,

I am using AF Photo 2.1.1 and I can't figure out how to make Resize Canvas stop blurring my rasterized images. Here's an example:

Before:

After:

All I did was resize the canvas. It has no options that could affect this.

The very same thing often happens when I just move rasterized images with having snap enabled. Due to this, I can't use snap very often. It's not just a visual glitch. When I export to PNG, the blur is actually baked in.

[NotMyFault]

If you resize e.g. from even to odd canvas size, the pixel layer may get to a non-integer position, thus giving the blurry rendering when using default bilinear resample. To check, please activate nearest neighbor in settings. If rendering gets sharp again, we found the issue.

Other potential issues:

• Affinity tend to temporary produce low quality preview due to mipmap rendering. Try to zoom in/out, this triggers a redraw.

Please check if the actual layer is blurred, or one of the rendering issues above occurs.

[rawalanche]

7 minutes ago, NotMyFault said:

If you resize e.g. from even to odd canvas size, the pixel layer may get to a non-integer position, thus giving the blurry rendering when using default bilinear resample. To check, please activate nearest neighbor in settings. If rendering gets sharp again, we found the issue.

Other potential issues:

• Affinity tend to temporary produce low quality preview due to mipmap rendering. Try to zoom in/out, this triggers a redraw.

Please check if the actual layer is blurred, or one of the rendering issues above occurs.

Yes, I already noticed it's due to the non integer transform positions, but this is still a bit ridiculous. This is not anything I as a user should ever get in contact with:

- If makes 0 sense for rendering filter (nearest neighbor/bilinear) to actually be baked into the exported image. It should only be used for viewport.

- There should be some global option to simply disallow subpixel transforms, and round up all floats in transform panel to integers. If I am working with bitmap images, then the smallest discrete increment is a pixel.

I as a user should never be making a choice between less buggy and high quality interpolation, as nearest neighbor will produce aliasing under many conditions. I should just be able to use bilinear but not have to worry about constantly manually rounding float decimals in the transform panel.

[Dan C]

Thanks for your feedback here @rawalanche!

I can confirm this is not technically a bug within the Affinity apps as this is expected behaviour when resizing to a non-integer position/size at this time - however our team will certainly consider a global option to disallow subpixel transforms in the future, as you've mentioned above

[rawalanche]

14 minutes ago, Dan C said:

I can confirm this is not technically a bug within the Affinity apps as this is expected behaviour when resizing to a non-integer position/size at this time - however our team will certainly consider a global option to disallow subpixel transforms in the future, as you've mentioned above

So is the recommended workflow for now really to keep manually fixing the transforms in the transform panel after every snapped move tool operator, after every element resize and after every canvas resize? It's a lot of work to do.

[Dan C]

When transforming objects directly on the canvas, you can enable Force Pixel Alignment and disable Move by Whole Pixels (next to the Snapping icon) to ensure that any objects transformed with the Move Tool will respect whole integer values -

However when resizing/resampling the canvas, you will first need to check that your objects are already aligned to integer values in the Transform Studio, and the resize itself is to an integer value for both width and height, in order to stop this from happening.

I hope this clears things up!

[rawalanche]

7 minutes ago, Dan C said:

When transforming objects directly on the canvas, you can enable Force Pixel Alignment and disable Move by Whole Pixels (next to the Snapping icon) to ensure that any objects transformed with the Move Tool will respect whole integer values -

However when resizing/resampling the canvas, you will first need to check that your objects are already aligned to integer values in the Transform Studio, and the resize itself is to an integer value for both width and height, in order to stop this from happening.

I hope this clears things up!

I tried all 3 possibilities:

1. Both off

2. Force alignment on and move by whole pixels on

3. Force alignment on and move by whole pixels off

Neither of these states prevent the blur due to misaligned transforms. Snapping to guides will just keep causing fractional transform values.

[Dan C]

13 minutes ago, rawalanche said:

Neither of these states prevent the blur due to misaligned transforms. Snapping to guides will just keep causing fractional transform values.

This is correct if your objects are already misaligned from the integer pixel grid, but with the above options enabled/disabled respectively you can then transform the objects on your canvas to ensure they are on whole values before resizing the canvas etc.

If you're still having trouble with this, a copy of your Affinity document could help me to demonstrate this for you.

[walt.farrell]

43 minutes ago, rawalanche said:

Snapping to guides will just keep causing fractional transform values.

That sounds like you have guides that are not properly positioned to the pixel grid.

[rawalanche]

6 hours ago, Dan C said:

This is correct if your objects are already misaligned from the integer pixel grid, but with the above options enabled/disabled respectively you can then transform the objects on your canvas to ensure they are on whole values before resizing the canvas etc.

If you're still having trouble with this, a copy of your Affinity document could help me to demonstrate this for you.

It can be replicated with anything, it's not document specific. Just create new document, use Windows' snipping tool to snip part of the affinity UI itself, enable snappig with the default out of the box settings, and you should get it. Here's a video:

I am having hard time imagining no one noticed that since Affinity Photo has been around. The default image center guides tend to snap the images with fractional transform causing the blur. And once the first image is placed this way, any subsequent images can often be snapped relative to that, so the blur spreads like a plague over over entire document.

I have not configured those guides in any way. They are exactly how the AF Photo 2 comes out of the box. The only thing that I change from the default factory state of the software (aside rearranging the panels) was clicking the big magnet icon button to enable snapping.

[walt.farrell]

19 minutes ago, rawalanche said:

The only thing that I change from the default factory state of the software (aside rearranging the panels) was clicking the big magnet icon button to enable snapping.

But what Snapping options have you chosen? And what are the pixel coordinates (with at least 3 decimal places displaying) of the layer you pasted into the document.

If we had your document, we could determine the answers to those questions, and probably explain what you're experiencing.

[rawalanche]

7 hours ago, walt.farrell said:

But what Snapping options have you chosen? And what are the pixel coordinates (with at least 3 decimal places displaying) of the layer you pasted into the document.

Uh.... well, obviously, those that come with AF Photo 2 factory settings. That's exactly why I wrote the sentence you quoted. But if it helps, here you go

bug.afphoto

[HCl]

.

[rawalanche]

1 minute ago, Return said:

From your video it is clear that the y position is not a whole integer.
You also seem to have set the move by whole pixels this will move by whole pixels even when set to .5 pixels

So if an object is on say 1.5 and you move by 10 whole pixels it will become 11.5 not 11 or 12

If you want it to have it always move by real integers just use the transform panel and hold shift while mouse wheeling the fields.
You have to use the topleft anchor from the ninedots options as the real position is calculated from the topleft.(0.0)

Jesus christ.... yes! I know! I am very well aware the positions are not whole integers. Just read pretty much ANY post above yours. We've been already talking about that above.

That's the whole point. I, as a user, should not ever come in contact with this. Snapping, nor resizing canvas should ever introduce sub-pixel transforms. Using transform panel instead of interactive in-viewport move tool is of course not a feasible workaround. We are in a third decade of 21st century, not in early 90's. Moving image in image editors is not expected to be done by typing numbers into text boxes.

My whole point is that I don't want to be constantly correcting errors in some value boxes outside of the viewport of something as essential as just snapping in a image editor. I want to focus on my art. I don't want to be going into some panel to correct some number due to buggy feature after nearly every use of the move tool. That pretty much defeats the purpose of even having interactive viewport move tool.

[HCl]

.

[rawalanche]

9 minutes ago, Return said:

Well, I and others concur with you that the affinities should always use pixelperfect positions and sizes to avoid this.
And your post makes it yet again clear that the developers aka Serif are wrong by the way they implemented this in their software.
I just pointed out what is happening and that you should be aware of this and what can be done until Serif comes to their senses and starts creating software for actual people instead of seeing this as a prestige project for doing it different which doesn't help any user.
 

Yes, but I got frustrated because that conversation has already been had. 

 

17 hours ago, rawalanche said:

So is the recommended workflow for now really to keep manually fixing the transforms in the transform panel after every snapped move tool operator, after every element resize and after every canvas resize? It's a lot of work to do.

^

Yesterday already I asked if there's better way than to manually correct transform after every snapped move or after every canvas resize, and a day later I get a suggestion that I should manually correct the transforms. So you can imagine the frustration.

[Dan C]

12 hours ago, rawalanche said:

Just create new document, use Windows' snipping tool to snip part of the affinity UI itself, enable snappig with the default out of the box settings, and you should get it. Here's a video:

Your video shows that you have Move by whole pixels enabled, which means that once your object is misaligned from a whole pixel value, it will remain misaligned as it is now only moving in full pixel increments.

As I recommended previously, please disable this option, such that when using the Move Tool, your objects will be aligned to whole pixel values.

12 hours ago, rawalanche said:

The default image center guides tend to snap the images with fractional transform causing the blur. And once the first image is placed this way, any subsequent images can often be snapped relative to that, so the blur spreads like a plague over over entire document.

However - as far as I'm aware Snapping will always take precedence over Force Pixel Alignment, when both cannot be true.

For example in your video the screenshot and canvas size do not equally divide between each other. When the object is set to snap to the midpoint, either the app can respect the 'true' midpoint of the canvas and set the object on a fractional pixel value, or can respect the Pixel Alignment option and snap the object slightly misaligned from the 'true' midpoint.
Currently the app always respects the true snapping point, ensuring that the object is perfectly aligned to the centre of the canvas, regardless of if this is a fractional pixel value or not.

I can certainly understand why you would not want this behaviour, so I can log an improvement with our developers for an option that respects Force Pixel Alignment over any Snapping options enabled - though you would then find that objects aren't exactly snapped to the centre of your canvas, when both cannot be true, as outlined above.

Is that the type of behaviour you're looking for please?

[HCl]

.

[rawalanche]

26 minutes ago, Dan C said:

As I recommended previously, please disable this option, such that when using the Move Tool, your objects will be aligned to whole pixel values.

Yes, the reason I kept it enabled in the file and in the video is that as I said yesterday, it doesn't do much in preventing the problem. Secondly, the name of the setting implies the exact opposite. So that if I have to turn off the setting called "move by whole pixels" to actually make the image move by whole pixels will be confusing to anyone who doesn't randomly stumble upon this thread.

26 minutes ago, Dan C said:

However - as far as I'm aware Snapping will always take precedence over Force Pixel Alignment, when both cannot be true.

For example in your video the screenshot and canvas size do not equally divide between each other. When the object is set to snap to the midpoint, either the app can respect the 'true' midpoint of the canvas and set the object on a fractional pixel value, or can respect the Pixel Alignment option and snap the object slightly misaligned from the 'true' midpoint.
Currently the app always respects the true snapping point, ensuring that the object is perfectly aligned to the centre of the canvas, regardless of if this is a fractional pixel value or not.

I can certainly understand why you would not want this behaviour, so I can log an improvement with our developers for an option that respects Force Pixel Alignment over any Snapping options enabled - though you would then find that objects aren't exactly snapped to the centre of your canvas, when both cannot be true, as outlined above.

Is that the type of behaviour you're looking for please?

I understand the technical specifics well. I understand that if you have for example canvas of 600x600 width and image of 255x255 width, snapping the image layer to the precise center of the canvas would mean the X image transform would be at 127.5 pixels off the X center of the image. If it was rounded to 127 or 128 it would be slightly off center.

However you really need to take a step back here and think in a bigger picture. If you are selling a commercial image editor, it's absolutely unacceptable that a simple snapped move operation could result in bilinear sampling of the image layer in such a way that would then be baked into exported image.

Just imagine a scenario where you are someone hired by some company to do graphics for some expensive print. You don't notice the blur at the first glance, and neither does the client until it's printed. Then, the blur is noticed and a lot of money is lost.

The kinds of questions like whether it's more acceptable for a user to have possibly many of the imported image layers blurred both in the editor and on the export, versus if it's acceptable that image layer to be snapped half a pixel off the location user desired is a question that would take at least one competent person in a UX team to answer.

Judging by the current behavior, which hasn't changed for years now, it doesn't appear Affinity even has a UX team, because this question is not really that hard to answer. It's the very common scenario where you have to make a compromise. Choosing a lesser evil. Both choices are bad, but in this case, it's pretty obvious that blurring image layers unpredictably is way, way less dangerous than lying to the user by snapping the layers half a pixel off the desired location.

 

So in short, yes, it's the behavior I am looking for, but it's really perplexing that behavior hasn't been the default yet for years. There's quite many more of these "my image is blurry" threads on this forum, for years already.

I'd like to also stress that this proposed option would have to be applied more globally. For example when resizing using the move tool by dragging a corner pin of the move frame should also round to whole pixels, otherwise the problem will never really go away. 

The option should be much more global in a way that the hypothetical checkbox would essentially prohibit any fractional transform values from ever existing. That they caused by any tool or operation anywhere.

Technically speaking, this should not be that hard to implement. Whatever callback that updates the transforms of any items could just round the values at the end of each transform update if that rounding user preference is enabled. Basically, it should be a "I never ever want to see fractional values in my transform panel ever under any circumstances" checkbox.

[HCl]

.

[rawalanche]

1 minute ago, Return said:

This is likely correct.
Getting feedback from a few design studios that will use it occasionally isn't feedback.
They will have a look and say "nice, that will work for us" but will still use the software from the mud company after Serif has left the building.



 

True. The reason I migrated to Affinity wasn't really that I didn't enjoy Adobe software itself, but the bloatware was absolutely unacceptable. Dozens of processes running in the background and PS not even starting without CC.

I have some other friends who did the same, but they all said that while they use AF Photo, they don't really like it. It can do almost everything PS can, but it does it way slower and way less comfortably. AF software is not lacking in features, but in UX. If they worked on that, they could drag over so, oh so many more Adobe users. But right now, even simplest things like masking layers feel like kick in the balls to do in AF Photo. Focusing on UX for at least one release would do help a lot.

[HCl]

.

[Dan C]

5 hours ago, rawalanche said:

it doesn't do much in preventing the problem

Although having this setting enabled/disabled wont stop the Snapping of the object to a part pixel location, due to the aforementioned reasons, your object will then remain on a part pixel unit, even if moved from this Snapping location - hence my recommendation to have one option enabled and the other disabled.

5 hours ago, rawalanche said:

the name of the setting implies the exact opposite. So that if I have to turn off the setting called "move by whole pixels" to actually make the image move by whole pixels will be confusing to anyone who doesn't randomly stumble upon this thread.

This is covered in the Helpfile for these 2 options, though we do appreciate your feedback here.

5 hours ago, rawalanche said:

However you really need to take a step back here and think in a bigger picture. If you are selling a commercial image editor, it's absolutely unacceptable that a simple snapped move operation could result in bilinear sampling of the image layer in such a way that would then be baked into exported image.

Just imagine a scenario where you are someone hired by some company to do graphics for some expensive print. You don't notice the blur at the first glance, and neither does the client until it's printed. Then, the blur is noticed and a lot of money is lost.

In this scenario I would recommend leaving the Snapping options disabled, with Force Pixel Alignment enabled and your objects will always be on whole pixel values, ensuring such issues don't occur.

5 hours ago, rawalanche said:

So in short, yes, it's the behavior I am looking for

Thank you for confirming that for me - I'm logging this with our development team to be considered as an option for FPA to override enabled Snapping options, such that the object would always respect the exact pixel grid, regardless of a 'true' snapping location.

Feedback from our users is how we continue to update and improve the Affinity apps, which can be seen in our active beta programs here on the forums.

[rawalanche]

Ok, this bug is actually horrifyingly bad. If I paste image (using Ctrl+V) which has odd pixel dimensions in one or two axes, this image will always be pasted 0.5px off. It's just rounding the pixel to nearest integer will actually make it blurry. So it's not only that I have to manually fix the transforms all the time, I also need to keep mental library of all the images of odd pixel dimensions which actually need to have 0.5px off transforms, OTHERWISE they will be blurry. I've been evaluating affinity photo 2 for past week or so to see if it's worth upgrading from 1.0, and it's been insane experience. Literally half of my time spent in the software is just spent on fixing transform panel values.

[rawalanche]

Ok, 

so:

When you put any layers as a child layer of a shape, let's say rounded box, and forgot to check "lock children", you will almost immediatelly get the fractional pixel value cancer spreading. Insanely enough, the state of "Lock Children" does NOT get saved in the afphoto file. It gets reset on every reopen.

The UX of this editor really is an absolute nightmare. I was doing a simple UI mockup yesterday. I spent about 20 minutes working on the actual design, and about 50 minutes fixing the fractional value transform problems.

It's as if someone intentionally designed this software with the goal of maximizing the possibility of user error.