rvst

Sure, the application UI itself operates in the same way when you're using the app regardless of installation method. It doesn't launch or integrate with the OS and other applications in the same way at all, however. This is the cause of all the complaints. You asked what the lock-in was and I answered: it's a lock-in to a restricted operating environment and usage metaphor that doesn't suit the majority of Windows desktop users.

Is there an easy way of converting the live luminosity mask into a static mask that can then be painted on to alter the mask? It can be done by choosing "selection from layer" and then creating a new mask and deleting the live one, although that requires several steps. It would be nice if the "Rasterize to mask.." option would perform the same task, converting the live mask into a static mask. Unless I'm missing something here in terms of how to optimally use luminosity masks, which is entirely possible.

As a Macintosh user Walt, I think you probably don't appreciate the extent to which the App architecture is a poor fit to a desktop environment. It's just Microsoft being bloody minded trying to fit a square peg into a round hole. MSIX installers are part of the App architecture. This is a tile-based interface designed principally for tablets - big ass tiles on a touch screen. It maps very poorly onto a multi-monitor desktop setup. Microsoft has attempted to force this metaphor onto users, but it has been roundly rejected by the market. I don't know any user who prefers it (in fact, everyone disables it) or any professional software firm that develops for it. Because of the sandboxing, launching the application is done differently. Because of the sandboxing, integrations are very difficult. It is designed to isolate software packages from each other, not facilitate integration. It gives the user no control of where the software is installed. That's fine for a tablet but not fine for a desktop with multiple drives in it. So the choice of a MSIX installer locks the user into a very restricted environment and usage metaphor ill-adapted to a desktop workflow. If we wanted to work on a tablet, we'd buy an iPad version of the software.

Calidad = the quality of the jpeg file you're exporting, expressed as a percentage value, ie. 0% - 100%. It doesn't mean DPI At 100% quality, no quantization occurs, which is usually responsible for most of the lossiness of a jpeg file, so the file is bigger and better quality. The second option your arrows point to is the option to include the bleed. From the Affinity Photo documentation When selected, the bleed area of your document, if set, will be included in the output. (Primarily used when working on Affinity Publisher or Affinity Designer documents in Affinity Photo.) There is no dpi setting in the export options.

It's unheard of in the software industry for software to have forward compatibility, ie., to be able to open a newer version file in an older version of the software (which is what we're talking about, not backward compatibility as many people are calling it. Backward compatibility would mean that Affinity V2 can open V1 files, which it can, so it's already backward compatible) The older software would need all the code for the new file format backported into a specific maintenance release to enable this functionality, and apart from the technical challenge of doing so, there is a disincentive for the developer to do this. What Affinity SHOULD do, however, is issue a warning when saving a V1 file using V2 software - "WARNING: once saved with the V2 file format, you won't be able to open it in V1". That way, at least the user will know before executing an operation that cannot be reversed.

Fair point. Although I suspect that would be on shaky grounds legally in many jurisdictions. The acquirer would very likely have to remove the online activation or refund users

It appears to only require online activation. That is to say, once activated, it doesn't need internet connectivity to run. I registered mine, then blocked all traffic using my firewall and the application still functions as normal.

Yeah, process explorer is quite useful for this too. Good suggestion. The added benefit is that it shows total number of page faults as opposed to a page fault / second.

In just 4 days, this thread has managed to become the 3rd most replied to thread of all time. Impressive

Here's just the face, blown up with Gigapixel to 6x its original size. You might be able to work with this one and overlay it on your image

You got similar results as me: better face but the rest is worse, which is why I overlaid the face on the image produced by whatever software the OP used I've noticed Gigapixel is pretty good on faces but not so good on other things. I think their machine learning models have seen a lot of development on faces but the other models are less polished

Go to the colour panel on the right. Click the hamburger and choose Tint. Drag the slider to the level you desire.

Your AI tool did a credible job except for the face. I ran the low res photo you attached through Topaz's Gigapixel AI, optimizing for the face. It seems to have done a better job on the face than your tool, but a worse job on the rest. That said, your grandad does appear to have a lazy left eye and there is a reflection artefact which I assume comes from the camera lens. So I took the face from the Gigapixel output and overlaid it on your image. Happy to send you the .aphoto file if you want - just send me a DM

Mark, The majority of the benefits you cite appear to lie in reducing Serif's support burden as it pertains to the installation of the software, which I can appreciate as being an important business level metric you need to keep on top of - unnecessary support costs nail business profitability. The very few user benefits apparent in that document (clean uninstall, signed updates) are minor enough that they're well outweighed by the inconveniences users are experiencing. Said inconveniences are already visibly causing Serif a support burden that I suspect outweighs the support burden associated with Affinity V1 installs, if the length of this thread and the numerous other related threads are anything to go by.

This is not an easy thing to diagnose as many components, both software and hardware, could be the cause of the slowdown. Others have mentioned some. The launch times you quote are extreme and likely due to some software issue with your computer (rather than an AMD processor). You can use the Windows Performance Monitor to gather statistics about what's happening during application startup to help diagnose the cause. Output for mine is below, with data capture paused just as Photo finishes displaying the user interface. It would probably be interesting for you to compare to yours given that your startup is so slow by comparison. My Photo v2 starts up in 4 seconds. I have an AMD 5950x with 128GB of RAM and a Samsung 980 pro, so similar setup to yours except the processor is faster and the RAM way more. A couple of things to note in this output. The number of page faults per second is very high. During its startup, Affinity Photo generated several times the amount of page faults per second that Microsoft Word does during startup and a considerably larger number than Affinity 1. This is likely because Affinity Photo loads a lot of dynamic link libraries during program startup - 216 in all, including the Windows system DLLs it requires. With this number of page faults per second, if your disk is slow (or you don't have a big enough pagefile) you will assuredly experience slow launch times. Ditto if your RAM is constrained either by its physical size or used up by other applications. Note the working set size: if you don't have at least this much physical RAM free (~500MB) then a lot of swapping will occur. This will also increase startup times as disk accesses, even SSD accesses, are vastly slower than RAM accesses. And if you have an on-access virus scanner, then each disk access will be slowed down. The cumulative effect can become quite significant. Also check your pagefile size is appropriate (the output below shows Affinity Photo uses around 650MB of pagefile during startup) Other less likely potential causes you may want to investigate: Affinity products phone home during startup, at the very least checking for updates. If one of your configured DNS servers is not responding to a query, timing out and causing a fallback to the next configured server, this could add a lot of time onto your startup, as each dns query will take a second or two to timeout before it retries or falls back to the next configured server. Disk failure - block read errors. Get Crystal Disk Info and check the SMART status of your SSD (or Samsung Magician, although later versions of Magician don't work with a 980 Pro) Oh, and check the Windows Event Log. There might be some clues there in warning or error conditions that could point you in the right direction.

I have the same laptop. The reason it's not Windows 11 ready is because it does not have a Trusted Platform Module, which is required for Windows 11 to function. A TPM is either a physical addon card or an eTPM implemented in firmware by later generations of processors.

Forgive me. I misunderstood your reply. My apologies.

Huh? Perhaps to you it was "patently obvious". However, Windows Store apps operate in a conditional access control list environment. This obviously can't be "fixed" since it's intentional on Microsoft's part. I meant a fix to Affinity, not a "fix" to Windows.

Correct. It is a permission issue and it's intentional on Microsoft's part as they wish to sandbox the Windows Store apps in a walled garden. Windows Apps add conditional Access Control Lists to the folders and executables that check the process security context to make sure that the process invoking the app has the correct WIN://SYSAPPID set in the security context. If you attempt to invoke the application directly, this is not set and so execute permission is denied.

Don't do this. It is a very big hammer. I posted a script that allows access in a much more granular and light-touch way without changing file or folder ownership and Patrick Connor freaked out and deleted my post. So if he considers my script bad (which, respectfully, I'm unconvinced about since I tested it and don't have any of the same issues), then this one is undoubtedly 10x worse. Changing ownership on WindowsApp folders is necessary if you want to add permissions, but the owner should be changed back afterwards. You may run into generalized problems with Windows Store apps if you follow the instructions in this video.

Other users have fixed Windows App installation errors of 0x80073D02 by clearing the Window Store cache using wsreset. There are several guides on how to use it available in easy reach of a Google search.

Apologies, I expressed myself unclearly. Yes, this is how MSIX works. By "fix" I meant a non-MSIX installation

Thanks for the feedback I repeatedly uninstalled and reinstalled with no problem. It uninstalls cleanly every time. I just did it again with no problem. Obviously I can't test updates yet. I'd be happy to test one, but none are available for download. My content was synced with no issue. We'll have to see whether it keeps the content up to date. I'll be keeping my installation this way until a fix is released. My 30 years of system programming experience tells me that these extra permissive permissions are unlikely to cause problems, since I took care not to change any file locations, ownership or even overwrite existing permissions, simply adding some new ones Here's hoping for a non-MSIX installation at some time in the future. Nobody uses this App model that Microsoft is trying to force onto users and I predict it's going to cause endless headaches if kept this way, especially for an app that needs to interact with other apps that are not sandboxed in the same environment.

Microsoft and it's "app crap" where it's trying to turn a desktop OS into a tablet OS even if we're still working on a desktop is about as misguided as Meta's metaverse thing.

I am the original poster. No, the script does not change the install location - it just adds more permissive permissions without changing the original file ownership or removing the original permissions. Yes, a future update would install new versions of files in the same location that have the original more restrictive permissions and therefore the more permissive permissions would need to be applied again. But that's a simple case of running the script again after an update. Personally, I find that a minor imposition compared to continuing to work with a sandboxed app. I see no technical reason why this should lead even to update problems. Hence why I requested a technical explanation from Patrick why he considers it a bad idea, because that's totally not apparent to me.