Richard Liu

Aren't there also only very few NIK plugins, even in version 2, that support 32-bit processing?

Thanks, @Chris B. I apologize for taking so long to reply. The print dialog appears very quickly when I open a new, blank document and immediately initiate the print. I hadn't expected otherwise. Furthermore, I expect many things in Affinity Photo execute more quickly on new blank documents than on ones that chock full of adjustment layers, live filters, masks containing many brush strokes, etc. So what do you recommend in the case that I wish to print real-life documents in Affinity Photo?

@Patrick Connor Printing from Affinity Photo 1.8.3 is working as intended, and there are indeed differences between printing from Affinity Photo and exporting to, say, tiff then printing the exported file from Preview, even though the same ICC profile with which I am working in AFP is also embedded in the .tiff file, and both prints are being produced on the same printer with the same ICC printer profile. However, as I report in https://forum.affinity.serif.com/index.php?/topic/116509-printing-in-183-excruciatingly-slow/&do=findComment&comment=632335, printing from AFP is extremely slow. I assume that hardly anyone is using Print, or there is something wrong with my setup.

I'm running Affinity Photo 1.8.3 on a 2018 MacBook Pro 15" Touch Bar with 32 GB of RAM under macOS 10.14.6 Mojave. Printing is excruciatingly s-l-o-w. For the print dialog even to appear took 1 min. 15 sec.! Savor that number. It means after clicking File | Print... I had to wait 1 min. 15 sec. just to see anything happen at all. Since the default printer is not the one I use for printing photos, the first thing I do in the Print dialog is change the printer. After selecting the printer in the dropdown list I had to wait 1 min. 20 sec. before the new printer's name replaced the old one's. After that I changed the ICC profile and the print quality, then clicked Print. It took 1 min. 15 sec. until the Printing message disappeared. Printing an exported .jpg or .tiff in Preview takes nowhere near as long. 2 min. 35 sec. just to change the default printer in the Print dialog!!!

Very generally speaking, the way to write software than runs on several OS's is to separate the device independent logic from the device dependent operations and, for the latter to create device-dependent services (subprograms) for each OS that are invoked from the device independent logic in a device-agnostic way. This is likely less the problem than testing changes to those services to ensure that everything that invokes them still runs properly. Many so-called regression tests can be automated -- indeed, good software is designed from the very beginning to be "testable" --, but those that cannot can be very time consuming to test, and are susceptible to tester inattention/fatigue. Remember, too, that many services invoked by the software's are supplied by the purveyor of the OS, and some of them tend to make changes to their OS even after the final release candidate of a new version has been sent to developers.

It seems that the Mac App Store is offering the 1.8.2 update. I assume that the usual blurbs describing the changes since the last update will appear here shortly.

Thanks, @Patrick Connor, I'll try it the first chance I get and let you know one way or the other.

In 1.7 live filters were ignored when printing or exporting to PDF. Has this been fixed in 1.8.1? If not, I do understand that, as a workaround the layers containing live filters could be flattened, but that's clumsy, and I would therefore really appreciate being able to print without have to perform any preparatory prestidigitation.

@R C-R, Yes, thanks for the link to https://tidbits.com/2019/06/14/the-ins-and-outs-of-non-destructive-editing-in-photos-for-mac-and-ios/ . Apple sure seems to have messed up the design of support for extensions in the OS X/macOS photos applications. I shudder to think about the support -- or rather the lack thereof -- of color profiles when editing using a sequence of extensions.

@MEB, OK, thanks. That's what I thought. I think you can see that this is not a good way of handling RAW files. Am I correct in assuming that, when Affinity Photo returns a developed RAW file to Apple Photos, it is identified as RAW and edited? That, of course, would be nonsense.

Although I import my photos to Apple Photos and develop RAW files with Affinity Photo, I have not done so directly, but export the RAW file and open it in Affinity Photo. Can somebody who is developing a RAW file with Affinity Photo directly in Apple Photo please tell me what happens to the original RAW file when I save the developed and possibly edited photo in Affinity Photo and return to Apple Photo? Is the RAW file still available, or do I have to somehow "undo" the work I did on it with Affinity Photo and revert back to the original RAW file? If the latter, then I submit that this is not correct behavior. Yes, it is exactly what happens with film, I can only develop a film once. On the other hand, in that regard digital development has a chance to improve on analog by offering the possibility to develop the same RAW file in various different ways,

@am7, I'm assuming you have a dual monitor setup and this is happening on the external, non-Apple monitor. Drag and drop the mangled HSL control to the other monitor. It should "self-heal" there. Then drag and drop it back. It's not a permanent solution. Unpredictably the control will once again be afflicted. It's better than restarting Affinity Photo, though.

@haakoo, Anticipating the day hopefully soon to come when printing actually does work -- presently, for all intents and purposes it is broken --, I export to JPEG or TIFF and print the exported file with Preview. Yes, in general, something will be lost in the conversion, but it is not clear to me that rasterizing then printing with the broken print is the equivalent of printing with print as it is supposed to work. If it were, wouldn't it be better to fix this problem by modifying print to first rasterize what needs to be rasterized, instead of placing the dual burdens of rasterizing and somehow also retaining the unrasterized layers on the user?

@Klas No, it was mostly, if not exclusively, messages. I had posted a bug report on the lighting live filter not printing, received no answer, and sent a message to @Chris B when I noticed he was online.

Yeah, this is a problem that has plagued all versions of Affinity Photo since 1.7.1. I reported on July 5, 2019 that the effect of the Lighting live filter was absent in the printout, although very evident on the display. @Chris B replied on July and further, Since then, with every release candidate that I test and every new release I have enquired about the status of this problem. Here are the responses that I have received: August 1: August 28: A follow-up question on November 9 after the release of 1.7.3 elicited no reply.

Is 2.31 by any chance this: https://nikcollection.dxo.com/what-s-new/ ? I don't know why DXO is so coy about revealing version numbers.

@Patrick Connor, When can we expect a 1.8 Beta for macOS?

Walt, Interesting. I'll have to try this. Do you know whether this works with live filters? I sometimes feel that I don't want to sharpen the background as much as the foreground.

Seriously, I hope none. I do not have Affinity Publisher, but I do rely heavily on Affinity Photo. I am dismayed at how long some features remain broken, while others seem trapped in a cycle of breaking, being fixed, then regressing. A long thread about compatibility with Apple Photos is an example of the former. And it is still not possible to print directly (i. e., without merging layers or exporting to another format ... except PDF) an .afphoto that uses live filters. In my experience as a software developer for a major Swiss bank and a large Swiss pharmaceutical company, it is sometimes necessary to put new software and new features on the back burner in order to fix the foundations of existing products. This would be a good time to do so.

Something for those who seem to think that making beta versions of macOS available absolves Apple of all guilt when a program stumbles over a change in a new release. Several purveyors of display calibration programs regularly wait for the new release before adapting their products. This they justify with their experience that Apple makes changes even after Gold Masters. It might therefore be a better strategy for Affinity to release beta versions of their products in response to Apple's macOS releases until incompatibilities can be resolved to users' general satisfaction. That would also leave users with a version to fall back upon.

I apologize. The panel appeared on the laptop's monitor, not on the external monitor where the rest of Affinity Photo is running.

Hi, I just HDR merged two .jpg and would now like to remove some artefacts by replacing them with things from the source images. I have activated Sources in Studio, but clicking on the Clone tool does not cause it to display the Sources panel. I'm using Affinity Photo 1.7.3 on macOS 10.14.6.

@MEB Well, the HSL control gets moved to the laptop's display every time it displays wrong on the BenQ. Actually, just hovering it over the laptop's display before dropping it back on the BenQ corrects the problem, at least, until it reappears. So sometimes I just leave it on the laptop. As long as one adjustment layer's control is being displayed on the laptop, Affinity Photo seems to replace it with the next one that it has to display. It doesn't do that with live filters' controls, however.

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