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

Recommended Posts

Sorry if this is in the wrong thread. 'Search' does not bring up the solution. Or is it the same kind of problem? Your help welcomed anyhow; thank you in advance.

When I create a layer (in this case, of a line drawing) and embolden it 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.

The same thing happens even in the base layer: opening Curves creates a layer that CANNOT BE SAVED. Even PS 'Elements' can do this!
(Affinity Photo  1.6.11. A new purchase, so I am still learning my way around.) Thank you.

Edited by GHS
Link to comment
Share on other sites

8 hours ago, olivierlafitte said:

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 ....).

Basically, "pixel aligned" means everything fits into a pixel grid, completely filling each pixel with exactly one color, with nothing 'leaking' into adjacent pixels. (Here, "color" includes transparency when applicable to an image format.) Outputting (exporting) a document to a 'flat' raster image format always creates a pixel aligned image because individual pixels can only have one color & opacity.

However, this not true for document formats like Affinity & many other apps support that allow moving raster images by less than whole pixel values, multiple layers of different dimensions blended in various ways, vector & text objects that are not based on rasterized pixels, rotating raster images by arbitrary angles around arbitrary centers, or various ways of distorting raster images (like warps, shears/skews, or perspective adjustments).

Any combination of these things can cause pixel misalignment in document using these formats. This is a very common cause of blurriness, even when layers are not merged.

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

Yes. I got this point. But what I find tricky is the fact that the activation of those both options didn't prevent at all misalignment cos like you said, rotations, warps, shears/skews, or perspective adjustments (no mention of various filters)  corrupt this state. Only the displacement tool works fine with these options and guaranty that your workflow remains a full pixel one from beginning to the end.

Finally those options (which are probably dedicated for web design workflow) are misleading to me. Maybe they should be automatically shut off when you process a transformation that corrupt alignement. Or a warning should alarmed the user. 

The more I think, the more I think the concept of un-aligned layers which is in theory great, powerful, is debatable. For most users, casual user like myself, the reference is what is displayed. To display a misaligned layer, AF does the job to calculate full pixel translation. That what the user see, and if didn't configure the UI to display layer coordinates, he can easily though he has a simple rasterized layer in front of him. That was always the case in my old version of PS: every pixel layer was rasterized (cos transformations leading to comput a full pixel image to approximate the result of the transformation were committed (rasterized) immediately). Only the vector layers could be rasterized.

It's a powerful concept that AF enable user to process successively multiple transformations on a layer without damaging the original data (impossible with my old version of PS), but it leads at the end at some confusions by introducing misaligned layers .... 

If only the merge function would process the logical result (the one, most of the users would like to got I think) when merging (result you got if you just rasterize the bottom layer before merging, see previous post), it would be ok. Seamless. If this current behavior is not a bug (ie. if it has a real function for some users), I wish there was an option to constraint merge function to process as I attempt. I'm sure it would glad many casual users ....  

 

Link to comment
Share on other sites

26 minutes ago, olivierlafitte said:

Finally those options (which are probably dedicated for web design workflow) are misleading to me. Maybe they should be automatically shut off when you process a transformation that corrupt alignement. Or a warning should alarmed the user. 

There are dozens of uses for free rotations, warps, shears, blends, & all the rest of it. Try browsing through the official video tutorials or YouTube 'channels' dedicated to graphics editing to get an idea of the many ways they can be used. Pixel misalignment & the resulting anti-aliasing it causes is not just an inherent possibility in these processes, it is usually the intended & expected result because it smooths what would otherwise be ugly visible artifacts in the output.

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

1 hour ago, olivierlafitte said:

un-aligned layers

My 0.02 €: There should be no difference if layers are aligned or not. They should anyway composite the same way, using the same algorithm, regardless merge method. In display, layers should combine at document dpi, and when merging layers it should follow the same method and result a layer with document dpi.

(Pixel alignment does not really have any role in this discussion. Of course at pixel level aligned image looks different from non-aligned, but question is that merged result should look the same regardless the merging method.)

Now if you are saying that merging layers and get in export different result than if you were doing just export to layerless format, that sounds like a bug. 

There a couple unclear things that affect to exported image:

1 multiple merges tend to erode image quality more that one single merge operation.

2 resample method: in export you can select resampling algorithm. In merge you cannot. There is a rumour that AP uses internally nearest neighbour method in merge operations.

Link to comment
Share on other sites

R C-R,

I got the point. From beginning. The problem for me is not that some transformations lead to blur a bit the source image. It's logical. There's no other way: the app had to comput a resulting image and due to pixel model and the resolution limitation, some rough approximation are needed leading to a blur effect [it's the blur you observe on my presentation on step B for square 2].

But the blur that occurs during the merging of a pixel-aligned layer into a non-pixel-aligned layer, THE problem pointed in this thread, is something else that can't be justified (so far). Proof : if you follow the right process of my presentation, the results is perfect (the only blur you got is the on due to the transformation on step B)   

Link to comment
Share on other sites

Fixx,

The fact that you introduce here the notion of dpi in this thread troubles me. Actually, in my case, my works are mainly pixel ones and not enough gorgeous to be printed. At the end, before exporting it in a jpg format to eventually share it to someone, I always merge all my layers. It's an habit. It's a way to act the work is finish (no way to rework it). Due to the fact I often process of resizing during export, I never chalenge the quality of the export.

But the fact you're talking of DPI make me realize now that users, more professional users, or user's who mixed rasterized layers, no-rasterized pixel layers and vector's ones, who's reasonable goal is to preserve data until export, are fully interest by keeping their un-rasterized vector layers intact. It's logical they don't process unneeded merges that lower the quality of their work not intended strictly to be seen on a digital display at its nominal resolution. 

 Now I got it. So thx.

..... but, my problem remains.

When merging layers, which is a nominal function, that lead to rasterized the layers to be merged, you obtain a different result according the fact the bottom layer is pixel-aligned or not. I can't find a reason that justify the blur that occurs on the step C of the left process of my presentation. All the more that if you first proceed to a rasterization of the bottom layer, you got a perfect result.     

 

 

Link to comment
Share on other sites

14 minutes ago, Fixx said:

In display, layers should combine at document dpi, and when merging layers it should follow the same method and result a layer with document dpi.

The display dpi (ppi if you want to be picky about the terminology) & the document dpi/ppi are two different things. In fact, if you consider all the layer types possible in the Affinity document format (Image, Pixel, vectors, text, masks. live & destructive adjustments, etc.) & the different display options (zoom level & in Designer the 4 different view modes), an Affinity document could include multiple dpi values, objects that are not even defined in dpi/ppi terms, all of which can be displayed in different view modes or screen resolutions, & rendered at 2 different view qualities & associated settings, using one of several hardware or software based renderers.

There are far too many possibilities to make it practical to base everything on dpi, whether for merges or anything else, either for display or export.

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

29 minutes ago, Roxfall said:

It is a bug plain and simple. Nobody uses misaligned layers for anything but corrupting merged layers. Fix it please for the love of all that is unholy and right with the world. ;)

I do not understand what you mean by "corrupting" in this context. If you merge layers, whether they are pixel-aligned or not, the results will be different from what any of the un-merged layers look like individually, so in that sense all merges are 'corruptions' of the individual layers that are merged.

Besides, as has been mentioned several times, vector & text objects rarely can be pixel-aligned to begin with -- consider for example a vector ellipse or any other vector shape with a curved path, any of the polygons with other than 4 sides or rotated to some arbitrary angle, or any text block using anything besides a completely squared off monospaced block font, & even then only when not rotated, sheared, or otherwise deformed.

Even if you consider only documents with nothing besides pixel layers & the limited ways they can be edited in Designer vs. in Photo, there are only a very limited number of edits you can perform on them that does not result in either edge blurring do to anti-aliasing or the stair-stepped jagged edges known as "Jaggies." Either one is a 'corruption' of the idealized representation of a raster image as a (pixel) resolution independent vector-like object, which of course it can never be.

Plain & simple, this is not a bug; it is inherent in the document format itself, not just in Affinity apps but in any app that supports similar layer types & edits.

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

23 hours ago, olivierlafitte said:

The fact that you introduce here the notion of dpi in this thread troubles me.

Well, it is just that [image]layers may have high resolution content and when you merge all is resampled to document dpi. That should really not affect merging result when using different merge methods.

Link to comment
Share on other sites

On 4/10/2019 at 3:03 PM, R C-R said:

Plain & simple, this is not a bug; it is inherent in the document format itself, not just in Affinity apps but in any app that supports similar layer types & edits.

There's no way "it's inherent in the document itself", since just applying a rasterize operation on the bottom layer you're about to merge before merging leads to the perfect and expected (and logical) result for most of us. A result without any blur.

  • Rasterize bottom pixel layer and then merge layers => perfect result. Merging didn't affect the quality of the data (as does PS). Before and after the whole operation (rasterize+merge), you got visually  strictly the same result.  
  • Directly merge the layers =>  the content of both initial layers are blurred.

From the beginning of this thread, I don't understand how this simple fact can be ignored. Maybe it's due to langage (english is not my natural langage and there's no doubt some of my sentences are incomprehensible). Maybe we didn't deal strictly of the same subject :

Maybe some got in mind the case when merging deals with non-pixel layers. In this case, yes, data of the non-pixel layer is necessarily affected due to the rasterization of its content before merging. No problem with that. It's logic. It's not what this thread is dealing about (it's dealt with pixel layers, normal blending, full opacity ).

And maybe there's a difference between the rendering of a pixel layer whom the content had be transformed before and after it's rasterization (in this case, rasterization (not a real-time operation) should logically lead to a better result (i.e less blurred), cos it can use more complexe algorithms) [to my experience : the result are strictly the same. Besides, the free wrap function which is far more complexe forces the user to commit its transformation. Which leads to think that for other transformations, the application achieve to comput and display the same image before and after rasterization]

But, considering the bullet points above, no acceptable justification had been given so far (I don't say there's none ... I'm neither an expert, neither a professional user).

So far it's a bug (unless there's hidden interest). And there's an alternative way to achieve the logical result that people who opened this thread expected (green bullet point above).

Those peoples, as myself, simply would like the application to produce nominally the result achieve  with this alternative process. Who wanted to get a blurred image when merging when it's easily  possible to get the perfect one (one line of code maybe) ? What the use ? Where's the gain ? If there's a gain, that what this post should eventually deal with now.

  

Link to comment
Share on other sites

The fact that Affinity Developers try to convince us that it's "not a bug" is so frustrating. Seems like they never used their editor and don't understand simple UX rules. This is really disappointing and sad. Ok we got it – you didn't think of such scenario while developing Affinity, that's why such strange behaviour occured. Well, how about to fix that now, when a lot of people ask for it? – "NO, IT'S NOT A BUG, GUYS! SUFFER MORE"

Link to comment
Share on other sites

I've followed this topic since my last post because checking/unchecking "Force pixel alignment" and "Move by whole pixels" certainly did not solve this problem and I've lost hours of work myself noticing too late that my merged layer has been blurred. I really admire you advanced users for your patience taking the time and effort to investigate, doing your homework to find out how and when the blurring happens, how to work around and sharing all these results.

The ignorance of Affinity Developers frustrates me also. I imagine if I delivered work to my customers with such "anti-aliased" line-art, trying to explain to them that the file was a perfectly healthy, high quality image, not corrupted or blurred just anti-aliased which is perfectly normal, they wouldn't be very happy with me... so instead I calmed down, did the lost work again and delivered a quality file as expected of me. I would expect a similar professional behaviour from developers. Bug or not bug, this blurring has no place in Affinity Photo which is supposed to be an intuitive program, behaving as expected, that lets you concentrate on creative work instead of worrying all the time trying to notice the moment your layer goes corrupted/blurred.

Link to comment
Share on other sites

1 hour ago, MasterBooth said:

I've followed this topic since my last post because checking/unchecking "Force pixel alignment" and "Move by whole pixels" certainly did not solve this problem and I've lost hours of work myself noticing too late that my merged layer has been blurred.

If you have "Move by whole pixels" enabled it is entirely possible that an object can become pixel-misaligned, even though "Force pixel alignment" is enabled. That is because "Move by whole pixels" does exactly what it says; that being moving things by whole (integer) steps. So for example, if the x value is 10.5 px, moving it by one pixel to the right moves it to 11.5 px.

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

2 hours ago, R C-R said:

If you have "Move by whole pixels" enabled it is entirely possible that an object can become pixel-misaligned, even though "Force pixel alignment" is enabled. That is because "Move by whole pixels" does exactly what it says; that being moving things by whole (integer) steps. So for example, if the x value is 10.5 px, moving it by one pixel to the right moves it to 11.5 px.

“Force Pixel Alignment” is clearly something of a misnomer, since it doesn’t actually force anything.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

Quote

If you have "Move by whole pixels" enabled it is entirely possible that an object can become pixel-misaligned, even though "Force pixel alignment" is enabled. That is because "Move by whole pixels" does exactly what it says; that being moving things by whole (integer) steps. So for example, if the x value is 10.5 px, moving it by one pixel to the right moves it to 11.5 px.

I know this very well, it's been mentioned here before and as I said I've followed the topic and read the posts. My point is that these checkboxes don't solve the problem, even if you understand what they're supposed to do and have them checked/unchecked the way suggested here earlier.

Link to comment
Share on other sites

  • 2 weeks later...
On 4/11/2019 at 10:23 AM, olivierlafitte said:

There's no way "it's inherent in the document itself", since just applying a rasterize operation on the bottom layer you're about to merge before merging leads to the perfect and expected (and logical) result for most of us. A result without any blur.

  • Rasterize bottom pixel layer and then merge layers => perfect result. Merging didn't affect the quality of the data (as does PS). Before and after the whole operation (rasterize+merge), you got visually  strictly the same result.  
  • Directly merge the layers =>  the content of both initial layers are blurred.

If this is what's causing it, then the default functionality should be: rasterize all layers first, then merge them. 

If you're hellbent on having a "merge a blurry mess" function, then call it that, and make it a separate thing.

I'm done arguing for common sense, you've lost a customer over this program-defining "feature".

I'll check again next year to see if it's fixed yet, will be using different software in the meantime. Yes, it's that big a deal.

Affinity Photo: just like photoshop, but you can't merge layers. :(

Link to comment
Share on other sites

This whole thread is just a crazy mess and should have a disclaimer posted by a moderator at the beginning.  I've lost work,  discovered my own workarounds,  discovered that other people have too,  wasted my time reading this mess (but thanks to the people who understand the problem and aren't just posting a blind fanboi defense to something they either haven't noticed or don't care to acknowledge),  I've ignored a user and again wasted time and work again and again.  I'm frustrated and angry.  and once AGAIN I've stopped my work to research yet another quirk of Affinity workflow.  I find it a great program with lots of potential but, Serif,  you need to change some things in order to not turn off everyone interested.  All of these people with their dealbreakers and the peddlers of misinformation! This whole community seems completely dysfunctional and unprofessional.  There's more intelligent conversations on the Steam forums for crying out loud.  

Probly my last post cause I've just had it up to here!

 

Link to comment
Share on other sites

  • 2 months later...

I'm aware it's been a couple months, but this problem is getting infuriating for me.

I work with stock images, which of course need to be resized and combined. Force pixel alignment is always on. Move by whole pixels is always off. I always ensure there's no decimal points in any Transform fields.

Often, however, I will have an issue like this: I will take a stock image, work with it awhile, and resize it. There's still no decimal points to be seen, or sometimes if there is, I will alter it to remove them. Then, attempting to merge this initial layer (either as the same file, or a new one) with any Adjustment layers blurs the entire image. Multiple merges (or exports, for that matter--as .PDF even, which to my understanding should NOT anti-alias this way?) blur it further. Even creating a blank layer and merging it down with the existing one, or merging the existing with the blank, blurs it badly.

Anti-aliasing aside, what irks me is that the preview space is perfectly clear until this merge or export. I think a what-you-see-is-what-you-get approach is extremely important. I shouldn't have to guess whether my export will have full clarity or be blurred. The program should be working with me to create what I want; I shouldn't have to fight with it and struggle to predict what it might do.

One thing I noticed is that if I pay -very- careful attention to which direction the blur is occuring (shifting left or right 1 whole pixel, for example), I can move the layer -in advance- 1 pixel in that direction, and then the blur on merge will not occur. This suggests to me that the anti-aliasing is taking into account pixel position that isn't actually accurately reflected in the Transform fields at all, but my understanding of it's all too basic to be certain.

I really hope that we get a fix for this (and for the completely unusable Color Replace tool, but that's a whole other story), as I really like Affinity and would love to see it succeed. Such serious issues in such basic functionality are hard to work past, though.

Link to comment
Share on other sites

3 hours ago, Feralkyn said:

I will take a stock image, work with it awhile, and resize it.

Hi @Feralkyn & welcome to the forums. :)

When you resize it, is the stock photo identified in the Layers panel as a "(Pixel)" or an "(Image)" layer? 

When you resize it, are you making it larger or smaller than its original size? Either way, what is the ratio of the original to the resized version? 

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

4 hours ago, Feralkyn said:

Often, however, I will have an issue like this: I will take a stock image, work with it awhile, and resize it. There's still no decimal points to be seen, or sometimes if there is, I will alter it to remove them. Then, attempting to merge this initial layer (either as the same file, or a new one) with any Adjustment layers blurs the entire image.

Are you saying your project is just one layer with your image and some adjustment layers, and merging that set is causing the blurring?

Or is there an additional stock image layer involved?

Can you give us a screenshot including the Layers panel, and possibly a .afphoto file that demonstrates it?

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

  • 2 months later...
On 4/21/2019 at 6:17 PM, Roxfall said:

If this is what's causing it, then the default functionality should be: rasterize all layers first, then merge them. 

If you're hellbent on having a "merge a blurry mess" function, then call it that, and make it a separate thing.

I'm done arguing for common sense, you've lost a customer over this program-defining "feature".

I'll check again next year to see if it's fixed yet, will be using different software in the meantime. Yes, it's that big a deal.

Affinity Photo: just like photoshop, but you can't merge layers. :(

I agree, it is a bug, no other explanation possible.

My workaround for it  :

1) Group together the layers you want to merge (layers selected + ctrl +G)

2) Rasterize the group of layers

That produces a merged layer without any blurring.

I will never use ctrl +E (merge down) again until this bug won't be solved.

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.