Medical Officer Bones

There it goes, my inspiration that is, out of the window, and I lost it trying to change who knows what shortcut key... again.
As a professional in video, animation, 3d and audio I have used many many applications over the years, and find Affinity package a real refreshing leap forward. However, I must admit that the preferences window across all three Affinity apps (Photo, Designer and Publisher) is one of the most useless I have ever encountered. I am not afraid to switch and learn applications and am ready to customize the new ones I learn to my own best practices, and the preferences window is my friend or it should be, but Affinity's is not at all. Please let me try to explain what I find is wrong with and suggest some changes which I did not think a lot about, but seem much simpler to use. Let's start:
1. The preferences window uses a unique visual paradigm, completely different from any other dialogue I have encountered in the rest of the application. It has a header with Back/forward buttons, "home" button (with an odd icon and a drop-down menu) and search bar. No other panel, toolbar, manager, assistant or any other window in Affinity uses this paradigm or at least my humble knowledge of the app does not bring any into the mind. I doubt that this is good. For instance having tabs, like some other windows would do the trick no need for back/forward buttons, no need for home button, no need for drop-down menu, just 7 simple instantly accessable tabs.
2. search bar is a sneaky red herring! It is in fact dangerously useless! I'd like to change a shortcut for brush size in pixel persona? typing any of these terms does not help me to find where to do it. It seems that this search bar is good for searching only a couple of dozen words which does not make any sense at all, either you make every single preference item that can be change searchable or get rid of the search bar because the way it is now is frustratingly useless.
3. I will not go in depth on my thoughts about "General", "Color", "Performance", "User Interface" and "Tools" pages as I do see some benefit of "bite sized" preferences pages even if some items on them seem to belong to another page, and the number of these pages could actually be decreased. (for instance half of the "Tools" preferences could easily belong to "User Interface" tab)
4. Checkboxes, since they have really powerful results would benefit from tooltip help with a more verbose description of what they do.
5. "Miscellaneous" could easily be renamed to "factory resets" or something on that line, as that is what it does.
6. And now I come to my nemesis, the "Keyboard Shortcuts" page. Where to start?!
a) there is a search bar on the upper right, that is as we said a sneaky trap, and a red herring. It does not help us here, and will take us "home" probably finding nothing of interest.
b) we need to use these two fiddly drop-downs. The first one could easily be replaced with beautiful Draw, Pixel and Export icons cutting the number of actions for picking persona to edit to only one click (or even better none.. read on). The second one is really unintuitive as its items partially overlap in different personas. It took me a while to get the idea that this second one is contextual to the first one (as the list changes "behind the curtain")... I got it only after learning my way a bit around the app so I recognised that some items belong to some personas.
c)  a quick overview of other buttons and check boxes in this upper region of Keyboard Shortcuts page;
"Apply to all" -what? to all what? I had to dig through the manual to see what it does, and all it would take to fix it is to call it "apply shortcut changes to all personas" without this information there is no way to know that there actually are some connections possible between personas. As if the for instance, brush size in pixel and draw persona must be separate.
"Ignore Modifier—Lets you create shortcuts using a single letter designation instead of using keyboard modifiers." says the manual, and I still do not get it. Does it allow me to pres only the letter in application without modifier keys and get what I want? No, as Ctrl+S is stil "save" and "Ctrl+Shift+S" is stil Save as. Does it filter out the input of Modifier keys while assigning new shortcuts? No. So what does it do? Maybe a better explanation in manual would help, and a more verbose checkbox title or tooltip.
"Load/Save" what? it loads and saves what? a file obviously, but what does that file contain? All shortcuts, or only those in focus? Maybe "Load Shortcut configuration" or something on that line would be better. to be continued...

I cannot respond to your critique of Aph vs NX-D.
I only know that APh works to my satisfaction and I have tried the Nikon program in the past and did not like the way it operated.

Here is a stock photo agency I sell some of my photography through. They are pretty picky when it comes to quality.
All of the images I have here were processed from NEF files using APh.
These images would not have been accepted by this agency if there were any quality problems with the way they were processed.

https://www.robertharding.com/photographers/stevenlove/

It worked! I will create an action for you, which can then be used to batch process the hundreds of images you have in one go in PhotoLine.
I attached the fixed TIFF version, which is LAB 16bit and opens in Affinity Photo.  Here is the result for you to check:

Chris Birthday009.tif

It is doubtful the Affinity devs will ever support JPF files.
If, like you write, your intention is merely to convert all your 16bit JPF files to 16bit Tiff or PNG files, I suggest you look into the fully functional 30 day trial of PhotoLine, and use its batch processing to convert all your files in one go. PhotoLine reads and writes 16bit JPF files and retains the 16bit per channel information.
PS you find this batch conversion option under File/Functions/Batch Converting in PhotoLine. The dialog is self-explanatory.

Made a short video, also added the texture PNG I created to see if your extend and quality options appear using the file.

 
Texture file:
 

I assume you turned on "Force Pixel Alignment"? If not, Photo will work with decimal pixel values, resulting in ugly anti-aliased copies when positioning to a half-pixel value, for example.
The trouble is that if you already moved bitmap objects, turning on this setting does not fix the issue initially: first the object needs to be moved again, and then the setting kicks in. And when "Move by Whole Pixels" is active too, the blurred version will not "unblur". So turn off this option first, then turn on Force Pixel Alignment. Then move the bitmap, and it should clear up.
The combination of these two settings can be a potential pixel art killer, so be aware of the effects.

This has been requested many times before I realize, but I am going to reiterate it one more time.
As it stands, the export persona is pretty much useless, because it doesn't allow for a real-time preview of the rendered asset(s) to check the quality before export. Therefore, I don't use Photo's export option, and instead export a full quality PNG and optimize in external software.
There are a number of other issues with the export (jpeg quality<->file size, inability to set >256 colour PNG output, lack of dithering options and resample options), but this is really the major one. I don't understand why this wasn't implemented in the first place, but hopefully it will be at some point.

Few other alternatives for animation without a focus on visual effects?
ToonBoom Harmony (essentials, Advanced, Premium) OpenToonz / Toonz Moho (Pro) TV Paint CelAction 2D Blender 2.8 + new 2d animation mode Other 3d apps (Max, Maya, Houdini, ...) Animate CC And many other options depending on your needs (Krita, ClipStudio Paint EX, ...)
If anything this market is quite saturated with powerful options, both commercial and free.
Unless I misunderstand you?

The market already is saturated with both free and commercial production level animation software. Take your pick: Toonboom, TVPaint, OpenToonz, 3d animation software (Blender, Modo, Max, Maya, Lightwave), CelAction2D, Moho Pro, Flipbook, Spine, DragonBones, Krita, ClipStudio Paint EX, Animate CC, and the list goes on and on. Not to mention visual effects software which also includes very accomplished 2d (and 3d) animation features (Nuke, Fusion, HitFilm, etc.).
So just pick one of the above, and import your work. I don't think Serif is going to attempt to compete in this market with a dedicated animation tool.
That said, a simple Krita-like animation timeline would be nice to have in Affinity.
 
Funny, the first time when I read this sentence I read "Adobe Perversion". :-) I never knew about that software, btw.
In regards to presentation software: I create a lot of presentations/slides for my work, and I've completely given up on superfluous eye candy like transitions and animations years and years ago. I create my slides in design layout software, and export a simple PDF. Audiences are distracted and bored at the same time when faced with yet another PowerPoint-like slide collection. Nowadays I focus on the content and the content structure instead of useless slide animations and effects unless I have to show a complex topic or subject which requires animation to clarify the content. In that case I fire up a movie file.
Otherwise I just stick with simple static slides which have a good clear readability and visual hierarchy. People grow bored quickly staring at that same old cross fade or wipe-in for the umpteenth time. Good presentation technique works FAR better than someone rattling off yet another boringly animated presentation slide. The less slides to bring the message across, the better.
"Oh look, it's one of those presentations where the heading and text bullet points fly in sequentially from whichever direction" responses should be avoided. Have the audience focus on the presenter and the presented content, and avoid pointless animated effects. Avoid inserting graphics and images "just because" - there should be a valid reason. Stop brain-dumping all over your slides. Elucidate and engage and interact with your audience. Stupid pointless animation effects will just bore the audience. Clarify, use great typography, visual structure and presentation structure instead of relying on visual animated effects which no-one in your audience appreciates or cares about anyhow.
If I do need to create something eye-catching, I create it in an animation and/or visual effects package with sound and so on. But that would become a running presentation for a booth at a convention, or something. Or a museum kiosk. In these cases I have control over the hardware used as well. And in such cases I avoid traditional presentation software like the plague and opt for different solutions.
sso often have I seen presenters get into technical trouble because PowerPoint wouldn't run right, or slow, or the hardware was completely outdated and software wouldn't support their latest greatest presentation files. Or they would bring their own snazzy Mac notebook with Keynote, and forget about that RGB/HDMI regular connector.
PDF always works no matter the OS, and I bring my own portable version of PDFExchange Editor, as well as export simple PNG files just in case when presenting in locations where I haven't presented before.
If you are heck-bent on introducing slide transitions, why not export to a PDF, and assign page transitions with a PDF tool like PDFExchange Editor? Works fine.
 

Right, there seems to be a bit of confusion here. Before continuing, I think we should make it clear that there is a difference between:
A) on-screen text rendering while working on a project, and
B) text rendering quality when the file is rendered for final output.
It is important to distinguish between the two when discussing text rendering and anti-aliasing quality, because even when (A) looks atrocious, the actual output (B) may be perfectly fine.
@KirkS You mention that Affinity's text anti-aliasing looks ugly when zoomed in at 150%. This falls into category (A). And yes, you are correct, and the rough text rendering is due to the way Affinity needs to convert pixels to a view which renders half pixels: 150% is an awkward on-screen zoom factor which forces the application to render pixels to scaled up half pixels.
This used to be an issue with all image editors, including Photoshop, and the situation improved when video cards were utilized with either OpenGL or DirectX rendering. When graphics acceleration (OpenGL based) in Photoshop is turned off (or is not supported on a flimsy GPU) the text rendering at 150% will look even worse than in Affinity. Other applications such as Krita also use graphics hardware acceleration to render the viewport, and zooming in will result in a (much) more acceptable view quality, albeit often with fuzzy edges.
Looking at your posted Photoshop example, you will notice that the edges of the text look quite fuzzy, and OpenGL rendering is utilized to anti-alias the text rendering on the fly. Turning off the text's anti-aliasing looks terrible due to the awkward conversion to 150% zoom factor, and really has no bearing on this argument except to underscore the fact that zoom factors other than exact multipliers generally result in bad on-screen text rendering. Zoom in at 200%, and it will look pixel precise.
In short, screen rendering of text in graphics software may or may not rely on the video card (GPU) to anti-alias the result on-screen. Some software is really good at this (Photoshop, Krita), but it will still produce fuzzy looking text when zoomed in, of course.
Mind, the way your text looks on the screen is in no way guaranteed to be representative of your final output, in particular when zoomed in or out at a decimal zoom percentage. And then there is the impact of vector output or bitmap output. When we save the file as a PDF from Affinity Photo, the text will remain vector, and be rendered beautiful in any good PDF viewer and at any zoom factor (within limits, of course).
Anyway, if the text rendering bothers you at 150% or other zoom factors like 125%, 109%, etc.) avoid previewing the work at those zoom levels. Only preview the text at 100%, 200%, 300%.
Next, lets discuss (B): final output text rendering.
The quality of the final text rendering output depends on a number of factors:
the anti-aliasing settings (on/off, specific controls like the ones in PS or Fireworks) whether or not the design software allows for text to be positioned at decimal pixels whether or not the design software features pixel snapping, and whether this is turned on or off the font rendering engine behind the text rendering the resolution of the final file whether the text is output to vector (see above) or to bitmap For GUI designers (1), (3) and (4) are quite important. Some graphics software utilizes the OS's font screen rendering to render the text: for example, PhotoLine uses the Windows font rendering when pixel snapping is activated, which results in a 1:1 result compared to how Windows would render the text. GUI prototyping/design software will do the same, generally. This is of course the preferred method for GUI designers. And the font rendering looks arguably better than Photoshop's sharp setting in my opinion.
Photoshop does NOT, as far as I am aware, make use of the OS text rendering, and the final rendered bitmap result will look different compared to OS rendered text (as is demonstrated in the example posted earlier in this thread).
So how does Affinity Photo perform in the output (B) category?
PDF output of text is perfect. No problems there. It depends on the PDF viewer's on-screen anti-aliasing and text rendering engine, of course. But Affinity is not to blame for any issues related to the PDF viewer's text rendering. If this is an issue, pick a different PDF reader.
As for bitmap rendered text output, Affinity's anti-aliased small text rendering is indeed marginally fuzzy looking compared to other design applications. Personally, I feel the anti-aliased text looks good enough. It would be nice to have control presets for the anti-aliasing, but the coverage map is quite helpful, if a somewhat cumbersome method. But it does offer more fine control compared to fixed presets. Which is a plus in my book.
That said, the major issue in Affinity Photo is the lack of an option to just plain turn off anti-aliasing for text (and vector objects in general). This is required for GUI work and often for very small text output. The Coverage Map won't cut it here. As long as (1) doesn't include a simple option to turn off anti-aliasing altogether, it will remain an issue for screen designers and pixel artists.
 

Right, there seems to be a bit of confusion here. Before continuing, I think we should make it clear that there is a difference between:
A) on-screen text rendering while working on a project, and
B) text rendering quality when the file is rendered for final output.
It is important to distinguish between the two when discussing text rendering and anti-aliasing quality, because even when (A) looks atrocious, the actual output (B) may be perfectly fine.
@KirkS You mention that Affinity's text anti-aliasing looks ugly when zoomed in at 150%. This falls into category (A). And yes, you are correct, and the rough text rendering is due to the way Affinity needs to convert pixels to a view which renders half pixels: 150% is an awkward on-screen zoom factor which forces the application to render pixels to scaled up half pixels.
This used to be an issue with all image editors, including Photoshop, and the situation improved when video cards were utilized with either OpenGL or DirectX rendering. When graphics acceleration (OpenGL based) in Photoshop is turned off (or is not supported on a flimsy GPU) the text rendering at 150% will look even worse than in Affinity. Other applications such as Krita also use graphics hardware acceleration to render the viewport, and zooming in will result in a (much) more acceptable view quality, albeit often with fuzzy edges.
Looking at your posted Photoshop example, you will notice that the edges of the text look quite fuzzy, and OpenGL rendering is utilized to anti-alias the text rendering on the fly. Turning off the text's anti-aliasing looks terrible due to the awkward conversion to 150% zoom factor, and really has no bearing on this argument except to underscore the fact that zoom factors other than exact multipliers generally result in bad on-screen text rendering. Zoom in at 200%, and it will look pixel precise.
In short, screen rendering of text in graphics software may or may not rely on the video card (GPU) to anti-alias the result on-screen. Some software is really good at this (Photoshop, Krita), but it will still produce fuzzy looking text when zoomed in, of course.
Mind, the way your text looks on the screen is in no way guaranteed to be representative of your final output, in particular when zoomed in or out at a decimal zoom percentage. And then there is the impact of vector output or bitmap output. When we save the file as a PDF from Affinity Photo, the text will remain vector, and be rendered beautiful in any good PDF viewer and at any zoom factor (within limits, of course).
Anyway, if the text rendering bothers you at 150% or other zoom factors like 125%, 109%, etc.) avoid previewing the work at those zoom levels. Only preview the text at 100%, 200%, 300%.
Next, lets discuss (B): final output text rendering.
The quality of the final text rendering output depends on a number of factors:
the anti-aliasing settings (on/off, specific controls like the ones in PS or Fireworks) whether or not the design software allows for text to be positioned at decimal pixels whether or not the design software features pixel snapping, and whether this is turned on or off the font rendering engine behind the text rendering the resolution of the final file whether the text is output to vector (see above) or to bitmap For GUI designers (1), (3) and (4) are quite important. Some graphics software utilizes the OS's font screen rendering to render the text: for example, PhotoLine uses the Windows font rendering when pixel snapping is activated, which results in a 1:1 result compared to how Windows would render the text. GUI prototyping/design software will do the same, generally. This is of course the preferred method for GUI designers. And the font rendering looks arguably better than Photoshop's sharp setting in my opinion.
Photoshop does NOT, as far as I am aware, make use of the OS text rendering, and the final rendered bitmap result will look different compared to OS rendered text (as is demonstrated in the example posted earlier in this thread).
So how does Affinity Photo perform in the output (B) category?
PDF output of text is perfect. No problems there. It depends on the PDF viewer's on-screen anti-aliasing and text rendering engine, of course. But Affinity is not to blame for any issues related to the PDF viewer's text rendering. If this is an issue, pick a different PDF reader.
As for bitmap rendered text output, Affinity's anti-aliased small text rendering is indeed marginally fuzzy looking compared to other design applications. Personally, I feel the anti-aliased text looks good enough. It would be nice to have control presets for the anti-aliasing, but the coverage map is quite helpful, if a somewhat cumbersome method. But it does offer more fine control compared to fixed presets. Which is a plus in my book.
That said, the major issue in Affinity Photo is the lack of an option to just plain turn off anti-aliasing for text (and vector objects in general). This is required for GUI work and often for very small text output. The Coverage Map won't cut it here. As long as (1) doesn't include a simple option to turn off anti-aliasing altogether, it will remain an issue for screen designers and pixel artists.
 

Just pointing out that your idea of "complete" and someone else's idea of "complete" are not the same.
 

This has been requested many times before I realize, but I am going to reiterate it one more time.
As it stands, the export persona is pretty much useless, because it doesn't allow for a real-time preview of the rendered asset(s) to check the quality before export. Therefore, I don't use Photo's export option, and instead export a full quality PNG and optimize in external software.
There are a number of other issues with the export (jpeg quality<->file size, inability to set >256 colour PNG output, lack of dithering options and resample options), but this is really the major one. I don't understand why this wasn't implemented in the first place, but hopefully it will be at some point.

This has been requested many times before I realize, but I am going to reiterate it one more time.
As it stands, the export persona is pretty much useless, because it doesn't allow for a real-time preview of the rendered asset(s) to check the quality before export. Therefore, I don't use Photo's export option, and instead export a full quality PNG and optimize in external software.
There are a number of other issues with the export (jpeg quality<->file size, inability to set >256 colour PNG output, lack of dithering options and resample options), but this is really the major one. I don't understand why this wasn't implemented in the first place, but hopefully it will be at some point.

The devs have stated they will not implement a 1-bit mode. At most they are willing to add some sort of 1bit export and (hopefully) proper 1bit handling in Publisher PDF export.

On Windows the answer is PDF-XChange editor. In the past I used to work with Acrobat Pro to create interactive fillable forms, but PDF-Xchange Editor is actually more usable than the "original" for this type of work. And full Javascript support.
I am a firm believer in a two-step process: design the document in a dedicated design/publishing app, then add the interactivity and form fields in a dedicated PDF form builder. The reason is simple: even if the design app supports inserting form fields and the like, it could never hope to compete with a specialist PDF form editor.
As for ePub export in Publisher: I hope for the best, but harbour no expectations at all. Besides, interactive FXL ePub files only work properly in Apple's ecosystem (iBooks reader), while on Windows, Linux, and Android such books break, because no good ePub reader exists which supports these. InDesign's FXL interactive ePub files are near to worthless to 90% of users.
Flowing ePub 2 output is however quite useful to have. But that means the output would differ completely compared to what is seen in Publisher: flowing ePubs' contents flow and adjust according to the screen size and user settings. Therefore it is debatable how useful such output would be in Publisher. To be honest, I never used InDesign's non-FXL epub export and instead opted to export text and import into Jutoh or Sigil. (Far more controllable and reliable in my experience.)
I would like to see plain old structured semantic html output from Publisher (no fancy CSS styling required but linked images would be with image quality export option), which is easily converted to flowing epubs with any of the above mentioned tools or even PanDoc.
Epub FXL output would be interesting to have once the reader software situation on OS platforms outside of Apple is resolved. But I am not holding my breath: I have been waiting for years now, and it only got worse since the demise of Readium on Chrome  due to Google's actions.
 

The devs have stated they will not implement a 1-bit mode. At most they are willing to add some sort of 1bit export and (hopefully) proper 1bit handling in Publisher PDF export.

The devs have stated they will not implement a 1-bit mode. At most they are willing to add some sort of 1bit export and (hopefully) proper 1bit handling in Publisher PDF export.

The devs have stated they will not implement a 1-bit mode. At most they are willing to add some sort of 1bit export and (hopefully) proper 1bit handling in Publisher PDF export.

I encountered this limitation too. I prepare comics work for print, and for that 1bit black and white high resolution 800ppi-1200ppi images must be created.
While Photoshop has the option to work in 1bit image mode, most of the functionality is deactivated: layers do not work for example. And to composite the line art with the colour plate, InDesign is required to produce a PDF.
After some trial and error I discovered that, as far as I could find, only one non-Adobe workflow option exists. This assumes the line art is inked in B&W at a minimum of 800ppi or scanned at that minimum resolution. I tried a combination of Gimp, Scribus, but while Scribus supports export to PDFx/4 with 1bit transparent images, I couldn't create a good transparent 1200ppi 1bit image in Gimp.
So I do my prepwork in PhotoLine now, which supports 1bit image layers, and these can be combined in the same layer stack with the 300ppi colour work. First I open the 300ppi colour work, then import the 1bit 1200ppi line art, activate transparency for this layer, and remove the white background. Then I add the vector text balloons and other vector elements, and export a PDFx/3 document. PhotoLine miraculously seems to understand that I want a layered 300ppi PDF with a 1bit B&W1200ppi layer printed on top, which was unexpected when I first tried it a year ago. The result is a nice layered PDF which prints the page's colours at 300ppi, the line art superimposed at a crisp 1200ppi, and the vectors at the image setters max res.
If you need to prepare 1bit images, just get PhotoLine for this. Work in Affinity Photo, and convert to 1bit with PhotoLine, and output. I use PhotoLine as a InDesign replacement for this type of work. It's an inexpensive solution to a very particular workflow requirement.
One caveat with both Affinity Photo and PhotoLine: neither one supports an 8bit (or less) indexed image mode. For this I use Pro Motion NG - which is kinda the industry standard for indexed pixel art anyway. If I need to work on indexed images, I open the art or photo in PM, and it converts it nicely to an indexed image. And PM being a specialized indexed image editor, I get the best indexed image tools in the business. Good for textile print prep too, to get remove those anti-aliased edges :-)
So three apps: Affinity Photo, PhotoLine, and Pro Motion NG combine to achieve an even more powerful workflow with indexed and 1bit images compared to Adobe. Not bad.

If you are on Windows, and have no need for a prepress PDF toolset, then I recommend PDF-Xchange Editor. Great annotation/commenting/revewing tools, form creation, OCR, Scanning, and full PDF editing. The GUI is miles ahead of Acrobat (that horrible form properties dialog in Acrobat...). It also supports (as far as I have tested) all Acrobat Javascript. It even loads and displays 3d models embedded in a page.
I found it to be an excellent Acrobat replacement. Only its prepress tools are missing, unfortunately.

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.

The G'MIC filter set includes a Pixel Sort filter. To use it (free), download Krita, and import/copy-paste your image in Krita.
https://krita.org/en/
Then apply the pixel sort filter: Filter-->Start G'MIC QT and search for the pixel sort filter. Change the settings to your liking.
I wish the Affinity devs would include a version of G'MIC. It's a really nice set of effects.
 

The G'MIC filter set includes a Pixel Sort filter. To use it (free), download Krita, and import/copy-paste your image in Krita.
https://krita.org/en/
Then apply the pixel sort filter: Filter-->Start G'MIC QT and search for the pixel sort filter. Change the settings to your liking.
I wish the Affinity devs would include a version of G'MIC. It's a really nice set of effects.
 

Both companies also offer full perpetual licenses, aside from subs. Click on the perpetual links on their pricing pages.