Richard Liu

@MEB I am not averse to helping, but I am running behind an -- admittedly self-imposed -- deadline. Working for a few days (!) with the BenQ set to the default resolution is something for masochists. I won't be indulging. Working at scaled resolution with Metal support might be doable, depending on how how slow the system becomes. I didn't mention explicitly: I am using both the BenQ and the laptop's display simultaneously. I do notice some nervous "twitching" of one or both while working with Affinity Photo, especially when I've place some windows (typically, the Blending Options) on the laptop's, almost as if something were being redrawn very quickly. What about working on the laptop's display at scaled resolution? Could the problem be caused when Affinity Photo is working with both displays and the resolution of one (or/not) both is set to scaled? Has the problem been reported with other brands of monitors besides BenQ?

The default resolution is 1920 x 1080. I wouldn't have needed to buy an external monitor at all if I were satisfied with that resolution. What happens if I set it to that resolution? How long would I have to wait for the problem to occur at that resolution before I could conclude that it doesn't? Because in the meantime I could not work with Affinity Photo under those conditions. As I said, I had the impression while working with 1.7.2 and macOS 10.14.6 that the problem had been solved. In fact, I recall being informed when I first reported it HSL crashing Affinity Photo 1.7 that the problem had to do with Apple's Metal support in macOS 10.13.6, which I was running at that time. The mangled HSL control of versions thereafter was the price to pay for its not crashing Affinity Photo on High Sierra. I just recently switched to 10.14.6, so I can't swear that it hasn't always been in 1.7.

Hi, In 1.7.2 on macOS 10.14.6 this problem seemed to have been solved, but on 1.7.3 it's back. Here are the pertinent screen shots: The problem afflicts the BenQ SW271, not the MacBook Pro's builtin display; however, it doesn't happen all the time and, as before on macOS 10.13.6, moving the control to the builtin display, then back to the SW271corrects the problem until it happens again.

Just taking a really, really wild guess here, because I use Affinity Photo but not Affinity Publisher. In Affinity Photo there is a really bad bug that affects printing and exporting to PDF. Live filter layers -- I don't even know whether such things exist in Affinity Publisher -- are not being rendered. So, depending on what live filter layers I use and the blend modes that I use with them, the first thing that I will notice, say, in a print, is a difference between the colors displayed on the monitor and those of the print. Exporting to JPEG and TIFF are not affected, but exporting to PDF is.

@Janutsa, I use Affinity Photo to develop my RAW files, never to edit JPG, PNG, etc. So the crash occurred while working on an .afphoto file. I think that that message might have been generated by macOS. In that case, it would mean that the crash log is being sent to Apple, not necessarily to Serif. I am on macOS 10.13.6. If I understand correctly, some of my problems stem from errors in Metal that have been corrected in Mojave.

Just tying up loose ends here. I believe I discovered that this did not happen in the then current beta, and shortly thereafter 1.7.2 was released.

MacBook Pro 15" 2018 model with Touch Bar, macOS 10.13.6, AFP 1.7.2 I was working either with a Levels or Curve adjustment layer attending to out-of-gamut areas of a soft proof when AFP crashed. I wasn't doing anything I haven't done many, many times before. Several other .afphoto files were open in the same session. Here is the crash log: Affinity Photo_2019-08-22-231523_RRL-MacBookPro15.crash .

If I recall correctly, the cloning tool operates differently. Even though one could argue that, by its very nature, a source must be selected, it does not just select, say, the upper right or left corner of the image, depending on the side of the road on which drivers of the locale configured in the OS drive. If one attempts to click somewhere on the image without having used Option-Click to set a source, a very prominent warning from the Cloning Brush appears in the top right corner of the screen in addition to the still visible discrete prompt in the lower left corner. There is nothing inherently "right" about selecting white; it would be "righter" to select the color of the color picker if one must be selected by default. I wouldn't be making such a mountain out of this mole hill if it weren't for the fact that the behavior and even the wording in the Select drop down are so misleading that I spent lots of time trying to figure out what I was doing wrong. After all, although the "..." in "Select Sampled Color..." indicates that I might have to do something after clicking the item, a selection immediately appeared, the Deselect did not work, and "Sampled" is, after all, past tense, so, I thought, perhaps I must first sample the color.

Thanks. I had tried that initially, but noticed that, even before I had clicked on anything in the selected layer, a selection was already being displayed ("marching ants"). Clicking the Deselect icon didn't clear it; on the contrary, the program seemed to be cycling through selections. I decided then that I was doing something wrong. Now I see that, if I click anyway, it clears the selection and selects areas of the same color as the point on which I clicked. Why is it displaying a selection even before I click anywhere on the image? I spent most of my energy trying to clear that stupid selection. Why do I not have full functionality of the color picker when selecting the color? Surely this isn't the point of having a color picker. The "Select Sampled Color ..." dialog should preselect the color picker, just as other dialogs (in Develop) select the gradient tool or the paint brush. A prompt to drag it over a point of the desired color and click would also be helpful.

Here's a Quicktime screen recording using the beta: https://drive.google.com/open?id=1B_KnZ6GP5HroqGMpWR_FxAuS1Hjzsj-N Doesn't crash, just doesn't do what I expected. I use the color picker to pick one pixel of a bluish color, as evidenced by the color picker in the Color panel. When I Select Sampled Color Affinity Photo Beta selects what looks like shades of white or grey, but nothing around the selection point. Even with a tolerance of zero I would have expected that at least the point at which the color picker was clicked appear in the selection. Let me digress here for a moment. In the past few days I've been under pressure to develop and edit some photos. In my opinion, I'm not doing anything that should challenge Affinity Photo's capabilities, and I don't think I'm using any features that weren't already present in version 1.6. Yet time and again operations have failed to work in, or even crashed, 1.7.1. And I waste a lot of time ... using the production version. If something fails to work that I have never tried before -- Affinity Photo is the first such program that I have ever used, and I've been using it for less than one year -- I initially assume that I am to blame, i. e., that the feature does not work the way I expect. I waste a lot of time trying to get something to work that, finally I conclude, is broken, or at least worth posting in the Affinity forums. In more obvious cases I don't waste a lot of time concluding that something is broken. I waste it instead finding a solution, preferable a work around in 1.7.1, but as a last resort using the current beta. I don't mind contributing my time to testing betas when have the time. But I have the impression that things are broken in 1.7.1 that were not broken in 1.6, meaning that there isn't really a reliable fallback when I'm under pressure. I understand the special challenges that the Affinity products face, particular on Apple platforms. Apple, it seems, is always diddling with the graphics in their devices, and things that used to work in one version of macOS don't in another, or, sometimes do, only differently. So, whereas a developer might decide only support the latest major version of macOS, a user, for the same reason, might decide to delay adopting it. Metal, though supported in macOS 10.13 and 10.14, seems to be the cause of some problems in 1.7. And then there are the usual requests for improving how some layers work. Even assuming you agree, how should that be done while retaining compatibility with previous versions of the layer? Nobody is going to thank you when he/she opens a favorite .afphoto file to find that the document look quite different, and then has to hunt down the layers responsible for the new look and tinker with their controls. Nevertheless, I would urge you to consider not implementing any new features in 1.8 but instead increasing stability, speed, and generally getting things like printing to work as well as they should. I believe Apple did something similar with Snow Leopard.

I have attached a mask layer to a Gaussian blur live filter layer. After inverting the layer I begin painting over objects to be blurred. Some parts of those objects display "tiled", e. g. in you can see a vertical line under the period of the previous sentence. Look more closely and you'll see the tiles. I'm running Affinity Photo 1.7.1 on a 2018 MacBook Pro 15" and macOS 10.13.6. Turning Metal computing off and restarting didn't alleviate the problem.

Yes, 2018 MacBook Pro 15“.

I was just going to send this: "No, sorry, I just tried on a document that I happen to have open. I could not reproduce the crash." Then I decided to sample a 17 x 17 px patch, and it promptly crashed when Select Sampled Color... . Then I opened a document that I had previously saved (i. e., it isn't new) consisting of a single Background pixel layer and performed the same experiment. Affinity Photo did not crash.

Here are the two tiff files again: https://drive.google.com/open?id=17A4tgZyqeRVQq-LY_Dkv3T5kR4cAYn76 (with photographer in lower left corner in the bushes) https://drive.google.com/open?id=1R4cwZ6aDTKtM7Nt7XPu4hLqUPoaMvIx1 (photographer has left the site leaving the bench visible on which she was sitting) By the way, the spots in the loupe where probably due to the fact that a painting brush had been selected and I had increased the brush size.

In fact, with Metal still active, I deleted the High Pass layer, recreated it, inverted it, and tried again, and was able to do what I couldn't before. I'm puzzled about the cause of the problem, and am not so naive as to assume it won't happen again. As I saved the working version of the .afphoto file over the misbehaving one, I would have to whether I can find it in Time Machine in order to try the same operation without Metal. Should I? It doesn't seem that many people have encountered this or related problems, does it? And someday ... real soon now ... I'll upgrade to 10.14, which, if I recall correctly, corrects some problems with Metal in 10.13. Here are the specs that you requested: