Medical Officer Bones

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

@LondonSquirrel I feel you are missing the overall trend of webp usage and popularity. I see a parallel trend with WebP compared to SVG. It took SVG a LONG while before it finally took off - but when it did... What I find most interesting is that it took SVG 4 years, more or less, to get where WebP arrived at in only 11 months time. The 600% increase in this short time is quite telling, in my opinion. While it is still early days, I expect WebP usage to at least triple in the next 12-16 months. We see that at this point that 8.2% of the top 10,000 sites use WebP for image delivery. Which makes sense: bandwidth costs money, and WebP saves bandwidth. But also because developers of the top segments tend to be more forward-thinking to remain competitive. Another reason why I forecast a dramatic increased uptake of WebP rather sooner than later. And very simply for smaller websites it means faster loading times and an improved user experience. These things, and the increased awareness. In my classes more and more webp is used by the students. Most design software can now export WebP, even if it requires a plugin (looking at you, Adobe!). The genie is out of the bottle. It is up to the Affinity devs to keep up with these developments and obvious trends. If not, they'll be left behind.

The main issue is that "industry standard" design and animation software still do not support the export of webp. It's a bit of a chicken and egg situation. Luckily the situation is changing: Krita 5 supports both APNG and animated WebP files, as does PhotoLine. Plugins exist for Photoshop to do the same. And WebP is gaining popularity. Simply stated: things are possible with WebP that are not possible with (A)PNG or other file formats or coded solutions that eat up much more bandwidth. This has an impact on the user experience from both the perspective of load times as well as eye-candy, and as such, it is steadfastly growing. As a large web-based business you'd be plain losing money on bandwidth if you keep ignoring webp. @LondonSquirrel You seem to ignore the fact that the uptake of webp grew by 600% in 2021 only, and that it is the most popular image file format now with high traffic sites. I interpret those figures as a NEED to support WebP export rather sooner than later. The context of that 3% tells a very different story in my opinion. And it is not only a useful format for the web: game engines support this format now as well. It is an effective and flexible image file format - the only one that supports a superset of all the other graphic file formats: both lossy and non-lossy, full alpha, animation, EXIF/ICC Profile/XMP support,... Nope, everything indicates that the use of webp will only grow and grow. It is very, very dumb on the part of the Serif devs to keep ignoring webp. I mean, they are behind: animated PNG and WebP support is growing, and Affinity can't even export a static WebP file.

? Photoshop never did and still does not support the APNG format (at least, not without a plugin). In any case, for those who wish to convert their animations to APNG or Animated WebP files, download the latest Krita 5 beta and FFmpeg. Krita 5 exports directly to APNG and animated WebP via FFmpeg. And it is free & open source.

Same in Windows: It's very inconsistent and, what's more, irrational behaviour in Photo. Photo does open a 1 million px wide PNG image that I saved from PhotoLine, but refuses to resave the same PNG file at its original dimensions. Why allow for the import of higher than 32768px wide PNG files, if the application blocks saving those same files it opens correctly? That makes little sense: on the one hand insisting that PNG files 'officially' only support up to 32768px wide and high bitmaps, but on the other hand still supporting the import of far higher resolution PNG files. That is very illogical ambiguous software behaviour. Besides, it seems only Affinity Photo enforces these arbitrary PNG export size limits: all other software that I use supports saving higher resolution PNG files. Krita also saves such PNG files without issues (including the 1 million px wide PNG file), for example. ClipStudio has no qualms exporting a 100.000px wide PNG file. Irfanview imports and exports much larger PNG files. Photoshop actually limits file format choices for saving a 250.000 pixel file to PSB, TIFF, and PNG - other file formats are excluded, meaning the PS developers chose PNG as one of the few file formats capable of saving such files! And as @fde101 reiterates: the max width or height is limited to (2^31)-1: 2,147,483,647 . I wonder if the developer implementing PNG export misread the PNG format specs. 😉

It no longer does. Adobe gave up on maintaining the 3D features in Photoshop. They are now officially deprecated. You are aware of alternatives, such as: 3DCoatTextura https://pilgway.com/product/3dcoattextura ArmorPaint https://armorpaint.org/ MaterialMaker https://www.materialmaker.org/ Quixel Mixer https://quixel.com/mixer And it is possible to paint with layers in Blender with this plugin: https://blendermarket.com/products/pbr-painter Many of these have a bridge to open the texture in an external image editor for round-trip editing.

Have you considered using proxies? Create lower resolution versions of your renders in Photo and link-place those and work on the layouts. Then when you are finished, relink (I assume you are linking instead of embedding!!!) and replace the low resolution proxies with the high resolution versions. Use the Resource Manager to accomplish this in Publisher. Then export to PDF (if Publisher still chokes, work in smaller sections, and use a tool like PDF Exchange Editor (or Acrobat) to collate all pages).

That is already possible: Blender imports SVG (both as curves for 3D extrusions, etc., and as a Grease Pencil object for 2D animation) and imports the common image file formats as a source for textures. Same for Maya and other 3d apps. Perhaps be a bit more specific what you are missing in this respect? It would be nice to have improved normal map support: for example a combine normal map mode similar to Krita.

In Photoshop and PhotoLine Filter Forge is non-destructive when applied to a smart object (Photoshop) or Placeholder layer (PhotoLine's smart object version). It works really well.

Perhaps Filter forge might fit the bill in the meantime? Full nodal filter construction.

Ah yes, I recall that discussion at the time. 🙂 Here is an updated article from the same site 4 years later: https://pvs-studio.com/en/blog/posts/cpp/0720/ It really was more of a discussion about using PVS to analyze a larger project's code quality (PVS is their product). It is used to identify " bad practices" in coding, and obviously the open sourcing of a once-commercial product provided a great opportunity to make some waves on the net for their PVS code quality checking. I believe they did a similar test with Blender's source code. Not sure. Overall it bears little weight as to the quality and functionality of OT, of course. Although it may create a more unstable running app. But really, OT runs well on my system now. Really no comparison with the first version (which was BAAAD!!!). I did some crazy timeline things today, and it hasn't crashed on me even once. It runs fine now (at least on Windows. I have no experience with the Mac side of things!) Not trying to convince anyone. I just thought there were some outdated/uninformed notions posted in this thread about OpenToonz. And yes, I do like to work with OpenToonz: it fits my workflow very well. But as you say: what works for one person may not work for another person. I think it is great we have so many options now, because I recall a time only expensive production-level 2d animation software was available. Now any animator can access high-grade animation software for free. As I wrote earlier, it works a bit different in OT compared to TVPaint: because the drawings are decoupled from the timeline, selecting frames and how these are selected becomes more important. To make it work, select a range of frames. Then the handle appears at the end. This is actually quite neat, because if a pattern of frames is selected, it will repeat that pattern - even across multiple layers!. To decrease the exposure, select a range, and then drag the handle to the left. Also, if you hold down CTRL a handle will appear at the start of a sequence, allowing for increasing and decreasing the duration of a sequence from the left (start). TVPaint does make it easier to drag sequences over other sequences & replace them. As I said, some timeline things work better in OT, other things better in TVP. I do very much miss nested timelines, though. Btw, after playing around with TVPaint I was pleasantly surprised by the nice fluid animation workflow. Definitely got some nice improvements since I last tested it. So at the very least your post here made me very curious about TVPaint once more. That depends! Blender's Long Term Support version is aimed at providing good support for studios. That was definitely a good move by the Blender Foundation and motivated more studios to adopt Blender in their pipelines. And OpenToonz's lead developer works for Japanese animation studios and is directly responsible for adding requested features and debugging OT when the animators run into issues. Vice versa (playing the devil's advocate here): Affinity users have been requesting a number of expected and basic features for a VERY long time now, and those are still not implemented. The reality of software development is a little more complicated than merely a matter of " free/open source" versus " commercial" business models.

Challenge accepted! I downloaded the trial version of TVPaint which is fully functional but for saving work, and I spent the afternoon hours in it. It's improved quite a bit since I last tested it 8~10 years ago, or so. So here are my discoveries, be they as they may rather shallow ones, and if I get anything wrong here, please correct me. Focusing on the timeline only: Things I liked the head and tail instance handles work well and fast. OpenToonz has similar options, but it takes an extra step for the head. timeline works well (minus my major gripe regarding nested timelines see below) layers in timeline offer regular layer blending (not possible in OpenToonz: the layer workflow is different, and requires the nodal compositor) thumbnail preview in the timeline is nice. And the layers are collapsible, which I love (and use in for example Resolve) I really like Image Marking in TVPaint. Great to indicate keys, extremes, inbetweens,... Would like this in OpenToonz, because I often want to differentiate between these. ToonBoom has a similar feature, but not as good. The Flip feature is also pretty cool. Very much like this, and haven't seen it implemented like that before. Timeline is easily controllable with the keyboard. Things I disliked: OpenToonz offers very efficient and convenient drawing substitution (ClipStudio works the same in this sense). Basically, drawings and the timeline are uncoupled, allowing for easy drawing recycling. For example, I have a character with various expressions. I create a layer with a bunch of expressions. Now I can easily reuse those drawings in the timeline. When I update one of the drawings, all instances update! This also works with sub-Xsheets/timelines, which allow for multi-layered embedded timelines. Very flexible system. I looked in TVPaint for something similar, but came up short. Are the drawings somehow separable from the timeline, or not? I hope so. Talking about sub-Xsheets: in OpenToonz it is efficient and simple to create nested timelines. Any animation timeline/x-sheet may be placed in another timeline as a nested timeline. In this sense they work like Graphic Symbols in Flash/Animate CC. I missed a similar feature in TVPaint. I checked the TVPaint forums, but this (rather essential option in my opinion) is not supported. That's a show-stopper for me personally: I can't imagine working without such a basic feature. A simple retiming on 1s, 2s, and 3s seems to be missing? I noticed there are scripts, so perhaps someone wrote a script for this? In OpenToonz the timeline allows block selection and dragging of frames across multiple layers. This doesn't seem to be possible in TVPaint. Onion skinning is much more convenient and flexible in OpenToonz: it is much better integrated in the timeline. Not sure about this one, but I missed a similar feature as Shift & Trace in TVPaint: it allows for keys/extremes/inbetweens to be temporarily moved/rotated to draw new inbetweens on the exact spot where they need to be. It's like grabbing one of the animation sheets, and moving it on a light table under your new drawing as a reference. This works directly in the timeline. Very handy. While I sorta like the project manager with clips in TVPaint, I prefer to work with the X-sheet/timeline and sub-Xsheets to generate a master. This also allows for all the timeline features such as onion skinning for example, which is not possible in the project manager with clips in TVPaint. It feels needlessly restricting in my view. It seems the lack of sub-timelines is complicating project management somewhat? Besides, it feels a bit like a cross between an X-sheet and a non-linear video editor, but falls short of either as far as I can tell after this brief exploration. Simple tweening (transformations) of drawings/content is terrible in TVPaint: it is all done in a separated fragmented workflow via the 'Keyframer effect'. In OpenToonz it is integrated in the timeline, with easy to identify timeline keys. Almost unusable for me in TVP. Who came up with that?! Same for the camera: in OpenToonz cameras are part of the timeline (which they should be in my opinion), and may be keyed/transformed/tweened. In TVPaint however the camera is part of the effect stack?! Just plain silly! Why over-complicate camera work? In short, the lack of sub-timelines is one of the dealbreakers for me. As are the way cameras are (not) handled in the timeline. But other things are missing as well, which I take for granted: obviously no vector drawing support. That's a big one! Toonboom, Flash/Animate, CelAction,... All support this. OpenToonz and Toonboom both allow for conversion from bitmap to vector as well. It does limit the usage scope of TVPaint in my opinion. Frame-by-frame animation with vector support is brilliant for that clean look, and can be scaled without issues for different resolutions. It is a major reason why ToonBoom is used for a lot of work and why Flash was used in the past. - the way effects are handled in TVPaint via the FX stack is rather (sorry) horrible. In OpenToonz a nodal editor is used. Same in ToonBoom. - In OpenToonz a special raster/bitmap layer exists that keeps track of palettized colours. Which means both vectors AND bitmap brush colours are editable at all times. - aside from great frame-by-frame animation options, OpenToonz also provides quite nice automatic tweening. Even vector drawings can be tweened for quite automatic inbetweens instead of having to draw them from scratch. In short: I quite liked the frame-by-frame bitmap animation tools in TVPaint, and it offers some interesting features. But it also lacks a number of rather essential features which come free with OpenToonz and are part of other commercial software as well. And TVPaint implements a number of features in a very awkward manner (effects stack, tweening,camera,...). The project setup was interesting, but I do prefer the way animation projects are set up in OpenToonz. As for storyboarding, WonderUnit Storyboarder is excellent, albeit not directly integrated in the animation software like TVPaint. But free and very capable. Please share with us the link to that article, please. What is "crooked code" exactly? I worked all day with both OpenToonz and TVPaint, doing the same things, and neither crashed. Yes, OpenToonz in the early days was horrifically unstable, and crashed time after time. Nowadays this is no longer the case. What does that exactly mean? Blender is incredibly successful, and is now used all over the world for work by artists and studios of all levels. Krita is stable and arguably one of the best digital drawing apps out there. Wonderunit Storyboarder is excellent and stable. OpenToonz is used and stable enough for large-scale feature productions. Now you are shifting the goal posts... Japanese examples do not count? Have you seen TVPaint's website recently? It is also used by Japanese animators and studios - the site uses this to advertize their product! So those Japanese productions do not count either? If anything, Japanese traditional frame-by-frame animation is mightily impressive. It serves as an example. (Yes, there is factory-work stuff as well, just like in the West!) Anyway, all animation apps have their ups and downs. I think that the "perfect" animation software cannot exist, because it depends too much on the workflow of the individual animator and animation studio requirements. Would I use TVPaint in my own work? No. It is too focused on bitmap frame-by-frame only, and it is really quirky in some areas - too non-standard and quirky for me. But if I was asked to use it within a team, I would have no qualms about it.