Medical Officer Bones

DPI (or actually PPI in this case, but Affinity gets the terminology wrong) doesn't say anything about the actual resolution of your files. It is merely a parameter that tells software at what size it will be printed. To learn what is happening in your workflow, we also must know whether the resolution in pixels is changing or not in your files. If this is not the case, then the PPI parameter in the Affinity file is somehow changed at some point in your workflow. So: do the 300ppi and 96ppi files differ in pixel dimensions, or not?

No, the behaviour is caused by Photo's inability to deal with 1bit images. If no changes are made to the image, and the user returns to Publisher, the image looks the same as before. While in Photo "mode" the image is converted to a greyscale 300ppi version. Any change triggers the conversion.

As long as Publisher and Photo cannot deal with 1bit bitmaps, it is useless to me for most of my print work. The latest 1.7 still converts a 1bit 1200ppi image to 8bit when exported to pdf, irregardless of the settings. Good 1bit support is absolutely required for a variety of print jobs. When imported, a 1200ppi 1bit image looks fine in Publisher. Switching to Photo results in the image being down-sampled to a 300ppi anti-aliased version in the view. Any edit in Photo will return a 300ppi greyscale image to Publisher!!! Imagine that: import a 1bit print resolution tiff in Publisher. Then the user decides to remove a scan stain, or something in Photo. Result: the image is reduced, without asking, to a 300ppi greyscale version, which will print at low resolution and with fuzzy edges. And because the user worked zoomed out, they did not notice and generate a pdf for printing. Now imagine the client's reaction. It staggers the mind to realize that the Affinity devs have stated they will never support 1bit images in Photo. As for Publisher support: it is all up in the air. I have not yet tested the 1.8 beta. Will do this today.

Agreed. Even when I uninstalled all Adobe apps and the CC manager and rebooted, Process Explorer still lists two or three Adobe services. The only way to remove these is to do it manually. Autoruns is a handy utility to manage that last step. Bridge by itself is actually quite good.

Get the latest HitFilm Pro and Ignite Pro for three tenners at HumbleBundle! https://www.humblebundle.com/software/professional-filmmaking-tools-software

More options: Godot game engine with the Slides script: https://github.com/GDQuest/godot-power-pitch Bit more technical, but the built-in timeline and other options enable some very complex presentations and animations to be made, including fully interactive ones. And exports to independent executables or the web. No need for a player. And completely free! Higher learning curve, however. Construct game engine. Latest version also includes a timeline. Exports directly to the web, or convert to an executable which runs without the need for a player. Pinegrow with the new Interactions plugin. This is a visual web editor, and the Interactions plugin allows for some nifty animations. Most importantly, it includes an animation timeline to control individual elements. https://pinegrow.com/blog/introducing-pinegrow-interactions/ Animate CC. Powerful timeline again to build any type of animation. Export to the web to share presentations. Or export an executable. Tumult Hype (Mac) or Saola Animate (Windows) Both are html5 animation apps, which feature a timeline based approach, comparable to Animate CC or the now defunct Edge Animate. https://tumult.com/hype/ https://atomisystems.com/saola-animate/ While the game engines require more time to learn, they would easily be able to create just about any type of highly interactive and animation controlled presentation. At the expense of more complexity, of course. Only an animation timeline will allow for full control of animations. Instead of re-inventing the wheel, you could use any of the above tools to create only the animations you require, and then embed these in your Powerpoint presentation. But I am unsure if it is possible for embedded html objects to receive clicks. It wasn't in older versions.

Well, what do you know. Things *are* changing, it seems. Microsoft perceiving Linux as yet another possible revenue stream: https://www.theinquirer.net/inquirer/news/3084602/microsoft-teams-linux-official

Workaround options are: Krita OpenToonz Both export to Animated Gifs through FFmpeg (in both applications the user must point to the FFmpeg executable before exporting to Animated Gif is possible). Import your assets from Affinity into either one to begin animating. Both are open source and free. OpenToonz also allows for very easy automatic tweening between positions, scaling, rotating, and so on, and, unlike Krita, also imports gif animations for editing. Although OpenToonz might seem overkill for animated gifs, I discovered it handles these quite well.

I think the OP means that up-scaling pixel art at values other than 2x, 3x, 4x, etc. Affinity Photo will introduce soft interpolated anti-aliased pixels when viewed. This destroys the intent of pixel art. Here is an example. The original is 20x24 pixels. Up-scaling to 150x180px results in fuzzy edges in Affinity's viewport. The same operation in Gimp, Photoshop, PhotoLine, Krita, ColorQuantizer, etcetera, creates a clean upscaled version in the viewport. Yet when the upscaled version is exported with nearest neighbor, the result is correct without any soft edges. In short, the result as shown in Photo does not match the exported version. Internally the image is fine, yet it is displayed interpolated. A work-around is to close the original document after up-scaling, and open the new exported version: it will display correct. As far as I can tell, this behaviour is caused by Affinity Photo's internal decimal pixel handling. No other image editor behaves like this, and I feel it is a bug. I was bewildered by this myself during testing, because it is completely counter-intuitive, and I haven't ever experienced similar behaviour in any other bitmap editor. I tried fiddling around with the pixel snapping options to see if this behaviour could be avoided, but so far no luck. Anyway, definitely room for improvement. Very confusing. *Edit* Weird, I had one last try, and now it seems to work. Must be a combination of settings...

If you like Bridge, you can keep using it alongside Affinity Photo. Bridge is a free download, although it still requires the CC app to install.

Do you own the Debut or Pro version? The Debut version doesn't include vector drawing and tools customization or story management. You are correct that the Debut and Pro versions are of limited use for animation: only 1 second of animation is possible, and only EX offers the animation export options. They just had a Black Friday deal, so it is a bit unfortunate that you missed that. On the other hand, I purchased ClipStudio EX years ago, and so far all the updates have been free. With some luck they should have another sale on Boxing day or around Christmas, so it might pay off to wait a couple of weeks. If you have the Pro version, I would suggest to create a small animation in that, and try out the various options to see if you like it or not. I agree that the animation timeline and the way animation layers / cells work takes a bit of time to get accustomed to. It is actually rather similar to OpenToonz in that regard, because of the separation of drawings and timeline frames. But it is really powerful: for example, an animation frame can be built up from several layers in an animation layer and cell. So the sketch, initial lines, cleanup, fills and shading can be set up in layer groups in a cell in a animation layer. Each animation layer can be used to layer various animated elements in turn. And animation cells can be reused in the timeline, making it easy to create a repeating smaller sequence inside a larger sequence. Layering your art is not possible in OpenToonz without adding additional animation layers (Art layers in Toonboom Harmony come close to this workflow, but are not as versatile). A tip: don't forget to right-mouse click layers and timeline frames. It exposes a lot of the functionality that way. Good tutorial:

Just out of curiosity: have you ever tried ClipStudio EX? Brilliant drawing tools, both vector and bitmap, and dedicated tools to correct vector strokes (correct line width, redraw a stroke and its thickness, simplifying a stroke, etc). The EX version has very good frame-by-frame animation, as well as onion skinning with options like monochrome, half-transparent, and full opaque. ClipStudio is used in production by many Japanese animation studios. It even has shot and scene options to keep track of these in your animation workflow. Then the shots can be exported directly to OpenToonz to finalize and combine all the scenes/shots and release. It's an application targeted at digital artists, and has some of the best drawing "feel" of any drawing software in my opinion. It just works really, really well, and the vector drawing tools feel like bitmap drawing tools. I can imagine! I animate as well, and I wouldn't even want to think about how much such an approach would slow me down (both time-wise and just being creative), and frame-by-frame animation is laborious enough as it is!

Atom was my main work horse until I met VSC. Atom is great, Visual Studio Code "greater", in my opinion. Atom struggles somewhat with larger files. At least it did last time I used it.

Dreamweaver can hardly be called a WYSIWYG editor anymore. You need at least basic html and css knowledge to create a web page in DW. Besides, DW's days are pretty much over, or at the very least has become a marginalized product in web development. Adobe ran it into the ground. An excellent and capable visual web page editor is PineGrow, which is what I had envisioned Dreamweaver to become. Some basic html and css skills are more or less required, though. Combine PG with the free and awesome Visual Studio Code editor from Microsoft, and the two form a combo that is hard to beat. The other day the PG devs also released a full visual event-based animation timeline for PineGrow.

BMP support would be great, as well as DDS, DXF, WEBP export, .... Common file formats, really. But I think I figured out why the Affinity devevlopers seem so reluctant to implement additional file formats! The Export dialog would become awkwardly wide, with silly proportions and too many icons would cause cognitive overload in the poor brains of Affinity users! That makes absolute sense to me! Therefore I think it is better to limit the number of export file formats in Affinity, because adding more export icons would impact this export dialog's user experience in a very negative manner. TGA was added only a short while ago, and I assume it led to many a deliberation and heated argument in the Affinity team whether to include it or not, which obviously led to a stand-off, and which in turn led to its very belated inclusion, even though many users had requested it. I understand their conundrum in this case. Each new export file format that is proposed leads to more icons, and hence, to an ever more widening dialog, with more and more icons. I propose to remove TGA and WMF (luckily the Mac version omits WMF). Too many icons already clutter this Export dialog, in my opinion, so less is more!