dmstraker

A thought: If shortcuts have been changed, does 2.2 install step back? Looking at Photo/Paint Brush Tool settings, for example, there are no shortcut keys set for changing brush hardness. I've not set these myself, but have changed a number of other settings. It does highlight a potential dilemma, but maybe the install can check for user settings and put the new ones in for each change only if the user has not already set them.

Testing brush improvements on Win10, APh 2.2: Shift + number key now changes flow percentage (in the same way that number key on its own adjusts opacity) WORKS FINE Shift + square brackets now changes hardness in 10% increments DOESN'T WORK (TRIED SHIFT ON BOTH SIDES) Number key in Paint Mixer and Smudge Brush now adjusts strength percentage WORKS FINE Fill with Primary colour has now been set with a default shortcut of Alt/⌥ + Backspace DOESN'T WORK (OK FROM EDIT MENU) Fill with Secondary colour has now been set with a default shortcut of Ctrl/⌘ + Backspace DOESN'T WORK (OK FROM EDIT MENU)

In Procedural Texture, adding Z or R numbers as custom inputs, you can type in a number and it's immediately calculated. The little up/down arrows work fine too. But when you roll the mouse wheel over the number, it is not calculated (and so has no effect).

It's a new one on me and I'm still puzzled as to what exactly might be going on. I've not heard of this happening with other applications. It would be enormously helpful if AP is unable to save remotely that it gave you an option to save locally rather than crashing out. Nevertheless I'm grateful for the knowledge and will follow your advice, Walt. Thanks!

Yes, 2.1.1. Saved to pCloud, a Swiss service and has proved very reliable. How might saving to a server cause such a problem?

I've just lost hours of critical work after "Save failed because ownership of the file could not be verified. The document must now be closed." I re-edited the image. An early save worked. A later save didn't. To say I'm unhappy would be an understatement. Version 2.2.1 Affinity Photo Edit: I tried resaving the original image (a jpg) with different algorithm (Lanczos) and restarted edit. I saved at regular points along the way. Eventually I hit the same barrier. I exported the original jpg as tiff and restarted, with the same effect. I also hit the same problem with a separate image which was a RAW .NEF file.

When a live mask preview is turned on, it still impacts the visible image when the mask is turned off in the layers panel. Effect is also seen when adjustment to which live mask is attached is turned off.

"Save failed because ownership of the file could not be verified." Plus the delightful "The document must now be closed" (with no chance of saving). Boom. Fortunately when I reopened it, it recovered where I was. Got me going for a moment there, chaps.

Well done and thank you to everyone at Serif for a momentous 2022. Please do have a splendid Christmas and New Year break, and try not to think about work too often (difficult, I know). As we say in Wales, Nadolig Llawen a Blwyddyn Newydd Dda (Merry Christmas and Happy New Year).

Looks like it's Windows-specific. Attached is what I saw after loading the Luminosity mask OK.afphoto file to 2.0.3. Thanks for checking on Mac.

Can't remember if I submitted these (also not found on search here, and beta database unavailable): As in attached and starting with gradient layer, black to white along x-axis. Add Luminosity Range Mask and adjust nodes as shown. When curve hits top or bottom edge of adjustment square, the effect is sudden, unexpected and presumably incorrect. Also when blur is increase, an edge effect around the periphery of the image is seen, much as would be found using a Gaussian Blur. It looks like a 'Preserve Alpha' checkbox is needed.

So I did a quick video for folks who might be confused (as I was).

No, but that doesn't stop it being a usability defect, as per notes above.

One last note, and perhaps something that Serif can address. In the Gradient colour panel, when you reduce opacity, the colour as displayed decreases to grey. But if the colour is still being used (as it is) in creating the gradient, then perhaps the colour should remain, hence giving some indication that you are going to still get the colour within the gradient. Image attached.

Understood and accepted. There's also the psychology of perception to consider. Looking at the red-with-zero-alpha node in the gradient panel or on screen, it appears to be transparent node. Yes, showing it as 'red with zero alpha' could be tricky. But cognition is often based on simple visual cues more than an examination of further panel data. And so (as with me), it is easy to assume that what is seen is all there is. This is what, in my development/QA/HF days we would have designated a 'usability defect'. There is clear logic in why it is what it is, but nevertheless it is experienced as a confusing difficulty. What the solution is here, I don't know. Nor is it a hill on which I plan to expire. I'll leave it to the good people in Serif to figure what to do about it.