Stokestack

Nope. That doesn't make sense. The OP wants to transform them together, not separately:

Yet another independent confirmation of this defect. How many people experience it but never know their work was degraded? Odds are: many. And then whittle those down to the ones who bother to come here and post about it, and the logical conclusion is that many of the people who actually exercise this software encounter it. But hey, enjoy the pile of grasping excuses you'll find among the dozens of posts about it.

I really wanted to support Serif for developing new art software (especially Designer, because Illustrator is dead), and I hate the software-rental rip-off trend. But their designers' detachment from reality, not to mention ignorance of good UI standards and design that already existed, has led to bizarre functional gaps and gaffes. I mean... this whole thread started with a simple request that should never have been necessary: Let us transform a selection. I mean... WTF? How does a NEW photo-editing/compositing application make it out the door without that in the last 20 years? The FREE software I got with my Epson scanner in the '90s had that (and still does). You can point out defects and make sure you suggest solutions that don't impede anyone else's workflow, and serve the most-common use cases and reflect industry standards. You can mock up a complete UI revision and grant free use of it, which again impedes no one's workflow. Yet the same apologists will endlessly attack it and defend dysfunction, like that which gradually degrades users' work through innocuous operations that are harmless in every similar piece of software (and should be in this one). I sincerely appreciate the fact that an employee or representative engaged with us in the thread. But I don't appreciate the insulting excuses and technically incorrect statements (peppered with citations of speculation from other customers as some kind of "proof"), and the condescending "You simply [undertake a number of steps that there was no reason to guess were necessary and are not indicated as necessary in the UI and aren't in competing software], so it's not a bug." Several people have independently demonstrated the blurring defect reported here, and nobody has been able to show why they should have guessed that their work was being ruined. Dan claimed he's sorry that I don't feel this software can be trusted, but that didn't hold up in further conversation. If Serif cared about users' work, it would either prevent it from being degraded, with the simple step we've suggested here; or at the very least WARN THAT IT'S GOING TO HAPPEN. There is no excuse for not doing at least one of those things. And that's that. It's sad to see that these applications are already moribund, hobbled by the same design defects, functional defects, and missing functionality that have dragged them down since their inception. Over and out.

Amen. Your request is succinct and nails it.

Hahah, they're just supposed to wait, for no apparent reason, for "understanding" to magically descend upon them? And that's assuming they realize that their work was degraded in the first place (which, as already pointed out, may depend on the type of imagery it is). Knowing what DPI and resampling are doesn't make any difference, except in being able to point out how defective Photo's logic is here. Nobody is complaining about that. Of course that's desirable. I never said anything to the contrary. I'm complaining that Photo doesn't do that when you are satisfied with the imported imagery's placement and integrate it into what's underneath it. It decimates the underlying image data; and nobody is denying that. Looks like we agree here. For pixel-precision work, I really don't want the software to do any resampling for me. Me neither, and the only way to avoid resampling both layers, according to the almighty authorities in this thread, is to rasterize the overlaying layer before the merge down. So you too must wonder why Photo shouldn't do this as part of the merge-down operation.

Again, the regurgitation of the DPI excuse without explaining why BOTH layers would be resampled. Which there's no way for the user to know. So why doesn't the software do that as a part of the "merge down?"

Nobody said it should rasterize after every step, so I don't know why you'd make that comment. The proposed workaround to the blurring was to rasterize and then merge down. The question is why doesn't Photo do that by itself, because as you agree: The layer being merged down is no longer its own entity and therefore the user loses the much-touted "separate control" over it anyway. So why isn't it automatically rasterized in the process of being merged? Why does Affinity choose to degrade the quality of the composition instead of taking the steps that will allegedly avoid doing so?

So what? You said: And again, that is not what's going on. The layer being merged down isn't becoming blurry; the underlying one is. Furthermore, you again failed to answer how layers acquire apparently arbitrary DPI. Somehow, with all source material coming from screen grabs with the same resolution, we have three different DPI; one of which differs by ONE dot per inch. Nor has anyone explained why resampling happens over and over, blurring the underlying layer more and more with each "merge down." Why? Why would you not simply resample the lower-DPI element to match that of the higher-DPI element and then blend them? Then why doesn't Photo simply DO THAT? Once the layers are merged, you've lost all of this highly-touted "control" over the now-merged fragment anyway. What exactly is the benefit of NOT doing this upon "merge down?" And again, you've yet to define exactly what this "control" entails or exactly what use case it serves or what benefit it provides to the user.

I don't care how many times you float the same excuses. I am not the only one to encounter this problem. Why not? I would never set pixel values fractionally. So that's a problem right there. WHY are they non-integer? Why keep repeating the excuse without saying how it could possibly arise? Nor did I set the document DPI. I'm the end user. Look at how long that thread was, full of speculation because clearly quite a few people are "unsure" of why layers are getting degraded. This excuse is a variation on the classic, "you're confused." No. There is no "confusion" here, because this entire mess is opaque. Which is not what I described doing. Again, if you have a layer that you're merging down onto an underlying layer, the top layer should be resampled to match the underlying one and blended. Why would you also resample the entire underlying layer? Again, this has never been explained. Why would an entire 4K image, for example, be blurred because you merged a 100x100-pixel patch onto it somewhere? If this isn't a defect, then explain this: Why would a user want his image blurred over and over? You're advertising some kind of benefit here: Really? Like what? What is the use case where all this implied "control" outweighs the likelihood of degrading your work? And, whatever it is, are you seriously going to argue that it's more common than taking an image fragment, transforming it, and compositing it into a larger image?

Thanks for the reply, Dan. I have reported this and it has been discussed in at least one (and, I think several) lengthy threads. Here's one: My comparison is exactly "apples to apples." The function I'm talking about is a fundamental operation in both Photo and Photoshop, and in any image-compositing application. Unnecessarily degrading the user's work is not "coding it differently." It's coding it wrong.

The transformed patch is the one with the so-called "wrong DPI." So it should be resampled to match the underlying layer and merged. Why degrade the underlying layer? I don't know why this same bogus excuse is floated over and over. And again, Photoshop doesn't have this problem. So it need not exist.

I guess the magical technology that makes marquees work as expected in competing applications has been lost in the sands of time.

Yes, because making and adjusting a rectangular selection should be the fussy, multi-tool/multi-step pain in the ass you just described. Which it is not in any similar application I've ever seen, from photo-editing applications to the free ones that come with scanners.

No. The entire underlying image is degraded (and repeatedly) when you merge a small transformed patch down onto it. No. We're talking about the selection marquee, not pixels. The marquee is not dependent on any particular layer; you can make one with no layer selected at all, in fact.

That makes no sense. The "benefit" is that you can make an exact selection, with no feathering of the edges.

Thanks for your response, Dan. But I don't recall seeing acknowledgment of the blurring problems on "merge down" or the announcement of any intention to fix it. This problem has been widely discussed and it degrades people's work. Missing features are one thing, but damaging image quality is another... which demands immediate resolution. So far we've seen none.

Good catch. The unwanted feathering is a deal-breaker. Thanks for that suggestion, but unfortunately it is not a viable workaround either, based on the evidence above. These absurd problems should not exist in shipping software, let alone software that's been out this long. I don't see any excuse for the large swath of missing features and image-degrading defects (specifically the blurring or softening of images when performing basic compositing, and the one cited above) in these products. Photo is supposed to serve the needs of image composers, and it fails in ways so varied and fundamental that I am actually considering going back to Adobe's rental rip-off just to ensure that my work isn't ruined. Affinity should just open-source these products and call it a day. They're clearly not interested in making them tools we can trust.

I've made a rectangular selection and I need to adjust its size to line up with an underlying image. But there are no resizing handles on the marquee and no way to invoke any that resize the selection and not the selected part of the image. This is a fundamental UI affordance in this kind of application. Its absence is embarrassing.

So... we're right back to the same "problem" that only Designer seems to have.

Mmmm I'm gonna say it's probably working correctly. The operation only affects layers you have selected. Did you have all the shapes selected? Look at the difference... Only the small shapes selected: someSelected.mov There was no overlap among those shapes. So if you take away each of the top layers from the one below it (and itself), you wind up with only the bottom layer (because it wasn't subtracted from anything). allSelected.mov Here the three shapes are indeed subtracted from the bottom one.

I think that workaround has been floated here before. We shouldn't even be discussing this defect a year later. It should be fixed.

I love the condescension of declaring that a ridiculous and laboriously-discovered workaround to a defect is "simple," as if we all should have anticipated that this application would degrade our compositions like no other... and then remember to undertake it every damned time we need to merge a component in our work. And if we get through five layers and then think, "oh shit, did I remember to RASTERIZE that second one," we get to go back and do it all over? Nah.

Let's all root for this simple request to reach its FOURTH birthday!

As opposed to what?

Well, the selecting of objects and then "create slice" turns out not to be a good workaround. I selected three layers in the Export persona and did "create slice," and nope: It created THREE slices. Incredible.