Jump to content
danmerey

[By Design] Merge Down Layers in AF corrupts/blures image in some cases: example attached, solution offered

Recommended Posts

Hello, this bug is being discussed in another thread, but since it's being ignored by Developers for pretty long time, I decided to refresh it by creating a new topic with some new facts and a solution.

"Merge Down Layers" (Ctrl+Shift+E) is very common and frequently used command, that we use to merge layers. Although it can corrupt your image in a lot of random cases by blurring you layers after merge. You can see what happens to layers if that occurs on attached image. After 1 merge you are losing sharpness, and after 2 or 3 merges you will start to notice that image got blurred, but it will be too late – your file is already corrupted. I attached *.afphoto file, so you can reproduce bug and see why this happens.

I already found a workaround in the past, which is super annoying, but better then nothing – Create Empty Layer (Ctl+Shift+N) and merge down to this new layer.

But today I found an ultimate solution for Affinity Developers, which is super easy to implement, and I hope they will do it ASAP: If you rastirize lowest layer before merge, nothing will be corrupted. So before Merge we should automatically rasterize lowest layer, and then we will never corrupt our image again.

Some important facts for Affinity Developers:

  • I attached *.afphoto file, you can reproduce the bug
  • I reproduced bug in Beta too
  • It's not because of "Force Pixel Allignment" or "Floating point coordinates"
  • This is critical bug, that corrupts our work (I corrupted my images without noticing, other guys from previous thread also corrupted 4+ hours of work)
  • This is not intended behaviour, please pay attention to this one and put yourself in our place
  • This never happened in Photoshop with similar actions
  • To get "bugged" layer you can resize existing normal layer and it becomes corrupted for future merges
  • To fix this bug you just need to automatically Rasterize lower layer before "Merge Down" operation

Thanks, hope you fix this asap and notify us!

1839930379_CorruptedMerge.thumb.png.c65bfe579880769ee9cc316da956ab06.png

Corrupted Merge.afphoto

Share this post


Link to post
Share on other sites

Is this the same issue that I describe below?

And if so, how is it possible for an 'advanced' graphics program to fail to merge Layers without some convoluted workaround? This  TOTALLY UNACCEPTABLE. Even the wretched Elements allows it. Please, Serif, Give Us the Answer!

  • When I create a layer (in this case, of a line drawing) and embolden this as a Multiply layer, every possible way of merging or flattening the upper image destroys the upper layer and saves or exports the image unchanged, as things started.
    Opening Curves unavoidably creates an upper layer that CANNOT BE SAVED.
    (Affinity Photo  1.6.11.)
  • Solutions please, anybody?

Share this post


Link to post
Share on other sites
34 minutes ago, danmerey said:

It's not because of "Force Pixel Allignment" or "Floating point coordinates"

Neither Layer 1 nor Layer 2 in your file are pixel aligned, nor do they have the same dpi in the X & Y directions:
1455618717_Layersinfo.jpg.5647519384026b266f9db4418830d300.jpg
You can see the dpi difference in the context toolbar when either layer is selected with the Move Tool. To see the Y direction misalignment in the Transform panel, you may need to increase the Pixels > Decimal Places for Unit Types in Preferences > User Interface. Above, it is set to 3 decimal places.


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
40 minutes ago, R C-R said:

Neither Layer 1 nor Layer 2 in your file are pixel aligned, nor do they have the same dpi in the X & Y directions:
1455618717_Layersinfo.jpg.5647519384026b266f9db4418830d300.jpg
You can see the dpi difference in the context toolbar when either layer is selected with the Move Tool. To see the Y direction misalignment in the Transform panel, you may need to increase the Pixels > Decimal Places for Unit Types in Preferences > User Interface. Above, it is set to 3 decimal places.

Can you please stop running away from problem and accept that there's a huge bug here?

  1. This facts shouldn't affect the merging anyway, this is not expected behaviour for any normal user. Merging shouldn't corrupt image in any way. "How it looks before merge" must be equal to "How it looks after merge". Why I need to make some stupid workaround to get normal behaviour of merge?
  2. If you change floating points to integer, problem still remains. How about to check it before posting this answer? That's why I said, that it's not the problem. Or I need to make a video to prove it? I'm really tired of explaining why this is a bug and not my imagination
  3. How can I avoid getting decimals in my image anyway? I can't because I use resize and rotation tools all the time. Or maybe I shouldn't ever resize anything so it won't corrupt after merge, lol?

Come on, it's easy to fix (I already found a solution: just rasterize lowest layer before merging) – why do you make it so hard for us to enjoy the product and customer support?

PLEASE, fix this already and stop making exuses. Software should be easy and pleasant in use, but we are frustrated instead (because of a bug and because of not wanting developers to fix it)

Corrupted Merge with Integers.afphoto

Share this post


Link to post
Share on other sites

Please R C-R :),

You're about to lead this new thread to same direction that the previous one (... which leads nowhere :().

Can you considering just this fact :

  • If you rasterize your bottom layer before processing merge, you got what can be considered as a perfect result. The global image before and after (rasterize+merge) operations are strictly the same. No blur. The result some of us (everyone ?) would like to got.
  • If you didn't, your result is sadly blurred (the content of both initial layers). Useless.

So the application is currently totally able to proceed a perfect merge, the one (casual / most ?) users would like to got. So why not ?

Why the merge function didn't simply proceed this way (the green one) ? Where is the gain for the user to proceed otherwise  ? If there's one (I'm not an expert), it's the missing argument in this thread. The only one.

Elsewhere, the merge function should be upgraded (maybe one line of code ....) for the happiness of most of us

Share this post


Link to post
Share on other sites

Thanks, olivierlafitte, this is what I was talking about.

I've recorded video with Current Behaviour and Expected Behaviour (with rasterize before merge and without losing quality). If after this Affinity Developers will still insist that's it's "not a bug", I have no idea what to do here

Share this post


Link to post
Share on other sites
41 minutes ago, danmerey said:

Can you please stop running away from problem and accept that there's a huge bug here?

I am just pointing out the problem is in your example files, not the app. Your first one is not pixel aligned to begin with, & in neither one are the X & Y dpi values equal or the same as the document dpi. Given those settings, both layers are already slightly blurred before the merge, even if you can't see it.

Unequal X & Y dpi values mean the original image was  slightly stretched or shrunk while not maintaining its original aspect ratio, which in turn forces the app to blur it slightly to maintain the new aspect ratio. That's unavoidable because there is no way to stretch or shrunk the pixels themselves to a different aspect ratio.

I am not sure why your layers have unequal X & Y dpi values, so if you can explain more about how that happened, it may help to understand what's going on in the file, but as it is it is just a demonstration of the expected behavior.


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
6 minutes ago, R C-R said:

I am just pointing out the problem is in your example files, not the app.

It is in the app, jeez. Stop talking about technical reasons and pay attention to why this shouldn't occure. Please watch the video that I attached in the previous post and tell me it is normal behaviour.

Now it looks like you are trolling us or just don't want to fix the bug. Worst customer support ever.

None of what you mentioned shouldn't affect Blurriness of the picture and corrupt it.

All that you explain is just "why this happens". Cool, now fix this please, because it's a bug and not intended behaviour for any normal software. We already showed how to fix this (by rasterizing lowest layer before merging)

Share this post


Link to post
Share on other sites
46 minutes ago, R C-R said:

I am not sure why your layers have unequal X & Y dpi values, so if you can explain more about how that happened, it may help to understand what's going on in the file, but as it is it is just a demonstration of the expected behavior.

Seems like you didn't read anything. I already mentioned how to get bugged layers: resizing it. And don't you dare to tell me not to resize anything to avoid the problem. Maybe I shouldn't use brushes too?

4 hours ago, danmerey said:

To get "bugged" layer you can resize existing normal layer and it becomes corrupted for future merges

 

2 hours ago, danmerey said:

How can I avoid getting decimals in my image anyway? I can't because I use resize and rotation tools all the time. Or maybe I shouldn't ever resize anything so it won't corrupt after merge, lol?

It is one line of code that will close this issue once and for all, please stop this useless resistance. It seems that your team lack some QA, because no normal QA ever let pass such terrible bug and say "it's not a bug, it's intended behaviour"

P. S. didn't know you are not a part of the Team, since you are way too active in those topics.

 

Share this post


Link to post
Share on other sites
4 minutes ago, danmerey said:

It is one line of code that will close this issue once and for all, please stop this useless resistance. It seems that your team lack some QA, because no normal QA ever let pass such terrible bug and say "it's not a bug, it's intended behaviour"

I am not part of a "team," just another user like yourself. Neither am I resisting anything, just trying to explain why what you see as a bug I see as the unavoidable & expected behavior when everything cannot be pixel-aligned.

Also, without knowing anything about the code, neither you nor I nor anybody else who does not have access to it can possibly know if some single line of of it could change anything related to this.


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
3 minutes ago, R C-R said:

I am not part of a "team,"

Whaddya mean, not part of a team?? :o


Alfred online2long.gif
Affinity Designer 1.7.0.367 • Affinity Photo 1.7.0.367 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.7.0.135 • Affinity Designer for iPad 1.7.0.9 • iOS 12.3.1 (iPad Air 2)

Share this post


Link to post
Share on other sites
2 minutes ago, R C-R said:

I am not part of a "team," just another user like yourself

Didn't know that, since you were too active in these topics.

Ok, then please stop saying nonesence since we need answer from the developers and you may confuse them when they come. You are not helping. We are trying to fix important issue here, and you just come to argue.

9 minutes ago, R C-R said:

just trying to explain why what you see as a bug I see as the unavoidable & expected behavior when everything cannot be pixel-aligned.

It is not expected behaviour since my "pixel-allignment" always on but decimals will appear anyway. And it doesn't justify fact, that image after merge is not what it was before merge.

10 minutes ago, R C-R said:

Also, without knowing anything about the code, neither you nor I nor anybody else who does not have access to it can possibly know if some single line of of it could change anything related to this.

I'm pretty sure that adding line of code like "RasterizeLayer(layer2);" before "MergeDown(layer1, layer2);" will do the trick. Because that's what I do with my own hands to avoid issue.

Share this post


Link to post
Share on other sites
2 minutes ago, danmerey said:

It is not expected behaviour since my "pixel-allignment" always on but decimals will appear anyway.

Unless all of the w, h, x, & y pixel values are integer numbers then the selected object definitely is not pixel-aligned. What may be confusing you is that "Force Pixel Alignment" does not always apply if "Move by Whole Pixels" is also enabled, because the latter does exactly what it says it does. So for example, if the x coordinate is currently 10.4 px, moving it by one pixel moves it to 11.4 px.


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
3 hours ago, R C-R said:

What may be confusing you is that "Force Pixel Alignment" does not always apply if "Move by Whole Pixels" is also enabled

Does “Force Pixel Alignment” ever apply if “Move by Whole Pixels” is enabled? I’ve mentioned previously that I don’t understand why the latter option can only be toggled when the former is enabled, given that it seems to override the ‘parent’ option.


Alfred online2long.gif
Affinity Designer 1.7.0.367 • Affinity Photo 1.7.0.367 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.7.0.135 • Affinity Designer for iPad 1.7.0.9 • iOS 12.3.1 (iPad Air 2)

Share this post


Link to post
Share on other sites
3 hours ago, Alfred said:

Does “Force Pixel Alignment” ever apply if “Move by Whole Pixels” is enabled?

It does if the original value is an integer pixel value, otherwise not. I'm not sure of the logic, but the help page explains it as "If you deactivate Move By Whole Pixels but have Force Pixel Alignment active, moving an object which occupies partial pixels will also transform it marginally."

Not the clearest of descriptions, but that is all we get.


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
2 hours ago, JimmyJack said:

Pixel aligned/whole pixel objects can also blur. 

edit: Whoops, got here through a link. I'm on Mac. Blurring.

Your Mac is blurring?!? That must be unsettling! :S


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
3 hours ago, Alfred said:

Does “Force Pixel Alignment” ever apply if “Move by Whole Pixels” is enabled?

 

21 minutes ago, R C-R said:

It does if the original value is an integer pixel value, otherwise not.

If the original value is an integer pixel value, pixel alignment still isn’t forced: it just happens naturally.


Alfred online2long.gif
Affinity Designer 1.7.0.367 • Affinity Photo 1.7.0.367 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.7.0.135 • Affinity Designer for iPad 1.7.0.9 • iOS 12.3.1 (iPad Air 2)

Share this post


Link to post
Share on other sites
3 hours ago, Alfred said:

I’ve mentioned previously that I don’t understand why the latter option can only be toggled when the former is enabled, given it seems to override the ‘parent’ option.

IIRC, in one of the old topics where you mentioned this, didn't one of the staff or developers explain that it had something to do with intentionally maintaining fractional pixel alignments, like when vector lines are offset by ½ pixel, or something like that?


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

Same here. On 1.6.5.135

  1. No merge: X 478, Y 0, W 565, H 396
  2. With merge: X 477.2, Y -0.5, W 565.8, H 396.5
  3. Occurs only for Merge Selected, Merge Down.
    For Merge Visible works good but some pixels color is not the same.
    A little bit the color was changed.
  4. If use the Merge Visible, the layers will not removed.

How should works:

  1. Merge action shouldn't affect the layers position on the page.
  2. No change the pixels color.

Share this post


Link to post
Share on other sites
14 minutes ago, AndRo Marian said:

1, No merge: X 478, Y 0, W 565, H 396

What are you trying to merge this with?


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites
7 hours ago, R C-R said:

IIRC, in one of the old topics where you mentioned this, didn't one of the staff or developers explain that it had something to do with intentionally maintaining fractional pixel alignments, like when vector lines are offset by ½ pixel, or something like that?

Quite possibly, but that doesn’t explain why those two options are in a parent/child relationship in the first place. As I see it, ‘Force Pixel Alignment’ and ‘Move by Whole Pixels’ are mutually exclusive and should therefore be same-level choices.


Alfred online2long.gif
Affinity Designer 1.7.0.367 • Affinity Photo 1.7.0.367 • Windows 10 Home (4th gen Core i3 CPU)
Affinity Photo for iPad 1.7.0.135 • Affinity Designer for iPad 1.7.0.9 • iOS 12.3.1 (iPad Air 2)

Share this post


Link to post
Share on other sites
1 hour ago, Alfred said:

As I see it, ‘Force Pixel Alignment’ and ‘Move by Whole Pixels’ are mutually exclusive and should therefore be same-level choices.

From the description in the help topic, I have the impression that "Move by Whole Pixels" is intended as an additional constraint on pixel alignment that applies only to the movement of vector objects, nodes and handles, whereas "‘Force Pixel Alignment" applies to the creation, movement, or modification of vector objects, nodes and handles, and pixel selection areas.

In that sense they are not mutually exclusive, but I don't see why they have to be linked, with "Move by Whole Pixels" available only if "Force Pixel Alignment" is enabled.

EDIT: Something that bothers me about the help topic is that it doesn't say anything about how the alignment options apply to pixel objects, other than perhaps to their handles. But it is easy to show that with "Force Pixel Alignment" enabled, with or without "Move by Whole Pixels" enabled, this does not affect the corner handles, only those on the center of the sides. Even then, if the pixel object has been rotated, sheared, or otherwise deformed so the bounding box & selection box are not identical, the corner handles of either box are not affected, & the center ones only if the selection box is reset.

I understand that there are inherent limitations that make maintaining "pixel perfect" alignment impossible for some modifications. But even considering that, at best the help topic seems incomplete, lacking important details about the scope of these options.


Affinity Photo 1.7.1 & Affinity Designer 1.7.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.0.135 & Affinity Designer 1.7.0.9 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.3.1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×