Richard Liu

Hi, I'm running AFP 1.7.1 on a MacBook Pro 15" 2018 with macOS 10.13.6 High Sierra. In the print dialog the "thumbnail" of the photo that AFP is supposed to print is displayed with a red overlay, like so: This didn't seem to be specific to the printer. I changed the printer to my HP OfficeJet X476dw MFP, but the thumbnail continued to be displayed with the red overlay; however, it was not present on the printout ... but neither was a good part of the photo. That's when I noticed that Fit Type and Scale had been changed to "Scale" and "100." Changing Scale to "Fit to Printable" caused the "100" in the Scale field to be greyed out, the whole photo was displayed in the thumbnail and the red overlay was gone approximately like so: "Approximately" because, once I set Fit Type, I save all the settings as a new preset, and when I exit the print dialog and reenter it, Fit Type has been changed to "Scale" (instead of remaining as I set it) but "100" is greyed out and the thumbnail displays properly. I might have noticed the size mismatch in the thumbnail with the red overlay if I had not panicked and overreacted to what is perhaps intended -- by the printer driver? -- only as a helpful warning. So I leave this "bug report" just in case somebody else encounters the problem. I don't know how that setting in the original preset was lost. When I select "Show presets..." from the Presets dropdown I see that the original preset, Plus Glossy II, A4, has indeed "Fit to Printable" for Scale, just as does the new preset, Plus Glossy II, A4, Fit to Printable.

I think it very useful to see what what James is doing on the keyboard as he shortcuts his way through a recipe.

If you’re trying to get the control to distort in Mojave and it’s not, maybe it’s because, as @Andy Somerfield explained it, the distortion is the price for not crashing, and the crashing of 1.7.0, at least in my case, was due to a problem with Metal in High Sierra that Apple fixed in Mojave (italics = from memory, please verify).

.141 no longer crashes on me (MacOS 10.13.6 High Sierra + BenQ SW271). The HSL control sometimes — unpredictably — becomes distorted, but moving its window onto the laptop’s Retina display then back to the BenQ fixes it. i have found no firmware update for the SW271. Furthermore, I think it was @Andy Somerfield who said that neither 1.7.0 nor .138 and .140 were crashing on macOS 10.14 Mojave with the same display. Can somebody check what Mojave reports in About This Mac | Displays?

James, Thanks for these new tutorials. I find that I'm still not clear what I should do in the Develop persona that could also be done later in the Photo persona, as there is considerable overlap between the tools provided in the former and the more basic adjustment and live filter layers in the latter. For a time I was just concentrating on flattening the image, having opened the RAW file without applying curves, e.g. pushing the black point a bit away from the left edge of the histogram, pushing the midtones toward the center, and recovering highlights, opening up shadows, etc. Sharpening, clarifying, increasing contrast, etc.could be done in the Photo persona, after all. But then I discovered haze removal. It requires a pixel layer to work on, so it seemed to make sense to do some of the things in the Develop persona that I had intended to do later. So now I am thinking that I should perhaps do some sharpening and perhaps introduce a curve during development. I would find a tutorial on the theme, what should I consider doing in the Develop persona and what might I want to postpone for later, extremely helpful.

As I report elsewhere, with 1.7.1.141 I, too, experience the distorted HSL control problem. It doesn't always happen, and I am at a loss to predict when it will. At any rate, when I move just the window containing the control to the laptop's (MacBook Pro 15" 2018 model) display the control displays normally, and when I then move the window back to the external display (BenQ SW271) it continues to display normally ... at least, until the next time the problem occurs. By the way, I am running macOS 10.13.6 High Sierra, and About This Mac | Displays claims that the BenQ has a 61-inch diagonal, even though it's only 27 inches. I suppose a luxury workaround would be to keep the control window on the laptop's display.

OK, thanks. As I note elsewhere, I've been able to clear up the distortion by moving just the window with the distorted control to the laptop's retina display, where it displays properly, then back to the external monitor, where it remains normal, at least, until ...

More to clearing up the "whacky" (distorted) HSL control. It's distorting on my external display. If I move it to my laptop's display and then back to the external display, the control appears normal.

@j3rry, Do you move the whole app back and forth, or just the HSL control window? In About This Mac | Displays, what is the information given for your EIZO monitor? I have been experiencing HSL crashes, and now with .141 distorted controls, since 1.7.0 and through all the betas. My external display is a BenQ SW271. For it, About This Mac | Displays sees a 61" (!) screen. However, I am still running macOS 10.13.6 High Sierra (on a MacBook Pro 15" 2018 model).

Andy, I was editing the message as you were replying. In the meantime I have found that restarting Affinity Photo seems to clear up the problem of the "whacky" HSL control ... until whatever provokes this behavior recurs. In the sense that I can still save my work and restart AFP, this is certainly preferable to losing work because of a crash.

Andy, I haven't had much time to play around with the HSL adjustment layer control. It sometimes displays normally, then it becomes "whacky," and once it does, I don't know how to get it back to normally. Saving my work, closing the file and reopening it seems to work, so I guess that is better than a crash. If I knew a way to get the control back to normal, I guess I could live with this. As it is though ... The monitor is a BenQ SW271. About This Mac | Displays says "61-inch (3840 x 2160)", but it is really only 27" UHD.

There's something very wrong with the HSL control in this beta. Here's a screen shot: NB: I'm still running macOS 10.13.6

So you're telling me, Affinity Photo starts with a larger "photo" before applying the same lens correction as the other applications, so, even after correction as I described, it ends up with more pixels? Okaaay. I guess one can only hope that whatever is cropped off after correcting lens distortion consists mostly of edge pixels. Do you happen to know in what sense the edge data "is considered" unusable?

Not sure I follow. I am assuming that lens correction refers to barrel and pin cushion distortion. Correcting barrel distortion involves "pinching" the sides and the top and bottom inward towards the center of the picture while keeping the corners where they are. In order to maintain straight edges, the resulting "pointy corners" must be cropped off or empty space inserted between them. Similarly, correcting pin cushion distortion requires "spreading" the sides and the top and bottom outward from the center of the picture while keeping the corners where they are. In order to maintain straight edges, the "bulges" must be cropped off or new corners built up by inserting empty space. The edges of the Affinity Photo JPEG are as straight as those produced by the other applications, and I see no empty space.

I have just noticed that the dimensions of the NEF (Nikon RAW) photos developed in Affinity Photos (both 1.6, 1.7, and 1.7.1 beta) are different from the dimensions of the same photos developed in camera (OOC), DxO Photo Lab 2 and EyeQ (formerly Athentech) Perfectly Clear. In all cases (except OOC, of course) I am comparing the exported JPEG photos. I would expect the OOC JPEG to be correct, since it is presumably produced with lens data available from the manufacturer, and the results from DxO to be just as good, since DxO does -- or, at least, used to do -- its own testing. In fact, OOC, DxO Photo Lab 2 and EyeQ Perfectly Clear produced JPEGs with exactly the same dimensions (3712 x 5568 pixels), whereas Affinity Photo's are 3728 x 5600 pixels. The camera used is a Nikon D7500 with a Nikon AF-S DX Nikor 16-80mm f/2.8-4E ED VR. The D7500 is configured to produce RAW + NEF. I am using the Mac versions of the mentioned application. What is the explanation for the discrepancy?

Several more crashes with the same document, always when I try to insert an HSL adjustment layer. I will omit the logs unless instructed to send them.

Another HSL crash. This time, I was only working on the document that caused the crash (i.e., there were no tabbed windows open in AFP), and I had restarted AFP before opening the raw file and developing it. Here is the log: AFP 1.7.1.140 HSL crash #3.zip

Well, I thought the HSL crash had been fixed in 1.7.1.140 (see ), but it just bit me again -- twice. Here are the logs: AFP 1.7.1.140 HSL crash.zip . Curiously, it takes a rather long time for the system to catch the crash and/or generate the log. Could this be a by-product of the fix?

Oooops! Spoke too soon. Starting new thread for this bug here:

@Andy Somerfield, Yes, Beta 1.7.1.140 does indeed seem to fix the problems that I reported in this thread. Thanks!

Maybe DxO should make a "back of the envelope" calculation. As more people reject Adobe's pay-by-the-month scheme for competitors' buy-it-once scheme, it's exactly those people who will have the loose change to buy the Nik Collection.

@fde101, I'm definitely not in favor of that. @Andy Somerfield seems to imply that there is a fix for the issue, so, until then, as long as I have some idea what operations are likely to trigger it, I'd prefer to decide for myself when to risk using Metal and when not. I probably should upgrade to 10.14, but Apple seems to have a reputation with some purveyors of monitor calibration software for fixing some issues and creating some new ones that wreak havoc with their products, and so I have been reluctant to upgrade major versions of macOS until they've had time to deal with such surprises.

Another two crashes to report, at least one time while using the HSL adjustment layer, perhaps both times. Could the cause be the same as for previous two crashes? Here are the crash logs: AFP 1.7.1.138 HSL crash.zip

OK, Andy, thanks. Does that mean that it could reoccur until the next build? Presumably, the fix would be in the update that you're aiming to release on June 19, or am I "jumping the gun" here?

I would like to second @abarkalo's request for a quick roll-over of betas into production updates. (Just read @MEB's reply. I'll leave this here anyway. A bit of support can't harm.)