Medical Officer Bones

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.

In my experience no layer-based image editor is perfect. PhotoLine does support pretty much a full non-destructive workflow with 32bpc images, and, like Photoshop, fully implements a "smart objects" ("placeholder layers") workflow, up to the point of allowing external PS plugins to be applied as live filters, and using placeholder layers as masks for other placeholder layers, and live instancing of layers. Krita also supports instanced layers, and a non-destructive filter layer. The thing that really bothers me about Photoshop is its reliance on clipped layers to create stacks of combined masks. It just works better to allow multiple (grouped) layer masks. But the issue remains that layer-based editors do slow down at some point, and things become rather complex fast: a nodal approach is often easier and more effective to work with when things heat up in terms of complex compositing. I would love to see a nodal layer of some sort to be implemented. If memory serves me, I recall a mac-based image editor that (years ago) implemented a kind-of stackable puzzle approach on top of the traditional layer stack. I forget its name; it was quite intriguing, but development stopped at some point.

Speaking from experience: get the larger one. 6"x4" seems awfully small to me. I work on a large Wacom now, and before I used a smaller one. The larger tablet is far more comfortable to work on for me personally. That said, I am aware that some people prefer a smaller tablet. In this case the 12", however, is still fairly small in my opinion. Just get the larger one, because even IF you feel you want a smaller surface to work on, the drivers always allow you to reduce the active area.

Confirmed. When I use a 32px ink brush, and start drawing a continuous line (using Wacom tablet) at some point Designer starts lagging more and more, and does not keep up with my stroke. In my case the issue becomes problematic after around 12 seconds of continous line drawing, and for short strokes it does not appear to be an issue. My machine is very, very old: an Intel i7 920 and GTX1080. Why your modern rig is experiencing the issue faster? I have no idea. But it definitely is an issue, and probably a bug.

Meanwhile Krita was released a while ago for ChromeOS (both Intel and ARM): https://krita.org/en/item/second-beta-for-krita-4-3-0-released/ Or download via the app store.

The Anti-alias option in Photoshop (or in Gimp for that matter) is not the same as a dedicated overfill feature. The anti-alias option isn't actually a good solution, and often delivers not-so-great to unusable results. The application either needs to be 'aware' of anti-aliasing and overfill it by default (ClipStudio), and/or a dedicated overfill option is included. Anti-aliasing by itself generally doesn't solve all use cases satisfactorily.

It is unfortunately one more paper cut in Affinity. Two paper cuts in this use case, actually. The first issue with the fill tool is the lack of anti-aliasing/alpha awareness or the lack of an overfill option. In other software this is solved by either including the alpha of pixels by default, or including an option to control the overfill. In Krita it is called "Grow Selection". ClipStudio Paint does it automatically by overfilling transparent pixels (because who would want ugly aliased fills!). PhotoLine fixes this with an "Overfill" option. Art Studio has a "smart fill" option. Gimp, Photoshop, and Affinity Photo rely on the tolerance threshold to address this, but it is less than ideal, and often doesn't work as expected, or requires more fiddling around. Affinity's threshold seems the most finicky of all in my experience. The second issue with Affinity Photo's fill tool is the lack of a "read merged" or "all layers" option in the Source drop-down list. Here is why: suppose the artist wants to quickly fill areas of comic artwork. The default workflow is to put the line art in a layer above the fill layer, then fill areas. This can be done in several ways, and one quick method is to just use the fill tool. The artist then chooses "sample merged" or "(sample) All layers", sets the overfill (depending on the software) and fills the area. This workflow is unavailable in Affinity Photo, however: the Source list only includes "current layer & below", "current layer", and "layers beneath". It is literally impossible to fill comic art using this very basic approach in Affinity Photo. ClipStudio Paint offers the best controls and has options that range far beyond the "sample all layers", which is great. Krita has a nice "Color labelled layers" aside from the "All layers" option to precisely define which layers to sample from. PhotoLine, Gimp, Photoshop: these all have the "All Layers" option. Yet Affinity Photo lacks any such option, rendering the fill tool pretty much useless for such work (including bringing in technical drawings as line art, btw! Not only comic art jobs!). Instead, the fill layer must be placed ON TOP of the line art, which is very, very awkward. The Affinity devs should take note: add an overflow option, and allow the user to sample the layer(s) above the fill layer. Without these two very basic options the fill tool is pretty much useless for anything beyond simple tasks. At the very least add the "all layers" source option to have feature parity with Photoshop and Gimp.

Well, now that Apple announced that Safari will be supporting the webp format, I see no reason for the Affinity devs to hold off on supporting the export of it. https://www.macrumors.com/2020/06/22/webp-safari-14/

Agreed. I find myself in a similar situation with InDesign projects: I rent it for a month whenever I need it for a particular client who returns with a particular job every year. Otherwise I opt to work in alternative software, since mostly clients want PDF files, and have no need for the source files. If you have to collaborate with others using Photoshop and PSD files, there is really no other choice but to work in Photoshop (unless specific circumstances allow to do so such as agreeing with the team to limit/flatten the use of certain PS functionality).