Medical Officer Bones

In the simplest of terms: I used the OP's original image with the baked unsharp mask effect, and then applied an unsharp mask adjustment layer effect in reverse with negative layer opacity.
That is exactly what the OP is trying to achieve: undoing/reversing an unsharp mask effect. But as I said, it cannot restore all original information, of course, because applying unsharp mask will always destroy some information.
*edit* I tested this method with other images with an obvious unsharp mask filter applied to them, and it depended on the particular image how successful this move is. In some instances lower than -50% layer opacity would be too fuzzy. In other images it did not really help that much unless other adjustments were made afterwards, or some masking to protect details.
To visually clarify the layer stack (notice the -100% layer opacity):

There is now: Krita!
https://krita.org/en/item/first-krita-beta-for-android-and-chromeos-in-play-store/

Exactly! Node-based compositors generally have way more non-destructive and flexible options for image editing. When I explain this concept to users familiar with node-based editing, they generally immediately understand what I am talking about.
It is a cool trick in your toolbox to have access to. I wish and hope that Affinity will consider implementing an expanded layer opacity range as well, because it is forward-thinking, rather than sticking with old-fashioned 25 year old Photoshop concepts.

Never really thought about reversing unsharp mask, but I will play too. The only image editor that I know of that can apply a filter "in reverse" is PhotoLine. So I opened the above image in it, applied an unsharp mask adjustment layer, and reversed the layer opacity to -100 (PhotoLine allows for negative layer opacity values which will invert an adjustment layer's effect).
On the left, the original. On the right, the original oversharpened version. In the middle, the reversed unsharp mask filter (9.2 size).
Unsharp masks destroys part of the original information through blurring, though. It can never be restored fully. The sharp highlight spikes remain, and should be filtered out in post. That said, the inverted unsharp mask version does look improved.

 

Never really thought about reversing unsharp mask, but I will play too. The only image editor that I know of that can apply a filter "in reverse" is PhotoLine. So I opened the above image in it, applied an unsharp mask adjustment layer, and reversed the layer opacity to -100 (PhotoLine allows for negative layer opacity values which will invert an adjustment layer's effect).
On the left, the original. On the right, the original oversharpened version. In the middle, the reversed unsharp mask filter (9.2 size).
Unsharp masks destroys part of the original information through blurring, though. It can never be restored fully. The sharp highlight spikes remain, and should be filtered out in post. That said, the inverted unsharp mask version does look improved.

 

Many other vector illustration apps on the market today already support DXF import & export: PhotoLine, CorelDraw, etc. Heck, even LibreOffice Draw will import and export these files.
Aside from this, Designer needs vector fill support for this type of work, which it does not at this time. The competition, meanwhile, do. Apps like PhotoLine and  Illustrator also support vector fills with the fill bucket tool to quickly fill areas independent of the actual vector shapes.
There is still some catching up to do for Designer before it becomes a truly attractive proposition to architects...

Nope, not the only one 😉
I agree with @Kuttyjoe : the way the controls are implemented in Photoshop for rotating the view is less from ideal. And I concur that the huge wind rose that suddenly appears in the center of the screen while rotating is quite distracting. Never liked that at all either.
As far as shortcut keys go, I actually prefer Krita, which is more in line with how 3d applications layout similar controls: <ctrl> middle mouse button zooms and shift middle-mouse button rotates the view. I find ClipStudio's space-shift/ctrl not as comfortable, because the action requires two fingers simultaneously pressing down keys on the keyboard.
Using a similar control method as Krita would be in line with how Affinity uses the middle mouse button to pan the view.
@Pierre68 The anti-aliasing of Affinity's rotated view is absolutely dreadful (at least, on Windows it is, and I have not tested Mac yet). It is unusable in my opinion. Before the devs implement a proper view rotation, they need to deal with that first and foremost. Zoomed in inks at non-decimal percentages look bad as well in Affinity Photo compared to ClipStudio and Krita. ClipStudio looks best in this case.
In short, my work requires a lot of inking, and I cannot tolerate Affinity Photo for this type of job. Even if I wanted to.
PS on a side note: on top of these issues, a major problem is the bad interpolation while drawing zoomed out in Affinity Photo. For example, when I work on a 10000 by 5000 px canvas in Photo, and draw inks (thin black strokes) zoomed out, the resulting strokes display kinks and straight interpolated sections. This does not happen in either Krita or ClipStudio (and yes, even when I turn on the stabilizer at low values: I hate using a stabilizer that is set to strong values - If I can, I turn it either off or down to the minimum).

@Jowday Could not agree more. Well said.

Hi @mayfly
Stiff opposition or the like from a small core of forum users is quite normal here and I know for a fact that new users (customers) simply quit the forum because of it. I would be surprised if Serif didn’t care. They do.

I also know Serif do read forum posts here and thus also your legitimate concerns and good suggestions. So you have been heard. You just won’t get an official answer to your suggestions. You will get support though from their staff. Perhaps they will take your suggestions into account, perhaps not.
My personal advice to Serif for v2 of Photo is not new features but a complete usability overhaul. It really, really needs it.
Thank you for taking your time to share your thoughts. You are not alone. And as I said the right people in Nottingham will read your post.
 

Oh, I would love to see a proper modernized After Effects alternative. I am surprised no-one has developed it yet, because nothing really comparable to After Effects exists on the market; it would be a successful product if someone would.

Some confusion regarding web resolution, PPI/DPI, how to prepare for the web, and such.
DPI is completely irrelevant for web and screen (mobile/tablet/desktop) work. Forget about DPI or PPI. It tells nothing about the actual resolution of a file. 1 pixel can be saved at 50000ppi, and a million pixels at 1ppi. It is merely a parameter that tells print software at what relative size it should be printed.
  Technically DPI is the wrong term in Affinity's dialogs. PPI (Pixels Per Inch) is the correct term.
  For web/screen export, think PIXELS. When designing for screen output only pixels count. Forget PPI! Screen tech and software ignores that parameter.
  In the early BFP (Before Flat Panels) resolution of screens was more or less related to the size of those screens. The larger the CRT screen, the higher the possible resolution. 1 pixel equated to 1 pixel. I was very simple to calculate the required resolution/pixel dimensions of an asset for a web page: just export at the exact pixel size required.
For example, if a logo had to be placed at 600px by 100px, that is what you exported and prepared it at. PPI was (and still is) entirely irrelevant.
  Things changed quite a bit AFP (After the introduction of flat screen technology). No longer can we relate the physical size of a screen to its physical pixel resolution.
The first iPad had a 1024x768 resolution. The iPad 3 introduced the retina screen, which offers double that: 2048x1536. The screen size did, however, not change.
Nowadays much smaller screens than an iPad screen are capable of displaying higher resolutions than that.
  Desktop screens display 4K or even 8K now, but the actual physical dimensions of those screens are similar or the same as the previous generations.
  This poses a problem to screen/web designers: at what pixel dimensions should assets be produced?
To solve this problem the concept of MULTIPLIERS was introduced by screen designers.
  The multiplier tells the designer at what pixel dimensions a bitmap asset should be exported. The goal is to hit the native pixel resolution/dimensions for each targeted platform/screen (or close to that resolution).
Example iPad 1: assets are exported at the native resolution (related to 1024x768 pixel screen). We prepare @1x: 600px by 100px.
Example iPad >3: this is a device for which we prepare @2x assets: 1200px by 200px
Result: we deliver two assets when our target platform is the regular iPad.
  For web export, at least @1x and @2x assets are required. When using the correct responsive <img> tag code, a browser will load up the correct version depending on whether the screen it is viewed at is retina or not.
At this point the screen designer must realize that only providing a @1x asset will result in fuzzy looking bitmap graphics on a retina screen.
  But many handheld devices have far higher PPI resolutions (recall that PPI tells us about the relationship between the screen size and the native screen resolution). Very small screens at incredible high resolutions. @3x, @4x, and even @5x.
How do we figure out the multipliers?
Answer: we check the configurations, and calculate the multiplier. Luckily, someone already did this for us:
https://material.io/resources/devices/
  This means that BEFORE designing any bitmap screen asset, the designer MUST decide what the highest target multiplier must be.
And create the bitmap asset at that highest resolution.
  At this point a "pixel" as a unit is unsuitable as a base unit when discussing the dimensions of a bitmap asset. Therefore, DP and PT units were introduced. DP ("dip"(s)) is a Google coined 'unit'. PT (point(s)) is Apple's preferred 'unit'.
  Example: We need to prepare a 600px *100px bitmap asset. When we communicate this to our fellow designers and developers, we no longer use pixels, but either dips or points. 600dp/pt by 100dp/pt.
Next, we must decide on the highest multiplier: with @3x we target most devices right now.
We then define the highest resolution with the formula 3x600 and 3x100.
We create a new document at 1800px by 300px, and work at this base resolution.
This is required for all our assets in this project.
  When the final asset is to be delivered, export all multiplier versions with a standardized prefix or suffix which indicates the multiplier.
In our example above, that means three bitmap assets: logo.png, logo@2x.png, logo@3x.png

   

Other recommendations:
if possible, export as vector SVG files. In this case there is no need to worry about multipliers. Do make sure the SVG code is responsive, and automatically scales up and down in a HTML tag container.
  Even better, if you deal with GUI elements, work with the built-in framework GUI options. For example, instead of exporting that flat button design as a bitmap, use SVG. But if that same button design can be replicated using HTML and CSS styling code, definitely run with that last option.
Built-in GUI components tops SVG which tops bitmaps.
  If it can be helped, never use JPG for sharp looking text, line art, logos, vector work, etc. JPG works well for photos and multi-tone images, but visibly degrades those aforementioned types of graphics due to the lossy compression algorithm
  Instead, use PNG. If your work consists of less than ~256 colours and tints, indexed PNG files are preferable and save file space. The best way to compress a PNG is worth an entire post by itself. Suffice to say, to best compress and optimize PNG files dedicated tools are required. Image editors are not that great at it. I use ColorQuantizer, which is (in my opinion) the best PNG optimization tool currently available. Only for Windows, though. But worth it and free! http://x128.ho.ua/color-quantizer.html
  WebP is also excellent for both photos as well as sharp non-lossy assets (WebP support both lossy and non-lossy), and supported by all major browsers now. Except, of course, Apple. Safari does not support it. 😞 Neither does Affinity, which only opens these files, but does not export to webp.  
@Ali1 Your original issue has to do with attempting to export a 600x100 px asset "as is" from a vector package. In my experience there is just NO chance to get a good quality acceptable result, even in Illustrator. This is caused by a couple of things, such as non-decimal positioning, which adds unwanted soft anti-aliasing to the edges.
What works well to maintain high-quality sharp looking anti-aliased low resolution assets are the following steps:
work at a 3 to 4 times higher resolution. export at that bitmap resolution. Optional: perform some pre-downscale sharpening. open the result in an image editor like Affinity Photo, and scale down to the required lower resolution. Optional: perform some post-downscale sharpening. the result will be much better looking. Ideally use a downsampling algorithm such as Catmull-Rom. This works extremely well to maintain sharp details. Unfortunately, most image editors do not support this.
Of course, if you are already working at a @3x or @4x multiplier, the above steps generally are not required, because your base resolution is already very high. But it depends a bit on the image editor: the only way to check for quality is to go though the above steps at least one time, and compare your manually exported version with the automatic ones.

Other recommendations:
if possible, export as vector SVG files. In this case there is no need to worry about multipliers. Do make sure the SVG code is responsive, and automatically scales up and down in a HTML tag container.
  Even better, if you deal with GUI elements, work with the built-in framework GUI options. For example, instead of exporting that flat button design as a bitmap, use SVG. But if that same button design can be replicated using HTML and CSS styling code, definitely run with that last option.
Built-in GUI components tops SVG which tops bitmaps.
  If it can be helped, never use JPG for sharp looking text, line art, logos, vector work, etc. JPG works well for photos and multi-tone images, but visibly degrades those aforementioned types of graphics due to the lossy compression algorithm
  Instead, use PNG. If your work consists of less than ~256 colours and tints, indexed PNG files are preferable and save file space. The best way to compress a PNG is worth an entire post by itself. Suffice to say, to best compress and optimize PNG files dedicated tools are required. Image editors are not that great at it. I use ColorQuantizer, which is (in my opinion) the best PNG optimization tool currently available. Only for Windows, though. But worth it and free! http://x128.ho.ua/color-quantizer.html
  WebP is also excellent for both photos as well as sharp non-lossy assets (WebP support both lossy and non-lossy), and supported by all major browsers now. Except, of course, Apple. Safari does not support it. 😞 Neither does Affinity, which only opens these files, but does not export to webp.  
@Ali1 Your original issue has to do with attempting to export a 600x100 px asset "as is" from a vector package. In my experience there is just NO chance to get a good quality acceptable result, even in Illustrator. This is caused by a couple of things, such as non-decimal positioning, which adds unwanted soft anti-aliasing to the edges.
What works well to maintain high-quality sharp looking anti-aliased low resolution assets are the following steps:
work at a 3 to 4 times higher resolution. export at that bitmap resolution. Optional: perform some pre-downscale sharpening. open the result in an image editor like Affinity Photo, and scale down to the required lower resolution. Optional: perform some post-downscale sharpening. the result will be much better looking. Ideally use a downsampling algorithm such as Catmull-Rom. This works extremely well to maintain sharp details. Unfortunately, most image editors do not support this.
Of course, if you are already working at a @3x or @4x multiplier, the above steps generally are not required, because your base resolution is already very high. But it depends a bit on the image editor: the only way to check for quality is to go though the above steps at least one time, and compare your manually exported version with the automatic ones.

Some confusion regarding web resolution, PPI/DPI, how to prepare for the web, and such.
DPI is completely irrelevant for web and screen (mobile/tablet/desktop) work. Forget about DPI or PPI. It tells nothing about the actual resolution of a file. 1 pixel can be saved at 50000ppi, and a million pixels at 1ppi. It is merely a parameter that tells print software at what relative size it should be printed.
  Technically DPI is the wrong term in Affinity's dialogs. PPI (Pixels Per Inch) is the correct term.
  For web/screen export, think PIXELS. When designing for screen output only pixels count. Forget PPI! Screen tech and software ignores that parameter.
  In the early BFP (Before Flat Panels) resolution of screens was more or less related to the size of those screens. The larger the CRT screen, the higher the possible resolution. 1 pixel equated to 1 pixel. I was very simple to calculate the required resolution/pixel dimensions of an asset for a web page: just export at the exact pixel size required.
For example, if a logo had to be placed at 600px by 100px, that is what you exported and prepared it at. PPI was (and still is) entirely irrelevant.
  Things changed quite a bit AFP (After the introduction of flat screen technology). No longer can we relate the physical size of a screen to its physical pixel resolution.
The first iPad had a 1024x768 resolution. The iPad 3 introduced the retina screen, which offers double that: 2048x1536. The screen size did, however, not change.
Nowadays much smaller screens than an iPad screen are capable of displaying higher resolutions than that.
  Desktop screens display 4K or even 8K now, but the actual physical dimensions of those screens are similar or the same as the previous generations.
  This poses a problem to screen/web designers: at what pixel dimensions should assets be produced?
To solve this problem the concept of MULTIPLIERS was introduced by screen designers.
  The multiplier tells the designer at what pixel dimensions a bitmap asset should be exported. The goal is to hit the native pixel resolution/dimensions for each targeted platform/screen (or close to that resolution).
Example iPad 1: assets are exported at the native resolution (related to 1024x768 pixel screen). We prepare @1x: 600px by 100px.
Example iPad >3: this is a device for which we prepare @2x assets: 1200px by 200px
Result: we deliver two assets when our target platform is the regular iPad.
  For web export, at least @1x and @2x assets are required. When using the correct responsive <img> tag code, a browser will load up the correct version depending on whether the screen it is viewed at is retina or not.
At this point the screen designer must realize that only providing a @1x asset will result in fuzzy looking bitmap graphics on a retina screen.
  But many handheld devices have far higher PPI resolutions (recall that PPI tells us about the relationship between the screen size and the native screen resolution). Very small screens at incredible high resolutions. @3x, @4x, and even @5x.
How do we figure out the multipliers?
Answer: we check the configurations, and calculate the multiplier. Luckily, someone already did this for us:
https://material.io/resources/devices/
  This means that BEFORE designing any bitmap screen asset, the designer MUST decide what the highest target multiplier must be.
And create the bitmap asset at that highest resolution.
  At this point a "pixel" as a unit is unsuitable as a base unit when discussing the dimensions of a bitmap asset. Therefore, DP and PT units were introduced. DP ("dip"(s)) is a Google coined 'unit'. PT (point(s)) is Apple's preferred 'unit'.
  Example: We need to prepare a 600px *100px bitmap asset. When we communicate this to our fellow designers and developers, we no longer use pixels, but either dips or points. 600dp/pt by 100dp/pt.
Next, we must decide on the highest multiplier: with @3x we target most devices right now.
We then define the highest resolution with the formula 3x600 and 3x100.
We create a new document at 1800px by 300px, and work at this base resolution.
This is required for all our assets in this project.
  When the final asset is to be delivered, export all multiplier versions with a standardized prefix or suffix which indicates the multiplier.
In our example above, that means three bitmap assets: logo.png, logo@2x.png, logo@3x.png

   

Couple of things to consider:
- Photo has no quick method to warp objects by dragging only one corner point (CTRL-T Free Transform in Photoshop equivalent is missing). This is quite frustrating for this type of work. I speak from experience.
- Photo does not support 1bit high resolution inked art. This means you must work at 1200ppi and full RGB, and later convert in other software. Unsure whether 1.9 will have 1bit TIFF export to at least work around this hefty limitation for comic related work.
- as far as I am aware there are no non-destructive booleans/compound paths option in either Photo or Publisher. Only in Designer. This does impede the workflow somewhat in this case. Ideally the balloon and tail should be able to be positioned separately. This can be achieved in Designer, though.
- You may want to place your ink work in Designer, or use Publisher to layout your comic as a comic book. But both will convert your 1bit inks to RGB or CMYK when exporting to PDF. If you are relying on high resolution inks to be overlaid on top of multi-tone colour work, Affinity cannot accommodate that workflow at this time. Perhaps with 1.9? Unknown at this time. If you work with high-res 1bit inks, this makes it impossible to work with Affinity and (semi)professional comic publishing work at this point of time.
Disregard all this if you have no idea what I am talking about or you are not interested in actually printing your comic, and only mean to release it on the web or digitally. In that case you are probably working at RGB 300ppi anyway, even when inking. The result will be lacklustre when printed, but for web work it is fine.
 

Wait: you embarked on a full publishing project in Affinity Publisher and did not check whether epub export is possible before doing so? And you knew in advance epub export is required (Ingram Spark clearly states what is required for upload)? How could you NOT check for epub export?
Anyway, there is perhaps a solution.
1) use a conversion service such as magicepub.
Free to register and try the service. It will watermark images, but at least you can try the service before paying for the conversion (which is a couple of euros per conversion).
But this service merely converts either all pages to images, or embedded SVG files. I found the img + text conversion to be lacking, and it will need manual intervention.
So, since a service like magicepub needs to convert your complex layouts to either flattened images or SVG, why not do it yourself?
2) convert all your pages to SVG, and use an epub editor like Sigil to create a epub3 fixed layout file. Place each SVG on its own page. Save the epub.
Or if you want to publish on Amazon, export as PDF, and then use Kindle Creator to create the KPF file. Creator includes a TOC, and converts the entire thing to SVG as well.
The advantage of SVG is that text and vectors will be rendered at high quality. Converting the entire page to a JPG obviously results in a fuzzy looking text, and is probably something you want to avoid. PNG works much better, but may blow up the file to unacceptable file sizes.
There are many online PDF to epub convertors online, although the quality of conversion varies. I prefer to keep the conversion process under full manual control, so generally for complex fixed layouts I will use SVGs and place those in Sigil. 
 

In my mind bitmap layers should never ever be affected by non-decimal movement/placement. Bitmap pixel information must be maintained, and Affinity's behaviour is somewhat unacceptable. The user should not be forced to turn on pixel alignment to prevent the blurring of bitmap information.
With vectors and text this behaviour is understandable, and it is correct to have adjustable options how to render the pixels.  Not when editing bitmap layers, however. Pixels must be absolute, and not be affected by such settings.
Pixel alignment ought to be the 'default' behaviour, just as it is in pretty much any other image editor.

That does not matter for the user experience: in Photo the default behaviour ought to be that pixel alignment is always on for bitmap layers.

In my mind bitmap layers should never ever be affected by non-decimal movement/placement. Bitmap pixel information must be maintained, and Affinity's behaviour is somewhat unacceptable. The user should not be forced to turn on pixel alignment to prevent the blurring of bitmap information.
With vectors and text this behaviour is understandable, and it is correct to have adjustable options how to render the pixels.  Not when editing bitmap layers, however. Pixels must be absolute, and not be affected by such settings.
Pixel alignment ought to be the 'default' behaviour, just as it is in pretty much any other image editor.

Krita is not a general purpose image editor, and aimed at digital painting. It wipes the floor with Affinity Photo in this respect (even Photoshop cannot keep up with painting in Krita), and Krita is widely in use by many professional digital illustrators.
Apples and oranges.

Now, that: ....is interesting, to say the very least. It actually looks amazing - if you guys get that up to a Substance Painter level of quality, you will gain the support of, and an influx of, a great number of game artists. 

Hi again,
Further to the other things, we are looking to add more support for game art users - can't promise this for 1.9 but we are working on it..
 

 
(I have two documents open here - you can see the texture itself, the other document is the normal map - both are being edited and a realtime preview is being rendered on a .obj model in the new Model panel).
Thanks,
Andy.
 

Now, that: ....is interesting, to say the very least. It actually looks amazing - if you guys get that up to a Substance Painter level of quality, you will gain the support of, and an influx of, a great number of game artists. 

Hi,
I'm pleased to report that we have implemented the Divide blend mode for Photo 1.9, which will enter beta in a few weeks time.
Thanks,
Andy.

Hi,
I'm pleased to say that we have implemented precise adjustment of curves using input / output values and it will become available in Photo 1.9 (which will go into beta in a few weeks).
Thanks,
Andy.