Fossil

Affinity needs to act here. Exactly how, they need to decide, but they need to do something. Whether it's partner with Midjourney, or support Stable Diffusion on a local machine, or an API or SDK, or some service of their own, they need to act and give users a good experience and a functional AI workflow that is better than just 'using Affinity' to fix your AI images. Photoshop is already there. Firefly is already a thing. The plugin is already working. Affinity is playing catch-up. If they don't catch up fast, they'll be left with a tiny niche market.

Not only did I find this bug, I have a temporary workaround: if you swap to Swatches for the matte color picker, you can pick a transparent swatch and it will work. However, when you NEXT go to export, the matte will look like white again ... however it will still export as if you've set transparent - so I guess that is actually ANOTHER bug of a slightly different kind - it's showing a matte color instead of transparent, but still performing the transparent export. Also, there is a FURTHER bug for export of images with transparent content... and this bug exists in older versions such as 2.04 as well. If you export in PNG palette mode, some colors just vanish and are replaced with transparency, regardless of their alpha. I can see this problem on an image I have that has only 21 unique colors in it. I can understand that the alpha would be lost in palette images because the palette entries have no alpha but I cannot see any reason why opaque colors would simply vanish. I can understand colors that match the 'matte color' being turned into completely transparent. However, I had a white matte and black pixels were vanishing! e.g. Pure black pixels may just vanish altogether, even when the number of different colors in the image is very low. Palette export with a transparent color is, to put it bluntly, completely BROKEN for PNG 2.x on PC. Finally, even with no meta-data or ICC data, exported PNGs that are not in palette format are larger than they need to be, with sub-optimal compression of completely transparent areas.

This has been a topic since ... when? ... 2017 at least, maybe earlier. The OP hits the key word here still ... Affinity have known about DDS and the markets it could open for them for years. However, it seems the forum posts are a couple of hundred complaints short of what it would take them to act. That so much effort went into something arguably far more niche (astronomical photo handling) is baffling. But at least we got .webp, right? Though, not with animation support as far as I can see - though export persona seems like it would be a useful way to support saving web animations - they could even support GIF properly - but that whole area of Affinity is lacking love and attention. I have exports for sprite games with multiple hundreds of images in them and there's a lot that could ease my workflow. A more pressing question is why DDS can't be solved with a third-party plugin? Adding good support for third-party exporters (or importers) would take the load off Affinity and make adding their own imports and exports easier too. It's an area where Affinity totally lacks parity with that other program.

I have an NVidia 3090 with latest drivers. When editing a document with a large number of layers - hidden, or otherwise - and attempting to edit a layer with a mask, either by editing the mask, or the pixel layer, the (regular) ERASE brush behave incredibly poorly. The more layers, the worse it seems to get. The brush preview flickers on and off like it's going crazy. When dragging, it doesn't work properly at all, as if flow were set to 0, but it's at 100. When single clicking, it works only erratically, if at all, and it often takes several clicks to erase anything. However, the pixel brush in "erase" mode (CTL click on Windows) works normally; it's only the proper erase brush that is failing. If I disable hardware acceleration, the problem seems to go away.

I think the problem here is that Affinity CR don't see a lot of posts on this topic, so they conclude that nobody really cares about it. As Marcurios implies, the people who need this feature are walking away from Affinity before making a purchase. They aren't posting on Affinity forums making feature requests because this feature is such a barrier to entry that they don't even consider Affinity as a potential solution. I've seen the same issue with Microsoft. Unless users are dog-piling onto a feature request, it will never get done, but the nature of this request is such that existing Affinity users aren't going to post about it. That's the problem if you only survey existing users - you end up chasing diminishing returns for people who were already mostly satisfied, not bringing in major new groups of users who had a major obstacle to adoption. I should imagine there are groups of web-developers who find Affinity's weak jpeg and png export features a blocker to adoption, and they aren't posting on forums either. I don't know how Affinity pick features for development, but I suspect that feature requests in the forums are heavily weighted, and thus we're seeing minor tweaks for users who are already well supported, not major new features that could grow the user base. I thought that once Publisher was released some of the long-standing feature gaps in Photo might get more attention, but I guess that was naive. In the game-development community, nobody is evangelizing Affinity, because they would look like an idiot proposing swapping to a tool that can't load any processed assets. It certainly can't be used to batch-convert a folder of texture assets to preview compression artifacts. While an individual can get by with an ancient copy of Photoshop, that's not a practical solution for a studio that needs to license artist-seats and be audit-ready. You end up buying that stuff, in bulk, on subscription because Adobe made anything else practically unworkable.

DDS support, or at least the ability to use the existing Photoshop plugins such as Intel Textureworks, or the nVidia plugin, are a must-have for game development. They really are not optional. I'm currently forced to use an awful mix of Photoshop, Paint.Net and Compressonator to do work that reasonably ought to be handled by Affinity import/export. What's so surprising is that after several years, there still isn't even a firm promise to add this feature, let alone a proposed date to deliver it. This functionality is useful to just about every game-development house on the planet. It's a huge market of people who would gladly ditch Photoshop if they could - but this missing feature continues to lock people into Adobe. Muddled posts from non-developers who think that BC7 is not relevant to Mac users do not understand that these formats are supported by AMD and nVidia hardware. They are largely old, well established, not subject to unnecessary change, and are relevant on all platforms that have modern rendering hardware, including phones. Most of the formats were introduced in the early nineties, and are still in use today in hardware on practically every modern smartphone, every Mac, and every PC. I still don't understand why Affinity marketing think this is a niche feature that can be ignored indefinitely. I've looked past this for years, naively convincing myself that it would soon be added, but I'm coming to the realization that there is no intention to add this feature at all and that Affinity marketing and development don't seem to grasp what it is, or why it matters to a large market segment who would otherwise be eager to embrace Affinity products. Finally, I've reached a point where working with BC7 is becoming unworkably awkward with Affinity Photo in my toolchain and I had to make a forum account just to raise this one issue. I've never had any other complaint about Affinity. What does this say? What is the long-term value of Affinity to me if I'm still obliged to pay Adobe, year after year? Even if Affinity is cheap, it's still cheaper to only pay for only one product. Sure, my existing purchases aren't going away, but if I'm not opening up Affinity, and I'm constantly opening Photoshop, when the next tranche of pay-to-update releases from Affinity come around where is my incentive? It seems more and more with every new release that Affinity Photo is fixated on competing against Lightroom, a product I don't use and know little about. It's a disappointment for me, that after eagerly adopting it some time ago, that I'm just not in a market where Affinity is headed. The effort invested in learning Affinity Photo is, apparently, wasted. I really have two major expectations from an image editor: making textures seamlessly loopable, and being able to quickly edit compressed textures during iterative development. Yes, the majority of my textures go through an automated pipeline that uses lossless sources and compresses them during the asset building process, there's still a huge need to get in there and mess with textures on the fly, to make an effect look just right, or tweak an alpha channel. Photoshop has both of these tasks nailed in a way that Affinity does not, albeit with third-party plugins, but it is at least possible to make seamless textures in Affinity Photo, and the process is ok; it just lacks the first-class treatment that liquify and develop have received. In contrast, there's nothing I can do about compressed textures with Affinity Photo. I can't load them and I can't save them. Affinity Photo doesn't even have a seat at the table. Of course I want my editor to do other things, but all the alternatives handle the basics to a satisfactory level. On reflection, I'm amazed that Paint.Net, a free product, has up-to-date functionality for loading and saving compressed textures, yet Affinity Photo - which has been a leader in other areas - assumes you'll manually convert to and from these formats using something else just to get them in and out of the wonderful Affinity world. If Affinity only has features that are nice, but lacks feature that are essential, it's going to lose in a toss-up against Photoshop, which has all the essential features, even if the interface is composed almost entirely of special cases.