Lemon Tree

No, I noticed it on 14.3.1 (Intel) with Publisher. And I was among the people who thought it was fixed for apps downloaded directly from the Serif Store rather than the Mac App Store, even though Serif themselves have said it is not. Unless you sit there with a stopwatch, it is hard to subjectively judge these things. Briefly, this is said to be macOS scanning the app for viruses. For what it’s worth, Apple’s own Xcode, which is the largest app I have on my system, is also very slow to start up now. Apple have tightened this up in recent major versions I think, so it now scans on every first launch after boot (at least).

I’ve worked out what it is about that particular TIFF which causes a problem. It has, as its embedded profile, a camera profile generated using Lumariver Profile Designer, for use with Capture One. This is probably a very strange profile indeed! I regenerated a similar TIFF from the same raw file, this time using the Prophoto RGB profile as is my usual practice, and the problem goes away. I verified again using the version with the camera profile that the problem still happens, so nothing on my system has caused it to go away. (Capture One calls Prophoto RGB “ROMM RGB”.) As the camera profile was used in error, and my practice is to use Prophoto RGB, this bug no longer affects me. The original TIFF with the camera profile was uploaded the next UK business day after being requested. I can supply the RGB ROMM version I used for the A–B test, but the engineers can probably extract the camera profile for their own A–B test using exiftool or a similar tool.

When editing the metadata of an existing 16 bit, zip-compressed, little-endian TIFF file, it takes roughly 5 to 10 seconds to echo each keystroke. This was observed for the keywords and description fields. It does not occur for a newly created file. The TIFF was produced using Capture One 22. Latest 2.0.3 version, macOS 13.1, Intel, plenty of memory. (Also occurred on 2.0.0.) Affinity Photo 1 can perform the same edits with no lag. I can supply a sample file if necessary, but don’t want to attach it here for unrestricted public download.

3. The "3 little bars" are called a "hamburger menu". The macOS equivalent is three dots, but is supposed to be used sparingly; Apple themselves have been criticised for overusing them in some of the bundled apps. I do agree that a hamburger/three dots menu is inappropriate here, because to what do the presets apply? Just the advanced options? I don't think so. 4. "Nested" just means dialogue boxes on top of dialogue boxes which have to be dismissed in reverse order. 6. I thought so too based on the screenshots and posted to that effect here a few days ago. But they behave differently. In Ventura's Settings, scrolling to the end of one section doesn't move the cursor in the categories column at the left. 7. We need to be realistic here. The video tutorials from Serif are outstanding, and partly because of them I am more expert now in Photo than I was in Photoshop. If having two different interfaces for Mac and Windows means half the quantity of those videos, I'd prefer that Serif carry on as they are. They haven't used any UI which isn't familiar to everyone from web apps, and unlike Adobe the controls are native macOS and so far the keyboard/mouse focus behaviour appears correct to me.

I understand why the Mac App Store version of Photo had an Authorise button in the New Batch Job dialogue. (It is to grant the sandboxed app permission to use that directory.) But I was not expecting to see it in the trial version of Photo V2 I downloaded from Serif. Why is it there? This does not appear to be a sandboxed app, since it wrote into "~/Library/Application Support" without requiring explicit permission from me. I once spent 20 minutes wondering why "OK" was greyed out with my V1 from the App Store, even though I had sat through Apple's video lecture on sandbox bookmarks and knew very well how they worked. It is just not expected behaviour, certainly not with the download version of the app. A search of these forums shows I was by far not the only person to get stuck like that; it must be an ongoing support cost to Serif which I would have thought you’d want to reduce by only having the Authorise button on the App Store version. And I have a related question: are batch jobs actually opening files as if it were sandboxed? I ask because I hit a limit with batch processing in V1. After 5,000 files, it started getting errors. This is because the macOS kernel imposes a hard limit on a process of 10,000 file opens via sandbox bookmarks, or at least it did when I hit the problem. It's a real shame because Photo compressed my 7,500 TIFFs like a champ, but I had to move the last 2,500 to a scratch directory and restart it. Losing this restriction was one of the things I was looking forward to in V2, which this time I will be buying direct from Serif rather than via the Mac App Store.

I have to disagree about the export dialogue. Of the two (and I did put them side-by-side to compare them) I prefer the V2 one for TIFF export. The advanced settings are available a mouse scroll away instead of being hidden behind a "More" button as in V1. When you did click "More" – which is Windowsy, it should have been "Advanced" on macOS – you got a nested pop-up, which is widely considered bad UI design. On recent versions of macOS that pop-up was tall and skinny, making it harder to read. The scrolling dialogue boxes aren’t very Mac-like, but they seem to be pervasive in V2 (e.g. in Preferences) and I can understand that a small company like Serif wants to prepare one set of training material for both Mac and Windows users.

Folks, App Store applications don't get to write into ~/Library/Application Support. For those, it's below ~/Library/Containers/com.seriflabs.affinityphoto etc (I have 9 folders from Serif there). Similarly for the preferences files.

The apps both live in /Applications. Stuff like macros and workspaces live in ~/Library/Application Support/com.serif.affinityphoto for a normal app. The App Store version also thinks it's looking there, but it's really under ~/Library/Containers. I should have said "batch and macros" instead of using the Adobe term "action". It's under "File > New Batch Job...". You can choose what macros to apply to each file in a folder. And right there at top right of that dialogue, in the App Store version, is an "Authorise" button that isn't present in the normal app, which is needed to tell macOS it's OK to trust this App Store app to write into that folder.

There could be a button to hide or show the preview, which was sticky so that it stayed the way it was last left. Then you'd see the preview all the time (and a Hide Preview button) and I'd never see it and have a Show Preview button in case I wanted it.

I think actually they're following Apple's recent look here. Ventura generally replaces tabs with scrolling panes, and this looks a lot like the Print dialogue in the current version of Pages. I do agree the preview is Adobe-esque and unwanted. But look at the options at the bottom right. The labels don't line up with the controls, and the checkboxes and radio buttons are IMO too close to the text. The two radio button options should be separated off from the rest by white/black space, and have a common heading ("Resolution"). For an example of how to do this properly, see Appearance under Ventura's Settings.

For version 1, the Mac App Store version is sandboxed, which restricts the way it can open files: I forget where, but there's a place in the interface where you have to grant access to a directory, and until you do stuff is greyed out. This had me stumped for quite a while on one occasion, because I "knew" it was necessary, but was not thinking about it at the time. This "grant access" button is not needed, and apparently not present, in the web store version. There is/was a kernel limitation in macOS which limits the number of files that a sandboxed app can open in a single run to aproximately 10,000. I hit this one when using Affinity Photo's actions feature to compress 7,000 TIFFs in a folder – it got to 5,000 and failed. I decided then if there were to be a version 2 I'd prefer the web download version for these reasons.

There is a spelling mistake in one of the dialogue boxes. Under the "Colour" tab in Preferences, you can choose the rendering intent. And it says "Relative Colourimettric" instead of the correct (even for British/Commonwealth English) "Relative Colorimetric". Even though you in the UK (and we in Australia) spell "colour" with a "u", it is one of those "ou" words which drops the "u" when it becomes an adjective. Both the Australian Concise Oxford dictionary and the UK Concise Oxford dictionary list "colorimeter" as the only permitted spelling. Another such word pair is honour/honorific. (The UK Concise Oxford is the one with the -ize endings. Sorry, I don't have a Collins or Chambers, but I think you will find the Australian Concise Oxford is close in most respects to standard UK spellings.) Version 1.8.6 Mac App store.