Brad Brighton

@thormiller The '/' at the beginning of the filename in the error dialog is suspicious. Do you happen to know how it got there? Are you typing that in somewhere? Alternately, how are you selecting where to save the file? Perhaps post a screenshot of the file chooser (the window that pops up when you do a Save As... or Export (after you've set the export configuration))? Make sure you click the disclosure button (highlighted in the first attached screenshot) so we can see where Publisher is actually trying to save the result.

@Old Bruce Turns out, Preview isn't going to open it (I get the same error locally). I don't need a workaround -- I can open the file with APh and I can adapt as needed now that I know that the embedded profile is the source of my original issue (Grey/16 rather than RGB) for this specific case. The request is to make the software response to the unsupported characteristics clearer and, in the cases that are realistically deterministic/determinable, easier to resolve for those who may not realize what the real error is. It's likely that there are several conditions involved in the check (but not all of the conditions, I'm sure) that pops up that dialog for which there is a single, known approach to "fixing" -- taking the user there automatically, IMO, is good form. This specific file is an example of one generated off a Nikon Coolscan 5000ED (original Nikon scanner software, not VueScan) and the embedded profile would have come from there.

I've attached a file and the nondescript error message that caused me to lose some time when attempting to Tone Map an import (because I was experimenting with the local contrast values). I figured the situation out fairly quickly but still, error messages are (in the best cases) not just a description of the bare fact of what went wrong but are a guide to remedy when the solution is reasonably knowable. in this case, the system clearly understands that it's not an RGB file, and while the pertinent color profile information is staring at the user, it's not the sort of thing one would think to look at and indeed, takes a bit of savvy to grok the what/where needed to fix this. The request is (at a minimum) to highlight in more specific detail that the embedded profile doesn't allow Tone Mapping (after all, this is exactly the same generic error message that pops up when the wrong layer is selected and tone mapping is attempted which doesn't give the user much help in resolving). I think offering a list of appropriate conversions right on the dialog would be more appropriate (with a button for advanced/custom corrections that leads into the complete "convert format/profile" path if the user is sophisticated/desires a different conversion). EDIT: This specific request dovetails with a more general request that I periodically think about writing up -- pretty much everywhere an alert like this shows up ("wrong layer selected") could use either a list of target layers or, in the case where there is only one target layer, "do you want to do this on layer 'blah'?" There are so many wasted clicks on uncomplicated documents because there's really only one valid target but I (the user) has to do the work when the app could have unambiguously done so itself. trees_1.tif

I certainly don't think I turned this on specifically on mine but in case it's been turned off on yours, take a look at your keyboard shortcuts to make sure Application Windows is enabled and for what key sequence in System Preferences > Keyboard

I'll bow out and leave it for others to respond in detail then, both because I'm a Mac guy (the Acquire Image functionality, as named, is specific to the Mac) and because your use case is not something I do very often.

Probably depends on your particulars. On the Mac, 'Acquire Image...' under the file menu will invoke the native Image Capture interface.

@Dazmondo77 It's not literally the same but have you tried (default combo) CTRL-downArrow as a workaround? EDIT: It's a bit of a combo of open documents and document history as it turns out.

Ok. Check your messages here please.

Ok, what about the "~/Library/Caches" part? Have you tried that yet?

Don't rely on Spotlight -- Apple actively blocks "normal" users from seeing the pieces we're talking about. Specifically go into the folder I mentioned and see what is there (or not there) -- unless you did that too, in which case I apologize -- it's not clear from your response. In what general area of the world do you live (timezone specifically)? I might be able to help you interactively at some point in the next few days. It's starting to sound like you're going to need some hands-on tech assistance to clear this up.

The receipts file can get updated from time to time so those may be good -- you're probably a "known" user to the system. As far as parsing the danger/difficulty of the technical discussion in the StackExchange thread, I can tell you that as long as you're dealing with cache directories, you're not going to break anything. The worst that will happen is something may be a little slower for a bit while the specific caches are rebuilt (that's what caches are for, to modify themselves over time based on usage -- clearing/deleting them means they restart from scratch). Do the CMD-SHIFT-G trick in a Finder window and type in (no quotes): "~/Library/Caches". Look for these directories below and delete them if they exist. Restarting the machine after that is the most convenient way to get the store update system to restart cleanly. ~/Library/Caches/storeaccount ~/Library/Caches/storeassets ~/Library/Caches/storedownload ~/Library/Caches/storeinappd I would certainly nudge you to get this resolved even if you decide to do it over time since the Serif apps may not be the only ones you're missing out on updates for. I highly doubt this situation is solely limited to Affinity Photo.

@Shoogles /private/var/db/receipts/ is a directly that you normally don't need to be poking around in and, in fact, Apple defaults to not showing it to you. To browse this, open a Finder window, do CMD-SHIFT-G and you should get a "Go to the folder:" sheet. Type/paste that path into the box and click "Go". You should be able to discern from the filenames which one(s) belong to Serif. (I don't have the App Store versions or I'd give you a heads-up on what the name actually is.) Also, take a look here as it's diving deeper into the guts of the App Store app state, caches, etc.: https://apple.stackexchange.com/questions/245406/how-to-fix-reset-app-store-app-on-mac-osx-el-capitan

So here's my question on this one -- without the exif data (specifically lens info) on the older files (I have a decent archive of them) lens correction and panoramic stitching will be degraded, right? This won't impact me daily but knowing what's up may save me some time as I do go back to the older images periodically. Thanks!

10.7 or later according to the App Store compatibility so it must be something with the information your App Store app is looking at for receipts and the like. Is it possible that you manually copied this from an older machine or otherwise lost the receipt data for it commonly found at /private/var/db/receipts/ ?

There are a plethora of suggestions here: https://appletoolbox.com/app-store-not-working-after-macos-mojave-update-here-are-some-tips/ but I cannot recommend any of them from experience. Be cautious when implementing any of these.

@Shoogles Make sure the purchase shows up in the Apple ID account purchase history -- https://support.apple.com/en-euro/HT204088#iTunes. If "yes", that tells you there's something at issue with Apple presenting you the update. If "no", that means you purchased it under a different account (the "open" test you mention doesn't actually guarantee that it was purchased from the logged in Apple ID) and you'll need to track down what Apple ID was originally used.

Sadly, there's no date on the posting (linked) so "soon" means nothing in relation to the release of reviewed profiles. It might be worth contacting ICC to find out the state of using color profiles (in combo with the SoftProof aspect of the Affinity tools) to get the desired result: http://www.color.org/resources/cvd.xalter

Representative (older) Canon RAW file (CRW) attached. This does not appear to happen with CR2 files. Open this attached file in APh macOS 1.6.11, develop (no changes), see EXIF data available in the studio inspector Do this same operation in 1.7.1 or 1.7.2 beta and the EXIF data is missing The RAW engine is set to Apple in each of these cases. 138_3824.CRW

If you've purchased through the App Store, you just reinstall (or copy over via Migration Assistant). If you purchased through the Affinity Store, go back to https://store.serif.com, log into your account, "Downloads and Product Keys". From the licensing, you can run it on both so there's no "transfer between them" as such. (from https://store.serif.com/en-us/help/)

As others have pointed out, details that are not yet available matter in terms of "in your specific case" but in the general case, I think you can assume macOS might get a little more performance love earlier than Windows. Case in point: Serif and their cooperation with Apple regarding Metal acceleration (and regardless of Apple's participation, the more complex environment for GPU compute support on the Windows side).

Hi again, @MEB, It seems my snark (yes, I admit it) may have overridden my primary point which was actually to deprioritize (but not to zero) the situation. As in, I hope this report doesn't fall into a black hole and I never hear about it one way or another because I don't want to induce it again, however my immediate urgency was solved on a different path so if there is a bit longer of a wait for clarity that's ok. The confusion is completely my fault and I'm sorry for that.

Hi @MEB! I'm guessing that I won't be getting a useful response on this any time soon if it takes two weeks just to find out if this is a "wtf?" sort of issue or not. Fortunately, I didn't wait -- I've recreated the project yet again and after triggering other issues (posted elsewhere), I've managed to complete the project and I'm no longer "blocked" by this particular crash. The condition of this specific file is of keen interest to me still since it's not clear how it got into the state it did and therefore, there's no way for me to knowingly avoid it in the future however.

Looks like I was late to the game reporting this... just now managed to discover the previous post. For an Apple Design Award winning developer, there are some noticeably glaring omissions in expected platform behaviors.

And dangerously drinkable! :-D