Medical Officer Bones

Sure, whatever works. I prefer Opera since it is installed on my local machine, and I can't be uploading licensed (client) work to an online service like that. I need to be able to maintain control over the files.

Well, the Opera browser is a free and safe browser. I use it quite regularly to convert SVG files to PDF (not so much for browsing, funnily enough).

Did some testing, and in other applications scaling up with Bicubic Spline results in an even nicer/usable scaled up version than your Photoshop version. Unfortunately, Affinity Photo doesn't give the user a choice in resampling algorithms when upscaling and rasterizing a specific layer. I then attempted to upscale the original with the Resize Document option, and selected Bicubic as the resampling method. The result leaves a LOT to be desired of compared to any of the other apps I tested in (Krita, PhotoLine, Gimp). In my opinion, based on my previous experiments with downscaling assets, and now with this particular upscale example, Affinity's resampling code base needs to be looked at again. It is a quite fundamental thing to get right. If other applications have no issues with up- and down-scaling, my only conclusion can be that something is amiss with Affinity's basic approach in resampling. The choices of resample methods in the preferences and document size dialog are fairly limited as well. For downsampling, for example, Lanczos and Bicubic are far from ideal choices, but no alternatives such as CatmulRom or MitchelNetravali are on offer in Photo. As it stands, Photo is lagging behind all the competition in this area. Let's hope the devs will address this in an upcoming release, because it needs to be.

Open troublesome SVG files in the Opera browser, right-mouse click the SVG, and save as PDF. Then open the PDF in Affinity.

Still, aside from the OP's perceived age of Photoshop CS6, the complaint of the OP still stands. It is an awkward and convoluted process in Photo to work pixel-precise this way.

And for those of you who doubt the veracity of option (1)'s usefulness, consider this situation: suppose an asset needs an exact white margin defined. Like the OP, we add guides that define the exact size of the asset first. Then we precisely calculate and place additional guides to set the margins. (Photo's inability to change the ruler origin irritates us while working on this last step.) Then we crop the canvas according to the outside trim guides. Result: the inside margin guides move (or completely disappear when working on a larger canvas). This is unwanted behaviour, of course. We defined those inner guides to remind us of the exact margins, and may have need of those at a later stage in our workflow. But they moved, rendering our preparation phase useless. Just a simple example of why option (1) is actually preferable over (3) as a default behaviour. If anything, Affinity Photo ought to behave like (4). Or (1) - better, the choice between the two.

The behaviour of guides after changing the document or image size in design applications fall broadly in four main categories: existing guides remain in place (what the OP expected to happen): Inkscape, Gravit Designer, Photoshop, Photoline, Xara Designer Pro; existing guides automatically adjust relatively to the new page size. A column grid based on guides will automatically narrow down to accommodate a smaller width canvas: InDesign, PhotoLine with formulaic %-based guides, Xara Designer Pro with Auto-fit, Affinity Photo with percentages; existing guides will move in absolute units in relation to the top left origin of the canvas (Affinity Photo, Krita); existing guides will move in absolute units but in four, three, two canvas edges or a single canvas edge (PhotoLine with px-based guide formulas) ...and a very few design apps allow for a combination of above methods (PhotoLine for example). I believe InDesign has multiple options as well. (1) has its uses. (2) is incredibly handy to have, for obvious reasons. (3) is only useful when guides need to move from the left top origin only. (4) is a much better variant of (3), because the size of absolute margins defined by guides, for example, would be retained on all or defined sides of the new canvas size. Having options (1), (2), and (4) in an design app come in handy for most practical situations in my experience. Affinity Photo supports (3) and (2). (2) is very nice, of course. In my opinion (3) is not that useful to have, because existing guides used as an absolute measure device will move after resizing a canvas and move into one direction only. Both (1) and (4) would be preferable as an available user choice. As far as I am aware only Krita and Affinity Photo (Designer too?) behave like (3) without an option to define absolutely positioned guides relative to all canvas edges or a selection of these. Anyway, I'd like to see more control over how guides behave in Photo in the future. (1) is very handy to have, actually.

@SrPx Blender is slowly making ways into larger VFX and Animation studios as well. Just look at Tangent Animation's NexGen, and all the work done by Barnstorm VFX on primetime shows (both are Blender-based studios). Something unthinkable only 7 years ago. But yeah, if you are planning a career on current job requirements in the animation industry, Maya still rules. Houdini is more or less required for many VFX jobs too. As a freelancer or Indie outfit/small team I'd say go Blender all out - which is already the case anyway with many game devs.

Yes, this is one of those cases where anti-aliasing wreaks havoc with the result, and Affinity Photo does not have an option to automatically render all objects to the pixel grid automatically. Yes, there's Force Pixel Alignment, but a 1 pixel line will have to be placed exactly at 0.5 - which is a bit ridiculous to ask of the user. Other design apps solve this with a simple document wide or even layer-specific pixel snapping that changes the rendered result on the fly. Not so in Photo, unfortunately. One of the many reasons why I think Affinity Photo is rather unsuitable for precise pixel work and pixel art. Another reason being the lack of a simple document-wide option to turn off anti-aliasing. And the Coverage Map work-around is a half-baked one. [ On a side note, I found that it is often the simple basic things which require all sorts of convoluted hacks and work-arounds in Photo. That is why I mainly use it for HDR merging, stacking, and sometimes panoramas, and then export the result to continue work in other image editors. Of course, this is my personal experience, and a bit of a shame. Basic workflow foundations in Photo are quite shaky. ]

Please refer to this thread: A similar import issue affects Publisher: 16bpc greyscale TIFF images are imported washed out and too bright. My hypothesis is that the Affinity developer team never tested such files before. This should be resolved. InDesign and Scribus import these files without any issues.

A quick test of importing your 16bit greyscale TIFF file reveals that Photo indeed cannot open it correctly - or at least, Photo assumes it is dealing with a RAW file. I also tested Krita, PhotoLine, InDesign, Xara Designer Pro, IrfanView, even OpenToonz (animation app), Scribus, and finally Affinity Publisher. All applications load up your file without any issues, excepting both Affinity products. Even Affinity Publisher loads it incorrectly (too bright and washed out). This leads me to believe that the Affinity developers have never tested actual 16bpc greyscale TIFF files while developing the import filters. I would call this a bit of an oversight (which is an understatement of rather planetary proportions). The 16bpc PNG version loads up correctly, though. I would suggest that if you intend to use Photo for your image processing, you scan and save directly to 16bpc PNG files instead of greyscale 16bpc TIFF files.

Initially I expected "Erase White Paper" to work here (found in the FIlters-->Colors menu, but Affinity Photo's won't leave the saturation alone, which results in semi-transparent colour fills. Sigh. Half-baked implementation compared to other apps, unfortunately. After applying the erase white paper effect, duplicate the layer four, five or seven times to restore the fills. Then merge those layers. (Merge visible). Or use the flood select tool, turn off "Contiguous" and click on the white background. Then hit the delete key. But it will leave white fringes, and Affinity defringe function for some reason won't deal with them.

This SVG file is quite problematic: I've opened it in various editors, and none open it completely correct. As stated, even Illustrator gets it wrong with that one leaf. Only the browsers process and render that file correctly. Quick tip for anyone not having access to Illustrator to fix a problematic SVG file: install the Opera browser (https://www.opera.com/) and open the SVG file in it. Right-mouse click the view, and choose "Save as PDF". This will fix all (or 99% of) issues. It depends on the PDF importer of your app whether the dark leaf will be imported correctly, though. Affinity Photo (and I am guessing Designer as well) do not support the soft dark mask that is required for the top right dark leaf. It is relatively easily fixed (just like in Illustrator) in Photo, though. I did some more testing for fun, and found that Krita, PhotoLine and Gravit Designer all deal differently with this SVG file as well - and the results are all over the place. Krita's version sort-of explodes. :-) After converting the file to PDF with Opera, all applications, including InDesign (which does not support SVG files) import it correctly, excepting the dark leaf at the top right. Every single application I tried the PDF with gets that top right leaf wrong, but for PhotoLine which (surprisingly) is the only app among the ones that I tested which gets it right. That particular leaf is created with a hollow shadow mask that is misinterpreted or unsupported by most of the design software. Interestingly enough when I re-save the PDF version in PhotoLine, it corrects this error, and all other applications then import the pdf without any visual issues, and the leaf mask issue is resolved. At the expense of editability, unfortunately. Sigh, can't have it all, I guess. Resaving the file from PhotoLine as an SVG and importing the result in Affinity also works well, although that darn leaf still refuses to be shaded correctly. I checked the result and that leaf's shading is rather complex, which would explain why most software seems to choke on it. They all, expect the browsers and PhotoLine after conversion to PDF, miss that transparent image overlay with the soft shading mask. Check it out below. Anyway, in short: use Opera to save a PDF version, and it will work fine (excepting that darn leaf) in Affinity. PS Xara Designer Pro and Gravit Designer both import the SVG with mixed results, both rendering it incorrectly. As mentioned by the OP, Inkscape's SVG import results in a weird translucent version, but Inkscape does import the PhotoLine SVG re-saved version without issues, though. Neither Xara nor Gravit support PDF, however, so no go for those two.

@>|< Corrected. Although this still doesn't solve the issue when zooming in.

You are right, I corrected this in my answer. But any value over 100% that is not a multiple of 100 results in badly jagged edges in the viewport. That ought to be addressed.