Medical Officer Bones

The posterize effect will not work properly with transparency in Photo. - create a 1200ppi greyscale document at A4 format (9921x14032 pixels) - paint with a black soft brush - add posterize adjustment Result: the soft edges remain. Not a solution, unfortunately.

Love WebP and PNG for game development. I use WebP mainly for lossy images which also require alpha transparency to vastly reduce the file size footprint. And in my opinion not supporting WebP is a bit silly. High traffic websites are converting more and more to the use of WebP instead of jpg, for the simple reason of reducing traffic bandwidth. WebP is out there, it is used, and it ought to be supported by an image editor.

Hi Andy, I am a bit shell-shocked after reading this, although I do appreciate the honesty. It does mean I can't use Photo for a very important part of my work. Simple as that. I also think it is somewhat short-sighted, since 1bit bitmaps are used in the printing industry for all sorts of jobs. I noticed the other day that Publisher now retains placed 1bit high resolution tiffs in the exported PDF, which is great. But when switching to Photo, any high resolution 1bit image is converted to a greyscale version. That just won't do, I am afraid. But at least Photo keeps the 1bit information intact when switching back to Publisher. Reading between the lines, I think the reason for the lack of 1bit (and 8bit indexed) support is that the core of the software would have to be adjusted, and that this would be far too fickle and too much work. Which I understand. Like I said, it means I just can't use Photo for my comics work without jumping through hoops. For anyone looking to edit 1bit files and looking to migrate away from Photoshop, have a look at PhotoLine, which supports 1bit bitmap editing with layer support (something even Photoshop doesn't support). The good news is that I discovered today that Publisher does now support 1bit high resolution images in its PDF export: I layered one of my 1200ppi 1bit files on top of a 300ppi colour file, and it retains these fine when I viewed the PDF output. So that is great. Now, I don't want to shut Photo's door entirely behind me for 1bit editing. Andy, perhaps you could implement a layer limitation which enforces the use of only 1 colour? Or perhaps a live layer effect that automatically converts to indexed/1bit? This idea is based on this Krita developer's work as seen here (see attachment for example): Which would solve the lack of an indexed mode as well. Allow your users to add a live layer effect to convert the layer automatically to 8/7/6/5/4/3/2/1 bit, with a control palette.

It is interesting to note here that someone posted about Publisher's release on the Adobe forums yesterday, and it was promptly removed by the moderators. Posts mentioning Affinity weren't removed up until the past six months, or so. It is quite telling: Adobe is certainly not liking the new competition, even if Publisher still has some way to go before it will catch up in certain respects. Anyway, I purchased Publisher this morning, and the Photo link is kinda genius. :-) It's come a long way since the first betas that I tested.

The reason why Adobe dropped Muse is quite simple: Muse's design view was decoupled from the actual html/css/js output. When the development team had to implement support for responsive page designs, it became quite clear how difficult such an approach is to maintain as developers while keeping up with the quickly evolving and changing web tech landscape. Simply stated, Muse became a bear of an application to maintain and develop. This is one of the main reasons why applications like WebPlus, Muse, and many others over the past decade have tried and utterly failed. Muse and its older brethren also tend to save to their custom proprietary file formats, rather than directly working with html, css, and js files (which is just plain silly, because those are open, human readable standards!). This made is pretty much impossible to work with a developer or in a team. A static Muse site's code is a horror, and utterly incompatible and unworkable for a developer to integrate with server-side code or convert to a CMS like WordPress theme (for example). And it isn't even possible to open existing sites in Muse (again because of that decoupling mentioned earlier)! Designers without an inkling about web coding couldn't care less about the code Muse, Xara, or WebPlus generates. They just want snazzy eye candy effects, and that was another reason why Muse tanked. Browsers are an ever-changing live target, and scripts/effects that may have worked two years ago, may cause issues in a newer browser. And let's not talk about the ridiculous size (file size) of some of those Muse sites. In short, Muse was (is) a disastrous approach for proper web development. Great for the odd static eye-catching website or portfolio/online business card and for quick prototyping. For anything else just a Very Bad Idea. And an elephant of an application to maintain for its developers. Always running after the facts. To my knowledge, the only surviving still developed purely visual off-line web page editors are Xara and Sparkle. And both rely on a proprietary file format. Which makes no sense to me: after all, the web is an open standard. Work with those standards, rather than against it. The only reason for a proprietary file format is to lock the customer into their own software ecosystem. Sparkle is a good example how NOT to create output code: they proudly proclaim their home page is created with its home-grown software. Well, the code is atrocious. Designer may not care, but if you plan to work together with a developer, the code is unusable. In contrast, an editor such as Pinegrow actually works WITH the html/css/js files, and will open any standard web page. The drawback is that basic knowledge of html and css is required to make the most out of it. Can't have your cake and eat it too.

Adobe had a good attempt with Muse, but here's the problem: the web and its tech evolves too fast for any tool that decouples the design view from the underlying html/cs/js. Muse had its own design view, as had Webplus. So does Xara. All of them work up to a certain extent, but for the developers it is a constant race to keep up, even if they care. As for Xara Web Designer's reviews: you can tell people's expectations and skill sets are all over the place where web page development/building is concerned. Some except simple templates, others full visual design control over the page elements similar to a DTP app. It is difficult to please this crowd. Also, Xara Designer Pro (as opposed to Xara Web Designer) not only includes all the web export stuff, but is also similar to Affinity Designer as a vector illustration app with page support. I recall users of Muse (for example) kept asking for more features they'd seen used on 'forward thinking designed snazzy looking' web pages, and at some point Muse just became an elephant. Impossible to maintain by the developers. That is why so many web page builders now rely on a design view based on html/css/js. Pinegrow is a good example. Or look at WordPress and the variety of visual web page builders like Elementor or PageBuilder. With Elementor there is no need to deal with posts at all, and just work with pages the way you envision. But usually this comes at at a cost of design flexibility/freedom. The other product you may like is Sparkle, which comes close to those visual web builders of old. But it is Mac only. And uses a proprietary format, so again a de-coupling from the web And visual web building tools are generally meant for small static web presences only anyway.

Not entirely true: Xara Designer Pro / Xara Web Designer exists, and does exactly that. But for the sake of a web developer's sanity I'd say Pinegrow would be a much better choice with good human readable code output. Not quite as much freedom as drag and drop, but close enough.

I tested this file in various applications: Affinity Publisher, PDF Exchange Editor, Xara Designer Pro, Affinity Photo, PhotoLine, InkScape,... I don't have a license of Designer myself (yet?). The file chokes up all apps. Some take ages to open it, others (Xara) once opened each move takes forever. Xara is one of the fastest vector rendering engines on the market, but while the file will load, every change takes a long time and Xara chokes. And Xara works absolutely smooth with some very heavy vector files. PDF Exchange Editor is the fastest of the lot and works reasonably well. But that's only for viewing. Still takes a couple of seconds to render those dots when zoomed in. With this many vector objects I don't see how ANY software is going to be able to work in a smooth manner. This file is NOT meant to be edited, but meant for output only. Those dot patterns are usually created at print/output time, and not meant for editing. I think no hardware in the world is going to give you a smooth vector editing experience when dealing with files like these. Perhaps reconsider your workflow.

Yes, as long as 1bit support is lacking, we will have to deal with work-arounds, or just rely on alternative software. A bit frustrating, because when I open your PDF in PhotoLine it takes two clicks to create the proper 1bit layer and overprint it. Two more clicks to assign a spot colour. InDesign treats these type of 1bit tiffs automatically as overprinting. Let's hope the Affinity devs will add this support before 1.7 is released. I think, because of the lack of 1bit support in the other Affinity apps, this may take longer for them to implement, however. I suspect it's just not part of the core functionality of Affinity, and will take more effort on their part. Thanks for all your testing!

Here is an infographic explaining the comic printing process. If printing on high quality glossy paper, a ppi resolution of 800ppi for the 1bit tiff file is a good idea, but it might be higher than that depending on the quality of the printer. The colour may be printed at 400ppi for high quality prints. Publisher is unable to achieve this workflow and retain the resolution of the black line art.

You are missing the point. Do you understand how halftones and LPI (lines per inch) work in print tech? If not, look it up. Printing black and white line art at 300dpi is too low for a quality print. Refer to @Fixx answer about terrible looking comic strips and lettering when printed at 300dpi in a news paper, or in black and white print.

Yet, there is. 1bit prints without being rasterized to half tones. 8bit is always rasterized and converted to halftones. A grayscale 8bit image contains 0-255 shades of gray, and even black will be printed at 300dpi (dots!). A 1200ppi 1bit black line will, however, be printed at that resolution (barring the quality of the paper, and the subsequent dot gain).

You explained it more succinct than I did. Indeed! Here is an example of the wanted PDF output. The black line art is 1200ppi and set to overprint, and the colours are 300ppi. Notice the difference in pixel size. The colour work will be halftones, while the 1bit line art will retain its sharpness when printed - just like black text, or black vector art. No halftones there. Absolutely essential for all sorts of print work. Without this option, Publisher is going to be handicapped from the very start. Just like Affinity Photo is with the lack of 1bit support.

As I explained, the black-and-white line art is printed at a much higher resolution than the colour work. Same as with black vector and text: those are printed at the image setter's / printer's native print resolution (this is a gross oversimplification) not needing any dot patterns (halftones) thus printed much sharper than grayscale or colour art. It needs to be 1-bit because of that. Because it prints at the native print density of an image setter or printer. You can't have any anti-aliasing, because dot patterns are not allowed - or at least, you can control your own dot patterns (halftones). I checked your PDF, and yes the left circle overprints. But all shapes are anti-aliased, which is also unwanted behaviour when doing this type of work. And all shapes are 300ppi, which is useless. We want to retain 1bit high resolution art, and overprint that.

@thomaso The problem is that 1bit tiffs lose their original high resolution when exported to PDF, and cannot (as far as I am aware) keep their original resolution and overprint. For example: I create 1200ppi 1bit ink drawings, which are then overprinted on top of 300ppi full colour renderings. InDesign and PhotoLine have no issues with this. Publisher cannot handle 1200ppi 1bit TIFF files and when exporting to PDF downsamples the ink drawing to whatever document ppi is set (max 400). Which is useless for comic work. We need at least 600ppi 1bit line art for acceptable print quality. Same problem with 1bit 800-1200ppi artwork that must be printed in other circumstances, such as printing on metal (example above). It won't work in Publisher, and always downsample and convert to 8bit art and lose the actual resolution.

Gimp's "animation" options are (sorry) extremely limited and awkward. Use either Krita or OpenToonz instead. Editing gif animations in OpenToonz is very effective and easy in my experience - and extremely powerful. OpenToonz imports and export gif animations if the ffmpeg executable is set up in the preferences. A joy to animate with. The timeline supports layers, of course, although the way they work is different compared to image editors. Krita's timeline is also quite good for animation, and works with layers (in this case just like Affinity).

PDF might be an option. At least for regular and rotated text. Most editors import PDF with text intact. Or perhaps use transparent PDF form fields for your map text with text already filled out, and center text aligned. But curved and distorted text will always be converted to a graphic object, and no longer be text. Alternatively, provide your maps not only as a PSD, but also other native formats (Inkscape, Affinity, ...) And if you do need to provide PSDs with full text editing functionality, you may have to invest in renting Photoshop or get an older CS6 version, or something. Perhaps even the CS2 version will suffice? I mean, if this is important to make a living, I don't think it is a good idea to ignore what your users use as software. Better to accommodate them. I still use an older version of CS6 of Photoshop to deal with these cases myself.

Had a quick look at the 1.7 beta today, because one of my pet peeves of Photo are the small layer thumbnails in pre 1.7. When I first saw this mentioned as an improvement, my spirits skyrocketed...! ...only to crash and fizzle out. Three fixed thumbnail sizes? Even Photoshop offers up to 80px. (which is still too small a max) I hate to be a party pooper, but... Why limit the software to only three fixed layer thumbnails sizes, of which the largest one is still too small (62x62px) for many users, screens, and use cases? Why not introduce a seamless slider and a minimum of 5 presets, and an upper limit of at least 192px or even 256px? Well, I suppose it's an improvement. It is better than before, and usable as opposed to pre 1.6. A bit of a missed opportunity.

Following the reasoning of the OP, ink colours on paper are subtractive, while colours on the screen (RGB) are additive. 100% CMY on paper produces a muddy brown. 100% RGB produces white. So I assume the OP expects that working in CMYK mode should be behaving likewise. But blend modes always work in screen colour space, as far as I am aware. One solution is to turn on overprint for those objects in Designer, for example.

Photoshop's 3d functionality is terribly outdated, and the rendering almost completely useless. Those haven't seen any core updates since their first introduction. Don't bother with those, excepting perhaps the odd 3d text effect. But even then a quick round-trip into Blender will yield a hundred times better and faster result. Affinity Photo is far better served by introducing improved support for rendering compositing pipelines, rather than the team spending any development on 3d functionality that is already available and proven in many existing 3d tools, both free and commercial. "Cobbler, stick to your last", as the expression goes.

The market is saturated with excellent animation applications. Just a few production-ready alternatives for Animate CC (in no particular order): OpenToonz, CelAction2D, Moho Pro, ToonBoom Harmony, TVPaint, After Effects, Fusion/Nuke, Blender (with Grease Pencil animation)... And these are only the start, with many lower-level apps out there, as well as 3d animation software which can also be used for 2d animation (Maya, etc.). Tough market to compete and survive in. Serif probably feels the same, and is not planning a dedicated animation app.

I would consider this a bug, not a feature request. Windows version is also affected. Imagine this situation: the file dialog is smaller than one of the GUI panels. The user attempts to save the file, mis-clicks, and the file dialog is hidden beneath that panel. Unless the user is aware of what just occurred, the user may assume that the app no longer responds. Showstopper! This can be categorized as a user interface BUG, not a feature request. I have NEVER experienced similar behaviour before in any Windows or Mac app. This is a first! Very interesting oversight on the part of the developers. Definitely should be categorized and labelled as a bug. ...and I am going to use this as another clear example in my UX design classes of "How Not To Design A User Interface". I've got a couple of other great Affinity GUI examples which are already part of that list.

I need 1-bit support for my comics and illustrations. Currently I use PhotoLine for this, which surprisingly has perfect support for this, even better than Photoshop or any other image editor out there: works with layers(!) Meaning, unlike Photoshop it's no problem to combine multiple 1bit layers. can be combined in a single document with RGB or CMYK 300ppi layers and create a top 1bit 1200ppi layer PDF output in PhotoLine keeps it all intact, and outputs a proper PDF file. The 1bit 1200ppi layer is retained, and the colour work maintains a 300ppi output. InDesign also works well with this, but I no longer rent that software. The only other software I found so far (other than QuarkXPress) that supports a good 1-bit workflow is PhotoLine. And I know of no other image editor that supports a layer-based workflow with 1-bit graphics. I am hoping that Affinity Publisher will support this workflow as well, but so far no cigar. I think all Affinity products ought to support a 1-bit workflow to make this work out properly anyway. (And an 8-bit indexed colour mode is missing in action as well in Affinity Photo, btw!)

Use X-Mouse to remap your right mouse button to behave like the middle mouse button. Tested in Photo, and works like a charm. I use the portable version. https://www.highrez.co.uk/downloads/XMouseButtonControl.htm I remapped the side buttons on my mouse to behave like the middle mouse buttons. X-Mouse allows you to remap the mouse buttons for each individual app you use, if required.

Ha! You think Tinypng does a good job? Colour Quantizer produces even smaller PNG files, AND at a (much) better quality. The problem with Tinypng is that the user has little or no control over the conversion, while CQ includes a simple to use quality mask brush to indicate areas that must be retained in regards to quality and colours. And a slider option to favour gradients versus colours and a threshold for rare colours. Also complete control over the indexed colour palette, including the option to load up your own custom palette. Did I mention the fine dithering controls? Nothing else comes close to the level of quality control and compression of PNG files possible with CQ. No need for the web, because CQ is a portable 1.32mb small executable. http://x128.ho.ua/color-quantizer.html