Medical Officer Bones

PS I get the best anti-aliasing quality at 2416x2416px when I export the initial 3333px version as a PNG and scale it down to 2416px using Catmul-Rom in Color Quantizer. Most software will not allow for Catmul-Rom as a downsampling algorithm, though. The file size is increased which is a sign of more (useful) information, which is again a sign of that particular downsampling algorithm preserving details better than a straight vector to bitmap conversion at 2416px. In particular the red lines of Tomas Road look much less jagged, and details stand out more (check the red dot at "such and such is located here").

All four PNG files have vastly different resolutions! The first one is 800x800 (no transparency), the second one is twice as high at 1600x1600 and has a transparent background, the third one (Graphics) is 2416x2414px without transparency... Nothing can be compared here. They all look good to me on a white background, but obviously the second AD version looks not as crisp as the third one, since that third one was exported at a much higher resolution. And the second one (AD with a transparent background) might not look as good DUE to the transparency when viewed interpolated zoomed out. Depends on the viewing software (in my experience some viewing software doesn't do transparency justice in regards to quality). So be sure to export with a white background. Viewing the second one at the same scale as the third one on a retina screen will result in a more blurred version in the case of #2, of course. Not a fair comparison either. Here is your eps file exported from Affinity Photo at 2416x2416px. I really can't notice any difference compared with your #3. Affinity's version is also smaller in file size. Are you sure you have a firm grasp of the concepts of DPI, print size and (true) pixel resolution, and how these relate to each-other? I mean this in the best way, so if you do, forget I asked. Anyway, DPI is completely irrelevant in this discussion: only pixels count. You MUST export all variants from all applications at IDENTICAL pixel resolutions (and I do NOT mean DPI!).

Here is a better example of PNG export comparison issues popping up when comparing the PNG output of these applications. P_Dinosaurs.svg I exported this SVG file in Photo, Photoshop, and PhotoLine as a 'pure' 24bit PNG file @ 800x720px. Result: Photo: 396kb Photoshop: 286kb PhotoLine: 423kb You'd think "Well, Photoshop is the clear winner!", right? Not so fast. As it turns out, Photoshop's version contains 2063 unique colours, while Photo has 3829 colours, and PhotoLine's version tops out at 4285 colours. So that means PhotoLine's version arguably retains the most fidelity (or uses softer anti-aliasing), but in practice the user won't be able to discern any visual differences between these three versions. All of these were saved as 24bit +alpha, so why the large differences? Depends on the algorithm each app uses to decide which colours to keep, and which to throw away. I have no idea. No clue. Up to the developers. If we'd be discussing a source bitmap the differences would probably be negligible. But in this case a vector file is to be processed, and each image editor's built-in conversion routines will have an impact on the final conversion. In short, "losless" loses its meaning when dealing with vector file conversion. It depends on the software used and the routines at work. The compression/processing algorithm can have a tremendous impact on final file size on top of that first vector to bitmap conversion. That same 4285 colours version was reduced to 281kb after processing it with Color Quantizer, and saving it as true color. CQ will create a palettized version of 4285 colours, resulting in no quality loss, yet a significantly smaller file size while maintaining more colours than either the Photo or Photoshop version. It's all about the compression and processing stage at this point. @SrPx Indeed, dithering may have a large impact on palettized images too. in this case I refrained from converting to a 8bit version, because it will open a whole new can of worms, in particular seeing that so many different dithering patterns may be used. A regular pattern compresses better than a stochastic one. The results can be inspected down below. I didn't check for meta data, but I turned it off for all, I believe. Visually no-one will be able to see the difference. Affinity: Photoshop: PhotoLine: Color Quantizer based on PhotoLine's high-colour version:

@haakoo Ah, right, sorry about that. SrPx is correct: too many unknown variables at work here, and until we have an actual sample file that demonstrates the problem unequivocally, nothing can be solved or anything useful stated. I did a quick comparison between Affinity Photo, Photoshop, and PhotoLine, and 24bit exports are pretty much similar in export size and quality, barring the included meta data. With Color Quantizer I obviously am able to achieve smaller file sizes at 24bit, as it is a specialized PNG optimization tool, but no surprising results. When I saved as 8bit palettized files, I was a bit surprised to see that Affinity Photo did not reach the same low file size as the other two, though. A rather large discrepancy which I can't explain yet, so I will investigate further.

@haakoo PDF retains all the vectors, and this would blow the file up (depending on the complexity of the graphic), so it should never be compared to a bitmap file format such as PNG. It's just not useful in any way. And depending on the settings, a non-compressed bitmap may be saved in a PDF as well. Too many variables at work there for reliable comparisons. Comparing the SVG output to a PNG output would be more practical, since depending on the graphic it would yield lower file sizes for one or the other format, and also SVG is obviously resolution independent for web page and app development. An informed decision can then be made which file to use. By the way, 300dpi tells us nothing: 1 pixel can be saved as 300 dpi, and it is merely a parameter used in print to decide how a pixel should be treated when printed. Always mention pixel dimensions when comparing.

Comparing a PDF with a PNG is like comparing apples and oranges. If the vector file is very complex, it will create a large PDF file (because the vectors remain vector, and all the original path data is retained) and a 800x800px PNG file could result in a very small file size. But it all depends on the complexity of the original file. You should not base any file size assumptions on such basis. It makes no sense. Are you exporting the PNG file at the same pixel size? What is the pixel size? Is it 800x800px? Are the PNG files you exported from Affinity and the lower grade tool you mentioned equal pixel size? Are they both 24bit?

@owenr Thanks! I had tried it with another file, and assumed the fill command worked differently. Thanks for the help.

@firstdefence Yes, that seems to be the case. It's quite a basic function, so I hope the devs will implement it at some point in the future. For those who need an example, here's a file that demonstrates the problem: When the transparency/alpha is transferred to a layer mask (or removed) this image pops up: If someone happens to stumble on a method to accomplish this in Affinity Photo, I'd be grateful. ps just noticed that in PhotoLine the brush tool can work directly with the alpha channel, and I can undelete the hidden parts of the image by painting over the transparent areas as well.

That was one of the things I tried, but to no avail: the original layer's transparency/alpha is maintained. But your answer did motivate me to look once again, and I found a method/workaround: 1) switch to the channels panel, and right-click on the Pixel Alpha to create a new mask layer. 2) select the original layer and use the pixel alpha's Fill command to fill the alpha with pixels. However, it is only a partial solution: I'd like to display the original pixel data.

Does anyone happen to know of an equivalent of Photoshop's "Layer Mask from Transparency" function in Affinity Photo? It converts the transparency of a layer to a layer mask, and removes the transparency from the original layer. In PhotoLine this is achieved by creating a new layer mask based on alpha. In Gimp there's the option to transfer a layer's alpha channel to a layer mask when a new layer mask is added to a layer with transparency. To be clear, this function removes the transparency from the original layer, and transfers the alpha channel data to a layer mask. It's a very basic option, and ought to be possible somehow in Affinity Photo, but so far I haven't been able to figure out how to accomplish this. Help is very much appreciated: I've been fiddling around for an hour now, and it's probably so obvious that I am looking past it.

Weird. In other image editors with advanced layer blending options the simple solution in this case is just to target the gray channel and slide the gray top slider to the left to remove the anti-aliased edge pixels until the edges become aliased. Quick and easy. But in Photo the Blend options work differently, and won't allow me to do this. I am somewhat surprised (not in a good way!) that this won't work in Photo. A gray channel target ought to be added in Photo too.

PS one thing Affinity's export persona should do, is a real-time preview. Come on, guys! Without a preview it's trial and error. Anyway, one of the major peeves I have with Photo at the moment, and why I just export to full quality PNG before processing further in other image editors and optimization tools. I just don't bother with Photo's export persona because of this.

I would agree that for specific purposes the PNG export could be much improved, but let's get down to Earth: no general-purpose image editor can beat specialized treatment via a dedicated image optimization tool such as Color Quantizer, and nor should that be an issue. If that level of control is required, the user will have access to that level of knowledge as well. Affinity's PNG export is fine compared to, for example, Photoshop. Photoshop doesn't even have a palletized option available to it compared to Affinity. As for JPG: not sure. Didn't do enough testing myself, but then again, I tend to stay away from jpg nowadays for my work, excepting the odd web dev job. Otherwise I'll just use either heavily optimized PNG or Webp files. And now that I mentioned Webp: i find it quite concerning that Affinity won't let me export to Webp. It's a great format for game and mobile development (I guess on Windows and Linux at least, because Apple seems to boycott the file format), and to me it's a crying shame a modern image editor like Photo won't support it. Worse, it DOES import Webp file, but won't allow me to save the same file as Webp? Silly. And very short-sighted, in my opinion. As short-sighted as Adobe in this case. Luckily PhotoLine has no such problem, and exports via its visual web export to Webp.

Unfortunately, at this point in time Designer does not support vector patterns. They have been requested many times before, and this feature is on the roadmap, but no fixed date when these will have been implemented is given to us.

In Affinity Photo a similar function is available, but only to remove white (or black when the image is inverted first). You'll find it in Filters-->Colors-->Erase White Paper. It is, however, quite limited compared to PhotoLine's Color to Transparency function in regards to options and control, and in Affinity this is a destructive filter (PhotoLine's version of this filter is non-destructive and can be stacked, if required).

If it's meant for app development, your development environment/language/API which you use may support Webp as an image format. Webp compresses both lossless and lossy, and compared to JPG results in much lower file sizes versus identical (or better) quality. And supports alpha transparency even when lossy compression is used. I use Webp instead of jpg for that kind of work nowadays.

True, although the RIOT version included is an older version and does not include the masking and meta data controls (at least, I believe it does - unsure). Irfanview: 0.4.6 versus the newer 0.6.0 (beta)

Oops, just realized this is a thread about JPG compression... Still, good information. A good tool for JPG optimization is RIOT (Windows only again I'm afraid), but the installation comes with adware and only the portable version should be downloaded and used. The advantage of RIOT is the option to control Chroma subsampling, which is generally not a parameter which can be controlled in image editors. Affinity Photo lacks such a setting, which is a bit of a shame. RIOT also offers good control over metadata (what to keep, and what to throw away). https://luci.criosweb.ro/riot/download/ WARNING: ONLY download the portable version! The installer includes adware!

THE ABSOLUTE best (not kidding here) PNG optimization and processing tool that I know of is Color Quantizer. Best kept secret of PNG optimization tools. One of the unique aspects of this small but wonderful utility is an easy to use quality mask brush, which allows for precise colour optimization control. It can create palettized colour ranges from 2 to anything, really. No 2-256 limitations. Also perfect for downsampling and dithering: 8 different dithering methods, as well as 16(!) different resampling methods. Full control over alpha optimization parameters, color space and visual perception, dither amount, and so on, and so forth. And full indexed colour palette control. And all with a very good preview: any change made is updated in the preview, with a nice zoom view to see the results in detail while you work. Instead of a side-by-side view the user clicks the view to compare the original with the optimized version. Get it here: http://x128.ho.ua/color-quantizer.html NOTHING else comes close to this level of PNG generation control and ease of use. The only drawback is that Mac users will have to use WINE to use it, because a Mac version is not available. But it is THAT good, that no-one even remotely interested in working with PNG files for web, mobile dev and game assets should be without.

@Al Grasso Please back up your words with actual examples. Upload sample images for us to compare.

Sorry, my mistake: what I meant was palettized PNG-24 beyond the 2-256 range. For example, restrict the palette to 512 colours. But without the ability to preview the effect of settings while these are changed really makes it a moot 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.

It's pretty pronounced in the demo file. I tried to rasterize it, add a layer effect to force it to resample, etc. The only method I found that improves the quality is to apply the perpective filter at a higher resolution (initially avoiding downscaling to a small version), then scale down the screenshot (and rasterize if necessary). But even then there are still some remaining anti-aliasing issues. All of this seems to point at less-than-ideal re-sampling algorithms when down-scaling layers for lower resolution screen work.

@owenr I re-uploaded the file. Can you try again?

Here is the screenshot Photo file for others to compare. Live Perspective filter is used, so free free to try to improve the result. screenshot.afphoto