Medical Officer Bones

Screenshot from PhotoLine as comparison how to implement a good functional Select Sampled Color tool. With mask preview option to show marquee, coloured mask overlay just like Photoshop, and a really nice (optional) black-and-white mask preview. Perhaps in release 2? One can hope.

@Old Bruce Are you sure?

@RasterFarian I too agree with you and the others here. It is, plainly stated, a wrong and confusing use of DPI, and it should be changed to PPI. Although I am almost certain that the Affinity devs will never change this.

@RasterFarian Completely agree with you. When this conversation comes up, I bring up a simple question to explain that PPI and DPI are very different: Why do two images with different PPI attributes print at the same size on paper? One image is a multitone colour image at 300ppi. The other image a 1bit black and white image at 1200ppi. Both print at 5 by 5 inches. If PPI and DPI are treated as being identical, one cannot answer this question. DPI and LPI are part of that answer, as you also mention. Confusing the two is just a plain wrong and misguided use of the terminology. And no: that is not an opinion. That is how they are used in the print industry for decades.

Because the original had all those rounded corners applied with the corner tool, I just wanted to ensure Affinity is working with a pure curve and nothing else. The reasoning: when I zoomed in to edit the curve (on the right side) Designer still lagged terribly. Reversing the curve doesn't matter: the right side of the drawing responds very poorly when zoomed in on a section. The left side does not. The left side of the trunk also performs badly. I found the start and end points, and it doesn't matter. The odd thing is that when I zoom out to 100% or less, the lag disappears. The more I zoom in, the worse the lag becomes.

This file is... weird. I converted the tree curve with "convert to curves" and still got incredible lag. Then I decided to export to a SVG for testing in other apps and found no issues in InkScape, PhotoLine, Illustrator, or Blender. Just in case I re-imported the SVG version to ensure the curve would be an actual baked curve. At which point I discovered really odd behaviour: editing a few points on the left side of the tree, and it behaves smooth like butter. But the more I run along the curve clockwise, the worse the lag becomes! The zoom factor affects this as well. And it affects EVERTHING: even the screen updating. It takes an instant for the nodes to appear when panning the view - but only on the right-bottom side of the tree. Drawing a selection marquee slows down dramatically. On the far left, no issues at all. Here is a comparison between editing a few points on the LEFT side and on the right-bottom side: This counts like a bug in my book. My system: Windows 10, AMD 3900X, 64GB, 3080TI.

I kinda like Krita's start screen approach myself. I wouldn't mind if something similar (as an option) would be implemented. Photoshop offers a similar new start screen nowadays, which I actually find quite helpful to continue to work on projects. But it should be free from unwanted advertisements, of course.

Blender was mentioned here. Since text in a 3d app is "real" geometry, bevels behave like "real" bevels as well. And lighting and materials are of course completely controllable. The following example is a screenshot from the 3d viewport: it works in real-time. No waiting required for rendering to be finished. Although bevels in 3d can go horribly wrong too... Anyway, lettering with bevels is very simple to achieve in Blender.

Irfanview! The one piece of software that I have installed since Windows 95 times. Still use it every day, and it has excellent batch processing.

Krita is NOT a fork of GIMP. Quite the opposite, actually: back in 1998 Matthias Ettrich demonstrated how easy it was to hack a Qt GUI around an existing application, which happened to be GIMP. His patch was never published, and caused friction with the GIMP community at the time. So because the GIMP community was unable to work together towards a better image editor, people in the KDE project decided to start their own image editor, called KImage. That was the start of Krita. and initially named "KImageShop", meant to be a GUI shell around ImageMagick. The name was then changed to "Krayon" due to existing trademark issues related to "KImageShop", and finally renamed to Krita in 2002. All of which brings me to mention here that Krita 5.1 was just released. Krita is wonderful to work with for drawing and painting, in my opinion.

In the meantime the latest 5.1 release of Krita added extended Webp support with every option under the sun

Another option is PhotoLine that runs on Mac (M1 native too). Not as controllable as CQ, but an added benefit is that PhotoLine supports a non-destructive approach if required. Or Krita's Palettise filter, which again may be applied non-destructively: Krita offers a really nice option to control the dither pattern as well as dither range. Also works on Mac, of course. Both reduced to a 27 colour Amstrad colour palette Actually, most image editors feature a similar colour palette reduction option. I am starting to wonder why Affinity Photo still lacks one. Odd. After all, such a basic tool? Then again, so many other basic things are still missing, so I shouldn't be surprised. Perhaps in release 2 or 3?

If you are on Windows, the best "colour indexer" is Color Quantizer. Free and nothing else really compares. Also happens to be the best PNG optimizer with masking tools to control quality on a local level. http://x128.ho.ua/color-quantizer.html

@Pšenda That is why I wrote that the only way to figure this out is to test, test, test, and compare various versions with small groups of participants. Because conversations like these tend to run in circles. That's an interesting thought - I actually think I prefer the non-standard version. 😄 Never considered that before. It seems easier to check which page number belongs to which content inventory entry and the eyes do not have to wander across the page from left to right and back again. Because of the indentation of each entry the page number on the left simplifies tracking each item as well. In particular for the first 7 entries the left-aligned version is by FAR easier to understand which roman number belongs to which entry. Traditions in layout are not always right, it seems. 😉

Have you actually put them side by side to compare? The left version is simpler to visually navigate than the right one. And at least to my eyes and brain I have much less difficulty figuring out the visibility state of the layers. Also: Users are apt to use and work in documents with less groups rather than more. This is an important one to keep in mind. Your example is an outlier situation with that many nested layers - and you actually provide a reason against a right-aligned version in that the more nested layers there are, the more you need to widen the layer panel window and thereby increasing the distance between the parent layer(s) and the layer visibility checkbox. In short, extreme use cases like yours do not provide for convincing counter arguments against common use cases. Target the common ones, and provide contingency GUI solutions for extreme cases - not the other way around as your thinking goes. You fail to include layer effects and layer lock icons. These create more noise on the right, and as I mentioned before functionality is probably better separated with the left version. Having the checkboxes on the far right also creates more issues than solutions, which is beautifully demonstrated by your own screenshot of disappearing content forcing the user to either scroll or increase the width of the layer panel - which further increases the distance between the checkbox controls and the base content layers. I agree that horizontal scrolling should be possible - and in that case again it makes more sense to use the left aligned checkboxes: those would then stay locked in place, while the user is able to scroll the content to the left - reducing distance rather than increasing distance between parent layer(s)s thumbnails and checkbox. The left aligned version adheres to the Western left to right reading order. Going against that creates cognitive friction in a user (this is proven in usability and readability research). The checkbox on the left provides a visual anchor for the user to follow downward, which is not the case on the right. Or let's use another example. Would you prefer bullets on the left or on the right? Most users probably prefer having these on the left. Why would you go against common accepted proven practices? From the point of view of scannability and proximity, as well as common use cases, left aligned would work better in my opinion. But again: only proper testing with actual users and various use cases will yield insight which will work better. And thank you for pointing out all the other usability issues/inconsistencies with the layer panel. In my opinion the layer panel deserves a bit of rethinking.

A 1-bit image mode is not supported in Affinity Photo or Designer - or Publisher for that matter. The developers have stated that 1-bit support will never be implemented in Affinity: There have been quite a few threads created about the lack of 1bit mode support in Affinity. Iffy work-arounds abound such as the threshold filter suggestion above, or adjusting the layer blend. None of these are great, unfortunately. As always, if this is a requirement in your work, I would suggest PhotoLine, which not only supports a proper 1bit image mode like Photoshop, but goes beyond Photoshop in that it allows for layers while working on 1bit images. It is also possible to export your vector line art/inks from Designer to PhotoLine and convert these to high resolution 1200ppi 1bit images. PhotoLine also allows for proper 1bit high resolution PDF export and can be used to combine cmyk/rgb artwork with high resolution 1bit imagery for this particular task too.

@N.P.M. I forgot about this one as well (I prefer to hide and show things by key shortcut): Cinema4d puts these to the right as well (which are really awkward to work with, btw). Then again, when animation timelines are present the visibility controls are always invariably placed to the left of these - including Blender and C4d. Which makes sense, of course within that context. Perhaps I should have written image editing/digital painting/video editing/ 2d animation / audio editing software instead of design software? 🙂 Gimp, Photoshop, PhotoLine, Corel Paintshop Pro, Corel Photopaint, Photopea, Toonboom, OpenToonz, Krita, ClipStudio Pro, Animate CC, TVPaint, After Effects, ProMotion NG, Premiere, Davinci Resolve, most pixel art editors... Pixelmator on the other hand again on the far right. Which shares its origin on the Mac with Affinity (perhaps it is a Mac GUI guideline the developers followed? But Apple Motion places these to the left...) *edit* Nope, Paint.net does the exact same thing as Affinity Photo and that is Windows only! And you are correct: I also forgot about Inkscape and Xara.

A properly conducted usability test should provide useful insights here. From a functional perspective, speaking for myself and from observations of students while working in Photoshop, hiding and showing layers is an action performed many times more than locking a layer or opening the layer effects via that icon. I stand by my hypothesis that moving the visibility function to the far left will allow a user a more convenient and efficient workflow. At the very least Affinity is (as far as I am aware) the only design app that positions the layer visibility function to the far right, which does seem to go against most designers' conceptual model that they created based on prior experiences with design software. Notice that Capture One (example posted earlier in this thread) also sticks to this convention. In UX design it is considered bad practice to break accepted conventions unless that new approach affords a clear advantage over the older method. In this particular case I struggle to see such benefits, and it is rather obvious what the disadvantages are. From personal anecdotal experience, when I work in Affinity Photo I notice that I am slowed down by that right aligned checkbox. As for the exact reasons? Well, that is why a simple usability test would bring some clarification in this matter 🙂

The layer stack UX design is indeed problematic, and it has less to do with the choice of a checkbox as an indicator for layer visibility, and more with the positioning of the checkbox to the far right of each layer row. Placing the checkbox near the right causes a number of issues: users tend to focus on the thumbnail and/or layer name to identify the layer they would want to select or work with. Because the visibility checkbox is located to the far right, it is impossible to tell in one glance whether one or more layers are visible: first the user checks the thumbnail or layer name to identify the layer, then the user's eyes must follow the layer row to the right to check if that layer is visible or not. Our eyes can only focus on a very small area and see details. In this particular case it is biologically impossible to identify the contents of a layer via the thumbnail AND identify whether that layer is visible or not. This is not an issue in other design software, because the visibility icon/indicator is always placed directly left to the thumbnail. Vice versa, it is also problematic when the user needs to identify which layer contents belongs to a hidden layer. First the eye must identify the empty tiny checkbox, then follow the layer row to the left. This action is problematic not only because of the aforementioned issue, but also breaks a common rule that Western languages are written from left to right: to move from right to left with our eyes to identify information breaks that basic rule and causes cognitive friction. The above issue is exacerbated due to the tiny checkbox: the on/off state is not clear enough. It takes true cognitive effort to visually identify which layers are visible and which are hidden when a number are hidden and others are visible. Our brain is forced to jump right to left and left to right in the layer stack for each layer, and up and down, double-checking along the way - rather than a simple downward traveling eye movement, capturing both the content and the visibility state simultaneously. An additional issue is quickly identified when layers are locked and layer effects are assigned: those icons are also placed to the right of each layer stack row. There are multiple issues with this: for one, the meaning of the checkbox becomes ambiguous: is the layer FX active or inactive? Or the lock? More problematic however is the cognitive noise that occurs: our brain is forced to differentiate between these various icons near the right, increasing cognitive friction. One more issue is that the layer visibility checkbox is placed to the far right and the lock and fx icons to the left of that checkbox, creating an additional visual obstruction for the eye to travel to the left over the layer row to check which layer contents it belongs to. It all adds up to a rather high cognitive effort on the part of the user. From a function perspective the layer visibility and layer properties (lock, fx, blending, opacity, etc.) are distinct and separate. Placing both the layer visibility indicator in the same area as the layer properties only serves to create more cognitive friction and noise. The two should be kept separated. When layers are selected the checkbox colour is kept: a light gray. But the selection colour is a light background blue. In this context it becomes quite hard to visually differentiate between layers that are selected and identifying which are selected and which are not. Yet another hurdle to what should be a simple cognitive task. Placing the visibility indicator to the left introduces a visual cue that organizes the layers better when multiple embedded groups are present in the layer stack. It is well known that readers have trouble understanding a paragraph of text that is set to ragged right aligned (left to right languages): it vastly reduces readability. It could be argued that without that stabilizing visibility icon column the users' eyes are forced to follow the indented groups - further reducing visible understanding of the layer stack. placing the checkboxes to the far right does not seem to be consistent seeing that checkboxes in the Effects panel are placed to the left - which is more readable, of course. And which then brings to the fore: for what rational reason did the developers decide that placing these checkboxes to the far right would be a good idea? Because they obviously felt that it is more natural to place these to the left of the effects entries. when the user widens the layer panel horizontally, placing the tiny checkboxes to the right begins to make even less sense. Fitt's law anyone? Why make life so hard for your users? Which brings up the last point: should checkboxes have been used in the first place to indicate layer visibility? A checkbox basic meaning is "(not) active", rather than "(in)visible". An argument could be made against the use of a checkbox to indicate visibility, again from the standpoint of consistency: the aforementioned Effects panel seems to use checkboxes within the context of "an effect is either active or not". The meaning of a checkbox to indicate layer visibility seems somewhat ambiguous then. In particular seeing that in most design software with a layer stack an eye icon is used, it seems preferable to yield to common sense and accepted UI practices and accept the prevalent conceptual model, i.e. the eye icon. All of which means this: It is quite problematic to the user to figure out which layer is visible, and which is not. Even harder to understand which layer contents belongs to which visibility indicator. Our eyes are forced to jump all over the place. Time someone other than yourself and ask them to identify which layers are visible and which are not. Simply moving the checkboxes to the left and inverting the colour for selected layers resolves many of the above listed issues: Now perform the same test with a bunch of users. Time them again. I expect that the result will be thatit is FAR easier to complete this simple test with the second version. In my opinion the Affinity devs have never properly tested the user experience, and merely went by gut decisions, or whatever. There exist a number of additional usability and functionality issues with Affinity Photo's layer stack; customized blend options assigned to a layer are not indicated by a visual cue in the layer stack it is not possible to drag over the visibility indicators (check boxes) to hide or show the content of layer in one motion opacity value is not indicated only three settings for thumbnail size no option to alt-click visibility indicator to hide or show selected layer only (it is really different behaviour compared to the Solo mode) layer colour tagging: similar issues related to the fact that the visibility indicator is positioned to the far right. Colour tagging again is more useful and easier to identify when pushed closer to the actual content thumbnail. Moving the checkboxes to the left is "low hanging fruit". It simply improves usability and UX.

Untrue. It brings something to the table for web image usage that neither PNG nor JPG supports: a lossy image format with full transparency support. It was sorely needed.

I remember Carrara back in the 90s - even at that time it was a bit of an outlier. It had potential, but it just couldn't compete very well. It is extremely outdated for 3d software. Serif would have to rewrite the core of Carrara altogether to allow it to compete and that is never going to be lucrative: Blender's usability has jumped ahead by leagues in the latest versions, and is now quite easy to get into for a beginner. And obviously Blender is light years ahead of Carrara in terms of functionality. Carrara belongs in the archives of old defunct 3d software, unfortunately. I am amazed that Daz is still selling it for $285! But it seems they actually merely selling their 3d assets and Carrara happens to be part of that deal. It's not even compatible anymore with Mac Os. Serif would be sinking cash in a very VERY deep money pit. It would be preferable for Serif to acquire LightWave instead (but that's going to have a really tough time competing with Blender as well...).

Yes, absolutely agree with you in regards to the text tool in Krita. The devs should really up the ante there. I still prefer InDesign for that work myself: the typography is so controllable. Although I have been doing more lettering in PhotoLine the past few years - in particular because it also supports 1bit image layers combined with different resolutions and bit depth combined in the same layer stack. Also not a fan of lettering in ClipStudio, btw, because it is originally aimed at Japanese comic lettering, and a bit too clunky for my taste. PS didn't you like Krita's colorize mask tools? I have used those before to create the holds quickly, and export the layered result to Photoshop/PhotoLine. Saves myself hours of manual tinkering with selections.

@LDB Completely agree. I would actually argue that Photo is entirely unsuitable for use in a professional comic colouring and publishing workflow. The gradient tool is utterly unusable for colouring work, but there are other problems, such as the lack of an overfill option to speed up flats and holds. Since you seem to be in a discovery phase to replace Photoshop for your comic colouring work: have you had a look at Krita and/or ClipStudio? Both have a dedicated set of tools to simplify comic colouring work. Krita in particular offers a very efficient Colorize Mask workflow to create flats quickly and efficiently - with automatic gap close hinting and cleanup. And automatic colour swatch tracking of the colours used for flats! No more manual selections for everything: add a stroke to indicate the flat, and done. It may take Krita some time to calculate the flats, but still way faster compared to manually creating selections and filling those. https://docs.krita.org/en/reference_manual/tools/colorize_mask.html?highlight=colorize

Instead of focusing on that static 3%, consider the trend: 600% increase in only 11 months. And before that almost no usage of WebP. In any case - we will know in another 11 months