Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

2 hours ago, MasterBooth said:

"Force Pixel Alignment" and "Move by whole pixels" have been checked in the snapping section all the time - it does not prevent the type of blurring I/we are talking about...

"Move by whole pixels" does exactly what it says it does, so if an object is not currently pixel aligned, with that option enabled it will only move by whole pixel increments, preserving the same relative pixel misalignment.

If that does not explain the type of blurring you are getting, an example of the before & after movement blurring you see would help us understand what you mean.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

25 minutes ago, walt.farrell said:

"Move by whole pixels" can cause problems like that. The general recommendation I've seen is to leave that option off.

From the Force Pixel Alignment help topic:

2145320248_ForcePixelAlignment.jpg.37dc1179f9406102eaf6f23bcab939af.jpg

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

20 hours ago, walt.farrell said:

"Move by whole pixels" can cause problems like that. The general recommendation I've seen is to leave that option off.

I tried this and in the quick test I did this worked: the blur was not there. I'll continue with "Move by whole pixels" off and see if it solves the problem completely. Thank you walt.farrell !

Link to comment
Share on other sites

  • 3 weeks later...

Hi guys, using Aff Photo for a few day now but this blurring and the bad jpg export quality should be fixed very soon otherwise Aff Photo is as good as unusable for my work. Also another issue, why is the preview of Unsharp Mask not the same as the final result?  Common guys, please fix this!

Link to comment
Share on other sites

  • 3 months later...

Hey, guys! I had the same issue today and found something that could help to avoid it and maybe fix it (for Affinity Developers).

I attached Affinity Photo file, in which you can reproduce this bug – merge_down_blur_bugged_layer_example.afphoto.

The thing is:

  • I have one Bugged Layer, and if I merge something with it, everything involved become Blurred
  • If I create new layer, it is OK, and I can merge it with other OK layers without blurring bug.
  • I don't know how to reproduce bugged layer thing, but if I cope layer, duplicate is also bugged.

Hint for users:

  • If you have such issue, try to find Bugged Layer (which causes blur bug with merge), and remove it, create new layer and work on it
  • I currently don't know how to copy Bugged Layer contents without copying Bug with it, if you figure this out, let me know

For Affinity Developers:

  • Please figure this out, why this Bugged Layer causes such issues, how to avoid or remove them (I didn't find anything strange about the layer, scaling layer and big size of it doesn't affect Blurry Bug as far as I checked)
  • I attached Affinity Photo File (merge_down_blur_bugged_layer_example.afphoto) in which you can reproduce that bug, all steps are in text inside file
  • I also attached PNG for demonstration of the bug with blur

P.S. I'm game developer, and I'm working on a game sprites and textures, and I really can't afford such sneaky blurry bugs in my workflow, so please pay attention to this one. It's good that I found this out pretty soon and didn't screw up my work yet (only got some blurry sketches, which is not that bad). I used to use Photoshop, and I lack some features sometimes, but I really like Affinity in most things. But this bug is really crucial, please fix it asap. Thanks!

 

 

merge_down_blur_bugged_layer_example.png

Link to comment
Share on other sites

  • Staff

Hi danmerey,
Welcome to Affinity Forums :)
This is happening because the bugged layer X,Y's coordinates are not integer values. Select it in the Layers Panel (with the Move Tool selected) then look at the X,Y coordinates in the Transform panel. Remove the decimal parts to align the layer with the pixel grid then merge it as you were doing. It shouldn't blur the results anymore.

If you are not seeing the decimal places in the Transform panel, go to Affinity Photo Preferences, User Interface section and increase the Pixels value in the Decimal Places for Unit Types section to 2 or 3.

To prevent layers from ending up in non-integer values when you move them enable Force Pixel Alignment in the main toolbar (the first icon on the magnet icon group). Also make sure the second one (Move By Whole Pixels) is disabled since this one will keep the decimal values if the original object's position is already located in non-integer values.

Link to comment
Share on other sites

17 minutes ago, MEB said:

Hi danmerey,
Welcome to Affinity Forums :)
This is happening because the bugged layer X,Y's coordinates are not integer values. Select it in the Layers Panel (with the Move Tool selected) then look at the X,Y coordinates in the Transform panel. Remove the decimal parts to align the layer with the pixel grid then merge it as you were doing. It shouldn't blur the results anymore.

If you are not seeing the decimal places in the Transform panel, go to Affinity Photo Preferences, User Interface section and increase the Pixels value in the Decimal Places for Unit Types section to 2 or 3.

Thanks for a quick response. I actually had not-integer values in this layer. I changed it to integer, it didn't help. I also tried to change all Position Values to custom int values to override old values, and it also didn't help. Layer remains bugged. I tried to change "Decimal Places for Unit Types", it also did nothing here.

But I have 2 additional interesting facts about this bug:

  • It is a layer that was in my previous PSD file (I recently moved from PS to Affinity), maybe that's what causes the problem? Some export layer settings bug?
  • If I merge Bugged Layer down to New Layer, merge is OK and nothing blures. Bug appears only if I Merge Down to Bugged Layer.
  • I don't think it's a floating point position issue, maybe it's some kind of Scaled Layer? I don't know if it's possible, but maybe Affinity remember actual size and after resizeing it will be not fully resterized and scales procedurally? It could be that, but I don't know how to return actual 100% size of the layer, and don't know how to check if it's not 100%

Hope, this helps and you'll figure this out : )

Link to comment
Share on other sites

  • 2 months later...

Hi everyone,

I've just fu****-up a file i was working on for 40hours, suddenly realizing all has been blurred without my consent many steps ago. No way to undo the damage .... 

Without doubt to me, this occurred on a merge-layers action. Indeed it's not the first time I've been fooled by this function. Each time I realize the problem had just occurred, I always manage to achieve a correct merge adding a certain amount of blank layers on the bottom or the middle of the pile of layers to be merged, according a logic that remains obscured to me. The main problem to me is not that this way of processing is tricky, but that it may lead to definitive "artistic" file corruption if i didn't catch the problem on time (my current issue).

I've read this thread.

The Force Pixel Alignement is no way a solution to me. I don't necessarily want my pixels to be aligned during my creation process. All I want is a merge function achieving  a logical and simple "you get what you see" result (blurred if blurred due to non-alignement. Plain elsewhere. The one i got on Photoshop during many years). I hardly understand this result not to be the nominal one. The real need. And I hardly understand how it couldn't be achieved, simply considering the simple trick I've found (adding some blank layers and process merging on a specific order) leads to solution.

This thread seems to be a dead end. Yet I can't imaging users to be satisfied with this fondamental dysfunctional function. 

Some news ?  

[ 1.6.11 on macOS Sierra ]

 

Link to comment
Share on other sites

Hi Wosven,

I understand the principe of alignement on the pixel grid (note: english is not my natural langage. I may hurt this langage integrity ...). Clearly a solution to prevent this problem. 

What I don't understand is : how the app manage to display in real time, before the merge, a perfect image (without blur), but fail to commit the layers consolidation (which should lead to the same result) when merging ? Should I understand that the image displayed before the merge is inaccurate, an approximation comput considering the layers aligned, and the real resulting composited image really considering the fact the layers are in reality not aligned is only computed when merging (resulting a logical blur) ? In this case, what is the purpose to allowed the user to work without the limitation of pixel alignement if he can't see the result before merging ? I would not understand the goal of this function. During a photo composition, I often need to go over this rule of pixel alignement to achieve a good result. So I though. Now there's the shadow of the doubt. It was just an illusion ? If the image displayed before merging is inaccurate and doesn't take into account displacement lesser than 1 pixel, I was a fool .... The fine adjustments I though to provide by slightly adjusting layer position were just mirages ....    

I couldn't open the joined file to the previous post with my AP version. But i try this proposition on my file. My blurred layer was not aligned on the pixel grid. A fact. But the blur was not the result of this non-alignement. By zooming the image, i can clearly see each pixel is spread in every direction (right and left, like a real blur. An initial 4*4 pixels square is now 8 pixels width . A strict blur due to a non-alignment should produce 5*5 pixels square at the most)

... 

I now realize I've done so many merges during my work, this last assertion (the grey one) is without value. The non-alignement blur may have built up at each merge. In this case, the problem remains total : if you don't imediatly realize that the result of a merge produced a blurred image (due to non-alignment of resulting layer with the pixel grid), after your second merge with this layer, your image is fucked up definitely.

If the hypothesis (the image displayed before merging is inaccurate and doesn't take into account displacement lesser than 1 pixel), my position remains the same : that's not the way the app should deal with merges. The nominal behavior should be non-destructive. If this hypothesis is right, I just don't understand the purpose of the option "pixel alignement". It shouldn't be an option. It should be forced. I can't see any use case ....  

 

Link to comment
Share on other sites

8 hours ago, olivierlafitte said:

What I don't understand is : how the app manage to display in real time, before the merge, a perfect image (without blur), but fail to commit the layers consolidation (which should lead to the same result) when merging ? Should I understand that the image displayed before the merge is inaccurate, an approximation comput considering the layers aligned, and the real resulting composited image really considering the fact the layers are in reality not aligned is only computed when merging (resulting a logical blur) ? In this case, what is the purpose to allowed the user to work without the limitation of pixel alignement if he can't see the result before merging ?

Like you I don't understand the purpose of "seeing" (and having) not whole pixels if the applications need to align them when merging, producing a blured result.

They should only use whole pixel. Another strange behavior is when moving the Bugged_layer: it's not aligned on the pixel grid, and the display show a half/third of  a pixel. But when we move the object to align it to the grid, this half/third pixel is displayed as a whole pixel. Perhaps the apps should keep this behavior when dealing with vectors, and keep whole pixels when working with rasterized content, to ensure sharpness.

When dealing with only 3 layers, it's simple, but with a lot more it would be difficult, and if this result is from drawing or selecting and dupplicating part of an image, it's a problem since all the other pixels other than those not-full-pixels are in the right position (or should be when we dupplicate). Depending of the size (halves, thirds, etc.) the app should convert them to whole pixel or nothing when dealing with merging layers. Those should only be used as halves or thirds when modifying DPI or resizing a layer.

 

9 hours ago, olivierlafitte said:

I just don't understand the purpose of the option "pixel alignement".

Or the purpose of less than whole pixel if in the end it means the app move the whole object in the merging operation, resulting in blured images.
Perhaps instead of halves or thirds of pixel, the apps should select whole pixels with less opacity to compensate or average colour.

Link to comment
Share on other sites

The blur (fuzziness) is the result of antialiasing. The alternative is what is often called "jaggies," because they are small squared off steps along edges that give them a jagged appearance.

The purpose of antialiasing is to create smooth looking edges for images that are not fully & completely pixel-aligned, for example the rasterized output of vector objects, which are defined geometrically rather than by a bitmap (pixels on a grid).

Merged raster layers will include at least some antialias smoothing if any part of any of the merged layers is not completely pixel-aligned, for example a curved vector line.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

there's no reason to have antialiasing in the middle of a plain selection (this blur can happen after duppicating large parts of a photo too, not only on thin drawings), it should only occur on the outside of the selection. And since we can have perfect merges without modifying antialiasing, the bug is elsewhere.

Link to comment
Share on other sites

4 minutes ago, Wosven said:

there's no reason to have antialiasing in the middle of a plain selection (this blur can happen after duppicating large parts of a photo too, not only on thin drawings), it should only occur on the outside of the selection. And since we can have perfect merges without modifying antialiasing, the bug is elsewhere.

It can happen anywhere there are edges (color or intensity transitions) that are not pixel-aligned, including in essentially all digitized photographs. You can see this by zooming in on a photo until individual pixels are visible.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

But since it seems like one of the layer is moved to be aligned on some invisible pixel edge before merging, resulting in blured image, that's a bug. It doesn't happen only on edges, but also with big part of images dupplicated (for applying a color adjustement for example).

Strangely, I had no problem merging all visible layers when this happened. But the purpose of merging part of the layers was to avoid having too many layers after doing some tests and modifications, not having  a merged image (this we can have when exporting in another format).

Link to comment
Share on other sites

1 minute ago, Wosven said:

It doesn't happen only on edges, but also with big part of images dupplicated (for applying a color adjustement for example).

Duplicating part of an image creates an edge around the perimeter of the duplicated part, so for example if you do anything that changes the color near that edge visible anti-aliasing likely will occur. The same thing can happen with blended layers, depending on the blend mode, opacity, etc., or for anything else that creates a different color, intensity, opacity, or whatever transition anywhere more than one layer is involved.

IOW, "edge" in this sense refers to the edges of individual pixels, not objects or images or anything else composed of or represented by those pixels.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

33 minutes ago, R C-R said:

Duplicating part of an image creates an edge around the perimeter of the duplicated part,

Thanks for this explanation, but I'm not so dumb as to not knowing where is the edge of a selection, please re-read my post before giving such answers. I said all the duppicated part end up blured after a merge layer.

Link to comment
Share on other sites

7 minutes ago, Wosven said:

I said all the duppicated part end up blured after a merge layer.

But I thought you also said a color adjustment was applied, or at least that was an example that produced the blur. I am I wrong about that?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

3 hours ago, R C-R said:

an example that produced the blur. I am I wrong about that?

No, usually (but the special ones adding blur), those layers don't add blur, they only add weight to the file, and at some point, when there's too much layers and when you're happy with part of the modifications, that's when you want to merge part of those modifications.

Merging the adjustement layers is usually easy... that's when you want to merge portions of the image that came the blur problem.

To avoid this, for unimportant files, I'll only import/use an exported result of the image, and I'll delete the .afphoto file once the document is send to print. If I want to keep some part merged, I'll take time to create masks of those different parts, use a "merge visible" with the needed layers, and use those masks to only keep the selected areas.

Or I'll work on the exported file (or Merge visible result) if the original isn't usable without those modifications.

 

The problem here is with the Merge down option — not the merge visible layers — that can produce blured results.
I couldn't obtain the same blured result as above with the drawings in the Bêta version, but the result isn't as sharp as expected (for this, I need to dupplicate the result and lower opacity).
And I try to avoid Merge down now, but I remember encountering this problem on a file I spend hours working on.

Link to comment
Share on other sites

Wosven, R C-R,

Here is simple presentation (I'm not proud of ... but I hope it's clear. It's the main goal) that sums up the previous statements.

merge.jpg.fd23dd4f7a94f815341878b88e1b38bd.jpg

 

The problem is no matter the pixel alignments options are on, as soon as you process a transformation that is not a simple displacement (rotation, skew ...) on the content of a layer (which is a basic use for composition), you produce a NO-pixel-aligned layer. And the way AF deals with merge of pixel-aligned and no-pixel-aligned layers is (at least for common users) a mess.

  • Merging a no-pixel-aligned layer into a pixel-aligned does the job: contents are preserved. The resulting layer is aligned. And problems are over. Great.
  • Merging a pixel-aligned layer into a no-pixel-aligned does a mess: BOTH contents are blurred. The resulting layer is not aligned. And by no way there's a way to retrieve a crisp original content by adjusting layer alignment after. The blur is build-up, commit. And it might be the begging of your problems cos, because the resulting layer is still not aligned, you can now spread this effect to other layer contents with futur merging operations (and each time, the blur build up to achieve a foggy content by the end .... ) 

When I switch from PS (a very old version) to AF, I was first amazed by the fact AF doesn't commit layer transformations. If you proceed a rotation, a skew on a layer content, the transformation is not destructive: if you proceed later the reversed transformation, you retrieve your initial data. Great feature. In PS, you had to commit your transformation. Transformation were destructive. It was not cool but it leads to a simple task for the app to manage layers merging.  

A simple (laborious) way to avoid this problem in AF is to immediately merge a transformed layer into a new blank layer: the transformation is then "commit" in the new pixel aligned layer (PS behavior). We lost the capacity to correct it later but we are sure to preserve the global file integrity along the way.

I don't understand the way AF deals with merge. Maybe a developper or a pro-user can justify a use case when this current behavior is useful, but I can't see. For a casual, non-professional  use, to my opinion it's a problem. The fact merging a pixel-aligned layer into a no-pixel-aligned leads to blur BOTH contents is so far a "bug" to me. A real pin in the ***.

Wosven, we definitely share the same problem. Merge some layers in our workflow each time an intermediate result is fine to maintain a reasonable amount of layers in our file. I though this was a common way to work. Maybe not. Cause doing so, at the moment, is not simple in AF.

I hope this behavior to be adjust in further versions (or that someone gives me the right way to work with this app which is by every other ways (... I got problems with gradients that are not fine to me. Maybe due to my colorimetric space ?)) a great app, a great alternative to PS, that is not an option for a non-professional user due to its price.  

 

Link to comment
Share on other sites

3 hours ago, olivierlafitte said:

The fact merging a pixel-aligned layer into a no-pixel-aligned leads to blur BOTH contents is so far a "bug" to me.

I could not understand what you meant in most of your post, but in context the above was perhaps the most puzzling statement in it. When you merge two layers into one, their contents are merged together, so what is this "BOTH contents" you are talking about? A merged layer cannot maintain the contents of the two layers independently of each other. The merged content is either pixel-aligned or it is not.

It might be a lot clearer what you mean if you can post a small, two layer .afphoto or .afdesign file so other users can download it & merge those layers for themselves to see what you are talking about.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

So my whole post was a total failure .... :) .  I should improve my english.

By "content" I means initial content of each layer before merging, i.e : square I for layer 1 (the background layer), square II for layer 2 ... .

  • On step C of the left process, squares 2 and 3, just merged into one layer, are blurred (artefacts are not the result of the jpg compression: it's a real blur)
  • On step C of the right process, squares 1 and 2, just merged into one layer, remains intact.

merge.jpg.aa918ce0608f2b7bfb6b6334799e46ea.jpg

According the order of merging, you achieve a fine or a blurred result. Merging a no-pixel-aligned layer into a pixel-aligned layer is the right way to annihilate the pervers effect of no-pixel-aligned layer during merging. If before step C, you merge layer 2 into a new blank layer (doing so, you commit the transformation, but you also "convert layer 2" into a pixel-aligned layer), you got the same final result as the right process. The right one (.... the one a non-professional user would like to got I think).

The fact merging a pixel-aligned layer into a no-pixel-aligned leads to blur the initial content of BOTH layers is so far a "bug" to me. If this blur was due to the fact transformation of one of the two layer remains not committed (meaning in this example rotating square II in reverse would lead to the perfect initial square ), I could accept it. It would by tricky, but there would be a functional reason. But it's not the case. Transformation are committed in each case of merging (which is logical)   

I join the AF file at step B for test.

 

mergeLite.afphoto

Link to comment
Share on other sites

Thx,

It works and it's a one click process (versus three for my current solution). The Rasterise function commit the transformation and convert the layer to a pixel-aligned one.

Fine ..... But ...

It remains a problem to me. Cos you can forget to process this operation (it just occurs to me and I lost a 40h work. I didn't realize immediately that I've blurred my main layer and I save my document ..... a pure nightmare). So working with AF is so far a bit dangerous for nerves ....

A part of my question remains : does this behavior got a real use for some users ? Personally I can see one. As long as transformations are committed as soon as you merge your layer. On the other hand,  it's hard to think it's a bug, cos it's so obvious and linked to such a fondamental function that I can't believe it wouldn't have been reported and corrected before (the correction being so simple: auto rasterized the bottom layer before processing merge. A one line code correction maybe....).

Clearly to me, it's fondamental this behavior to be adjust to definitely shift from PS (I had opened only one time for few months) to AF. Or a warning to be implemented when your about to corrupt your data. Did the Beta fixe something ? 

And I didn't completely understand the options "Pixel aligned" and "Pixel Movement" (I use the French version. I don't know the strict english name of those options) since a simple transformation as a rotation corrupt this logic (the only the simple nominal behavior works with translation function. Maybe useful for pixel-art amateur ....).

      

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.