Medical Officer Bones

I agree, this is quite useful to have for compositing, VFX, and concept art. PS Luminar 4 and Aurora HDR with many presets are now on sale in a Humble Bundle deal. https://www.humblebundle.com/software/aipowered-photo-editor-with-luminar-4-software

For those interested, PhotoLine added FITS file support in the beta last June. A nice HDR non-destructive adjustment layer with automatic exposure is automatically added for convenience. Could be an alternative until Serif decides to support FITS files in Affinty.

Or fire up a 3d app, and create your 3d metal object. I find that is more effective, and leads to better looking results. Much more freedom too. It took me a few minutes to create these.

SWF is a legacy format. SVG is a good replacement format for vector art import into a game engine. It's on the developers' heads of game engines to support it. GameMaker Studio still insists on the decrepit SWF format to import vector art, which is just plain dumb. Besides, it has all sorts of technical limitations. For example, Unity and Godot will import SVG directly. HTML-based game engines may support it as well, or you use plain vanilla JS with a SVG library to take care of it. But to expect support for SWF export at this point in time? Time to change your workflow.

I have a feeling that Affinity Photo's architecture perhaps complicates the implementation of a true 1bit (and 8bit indexed) mode to such an extent that the devs would have to re-code large swaths of their core code. I don't think they ever anticipated the need for a 1bit mode architecture, and patching the current code base is probably a really bad idea. And to be fair, it does present a new set of novel problems: how do you deal with transparency? Layers? How will those layers with different bit depths interact? For example, in Photoshop most of the functionality is simply turned off. No layers, no blending, most filters are greyed out and unavailable. Same in indexed mode. PhotoLine is completely unique in that it allows the user to actually keep using layers, vector layers, blend modes, layer masks and effects, but many effects and blend modes have no effect in 1bit mode, and layer masks still allow for grey values, which potentially can lead to issues. So in PhotoLine's case the responsibility lies entirely with the user to avoid making mistakes. Photoshop and PhotoLine represent in my mind two extremes in how to tackle the implementation of a 1bit mode: either limit the user's freedom when working in 1bit mode, or allow full freedom, but with that freedom comes the user's responsibility to avoid using features that might break the 1bit workflow. For an experienced user or expert PhotoLine is a revelation when working with 1bit graphics. For a novice a potential minefield, and Photoshop's hand-holding probably a better approach. And if an 8bit indexed bitmap mode is required in your workflow: even PhotoLine avoids opening that tin can of worms. I would argue it is preferable to switch to a dedicated 8bit (pixel art) image editor, such as Pro Motion NG, because of an entire new set of requirements. All of which returns us to the need of 1bit support in Affinity products. For many print/textile professionals it is an absolute requirement. If the Affinity devs could integrate 1bit in the export persona, fix the custom 8bit palette option (which has never worked), for heaven's sake implement a proper real-time preview in the export persona, as well as make sure Publisher (and Photo and Designer) deal with 1bit images properly in the PDF export and keep the original higher resolution, then Serif may perhaps at the very least provide a feasible 1bit workflow.

Various options which support all of your needs already exist on the market: OpenToonz, Toonboom Harmony, Flash/Animate CC, ... OpenToonz is open source and free, btw. It will also convert black and white drawings to vector.

Since it is related, for anyone looking for an affordable deal on a good video/sound editor: Humble Bundle is having a new video maker deal. https://www.humblebundle.com/software/your-sounds-your-movies-professional-video-and-audio-creation-software Video Pro X11, Vegas Movie Studio 16 Platinum, Sound Forge 13, and a few music maker apps for $33. And deals like these show that the video editing software market is overly saturated at this point. It would be, in my opinion, unwise for Serif to invest too heavily in a new video editor, unless it does something completely innovative.

A more controllable and simpler method: This is combined with a document-wide anti-aliasing control for flexibility, which means it is simple to control this property easily for document-wide and object-specific anti-aliasing.

A fellow C64 user! Yes, I recall GEOS: I was a GUI nut even before the term "GUI designer" was ever coined. GEOS was sloooooowwww, though, I agree. After the C64/C128 I switched to an Amstrad CPC 664, followed up by an Amiga 1000 (courtesy of the parents), and from there more Amigas. Then unfortunately the Amiga era ended (I held on to my Amiga till the latter half of the nineties!) before getting my first Windows 95 box. Good times.

That's interesting. It looks as if the image I created still has too much colours in each tile. Will check out that Multipaint tool! My graphics career started with a C64, Koala Paint and Pad in the 80s. Check out this video! 🙂

Here is a TRUE Commodore 64 version: one that would be displayed exactly like this, including the infamous 3 colours + 1 background colour per 4 by 8 tile! The zoomed version: ...and the 320x200 version at double pixel res: To generate an image like this needs specialized software that keeps track of the physical resolution limitations of these older 8-bit machines. In this case I used Affinity Photo to resize the image to 640x400 (double 320x200), open in Krita, use the Palletize filter with a C64 Lospec PAL file and Pixelate at 4:2 (this is the reason I needed to feed it a 640x400 image: the pixelate filter cannot go below 2). This then generates a version which can be downsampled in Affinity with nearest neighbour to 160x200.pixels. All double pixels are maintained this way in the next step! To ensure the hardware limitations (no more than 3+1 colours per 4 by 8 pixel tile) of the original c64 are maintained, I created a C64 Multi Color image in Pro Motion NG. Pro Motion NG is "aware" of the colour screen mode constraints of the older 8bit machines. Pro Motion NG automatically fixes any tile that contains more than the aforementioned hardware limit. I pasted the 160x200 image in PM, and saved the final result. This version could be displayed on a real Commodore 64! Anyway, in this little project I used three different apps to create the final result. I'd suggest to be pragmatic about software: use the right tool for the right job, and have a range of tools in your tool bag. I use Affinity for certain things, PhotoLine for other things, Krita, even an older version of PS CS6 and GIMP for various jobs, when they call for it.

Lospec has a list of pixel art palettes which include various 8bit machines https://lospec.com/palette-list/tag/computer

I would say to just stick with Gimp. Or Krita, which allows for a non-destructive pixelate filter that offers separate controls for x and y resolution, as well as the brilliant new Palettize filter. Use the right tool for the job, and in this case Affinity Photo just makes the process painful. There is no Palettize filter in Photo. There is no direct method to pixelate with 2:1 pixels in Photo. Photo should have at least an option to use a custom palette in the export persona, but it's been broken for more than 3 years now since it was first reported! Just stick with Krita or Gimp for this job (or just about any other image editor out there: most do have similar options), and import the result in Affinity if required. I have a feeling the development team has many other things at the top of their to-do list to fix or improve first. I mean, the custom palette export option is SO BASIC a feature, yet after more than 3 years it is still not fixed. A bit of a sad state of affairs, but it is what it is.

As far as I am aware, Truetype fonts are defined using quadratic bezier curves, while Type 1 fonts are created using cubic bezier curves. The latter has more control points, and the former less. Converting a Type 1 font to a Truetype is a lossy process, and information is lost, and such a conversion should be avoided. Anyway, in my experience PDF readers render T1 fonts generally better than TT fonts. OTF fonts can contain either format (as MikeW pointed out), so an OTF is no guarantee for a high quality font. And TT fonts may include hinting, which is again lost in a direct TT-->TT conversion, which leads to issues as well. Many free fonts online are poor conversions from their original source files. I checked the original document in PDF Exchange viewer, and the result is as expected: the TT version looks pretty bad in comparison to the T1 Quark document.

There are many different user types. Which user type exactly should Photo adapt to? Your user type? Mine? A beginner? An expert in image editing? A photographer? A texture artist? A digital painter? An illustrator? The collage creator parent? The wiz kid programmer? It is literally impossible to satisfy or even define every type of user. The best we can achieve is generalized user types - abstractions of reality. It is therefore impossible to have any software adapt to every single user's background, personal preferences, personal workflow, software experience, GUI expectations, and so on. It is just plain impossible. Any user interface is a compromise. The more complex the software, the more the developers/UX designers have to compromise. Now, having said all of this... I do agree with you that a bitmap gradient tool ought to "remember" the previous settings, and allow the user to edit an existing bitmap gradient. Not many image editors allow for this, however (only one comes to mind: PhotoLine). Even Photoshop can't do it. Truth is that by far the most design applications only allow vector objects to have "non-destructive" gradients. Node-based editors fare much better, and generally do support such a workflow. So, unfortunately the "standard" consensus in layered image editors seems to be that bitmap gradients, once created, cannot be edited.