No smooth contour.

[LondonSquirrel]

1 minute ago, R C-R said:

I suppose I need to install the developer tools for that to work?

Ah yes, you are probably right. I will save you the trouble and offer an explanation (for those who don't know):

strings liblibpng.dylib | grep version
libpng version 1.6.5 - September 14, 2013
 libpng version 1.6.5 - September 14, 2013
unsupported zlib version
ASCII conversion buffer too small
PNG file corrupted by ASCII conversion
 Testing libpng version %s
   with zlib   version %s
 libpng version 1.6.5 - September 14, 2013
Warning: versions are different between png.h and png.c
  png.h version: %s
  png.c version: %s
   and zlib version (%s)?

I'm interested only in the lines showing the libpng version. Ignore the 'unsupported|corrupted|too small|warning' lines - they are warnings for handling errors, they are not in themselves errors.

 

[R C-R]

10 minutes ago, LondonSquirrel said:

I'm interested only in the lines showing the libpng version.

So does "September 14, 2013" suggest this is an older version?

[LondonSquirrel]

4 minutes ago, R C-R said:

So does "September 14, 2013" suggest this is an older version?

It does indeed appear to be from 2013. By itself that does not mean the code is out of date, or that later versions of the code produce better output (the nub of this thread). One would have to go through the intermediate versions to see what has changed, and not just the last version (unless that has a list of all changes ever).

Some/many of the changes will have no effect at all on the output of files. e.g. from 1.6.37: 

• Fixed a typo in the libpng license v2. (Contributed by Miguel Ojeda)

• Added makefiles for AddressSanitizer-enabled builds.

[NotMyFault]

1 hour ago, LondonSquirrel said:

Affinity seems to use version 1.6.5 of libpng (http://libpng.org/pub/png/libpng.html - prepare yourself for the delights of a mid 1990s style web page). Beware and don't simply see the vulnerability alerts on the web page and say 'OMG, we're using a vulnerable version of libpng'.

This is the reference (i.e. 'official') version of PNG. It is quite an old version now and could probably do with an update. I don't know why Affinity is using this older version, perhaps they have good reasons. I could read all the change logs and see what is different. But there probably have been some changes and not just fixes (improvements?).

I don't know if Adobe uses libpng or wrote their own implementation. They certainly they have the capacity and experience to do that, and maybe they know that by adding the secret Adobe sauce they get better output.

Just for clarification: the PNG format has nothing to do with anti-aliasing. 

Anti-Aliasing is managed on per layer basis, within the document, unrelated to export. You can always choose "merge visible" (or flatten) to get 1:1 representation of what would be exported in any format. You could then copy/paste the flattened layer into Photoshop and export to PNG or any format.

Never the less, during, export, you can choose a resample method. This can influence the export, but again independent of export file type png tiff etc.

If your document is already flattened, and you do not change the resolution during export, the exported pixel data must 100% match what is in the canvas.

(Always assuming you are use consistent (export same as document) settings for color channel bit depth and color profile, e.g. RGB/8 and sRGB).

 

[LondonSquirrel]

11 minutes ago, NotMyFault said:

Just for clarification: the PNG format has nothing to do with anti-aliasing. 

Agreed.

[R C-R]

1 hour ago, NotMyFault said:

Just for clarification: the PNG format has nothing to do with anti-aliasing. 

Anti-Aliasing is managed on per layer basis, within the document, unrelated to export.

But can a PNG file have more than one layer?

[JIPJIP]

1 hour ago, R C-R said:

But can a PNG file have more than one layer?

@R C-R

Interresting :

I noticed this afternoon, that there is a step in my macro which kills sharpness of bicubic downsizing in affinity.

I know, this is not about vector to bitmap conversion, but, maybe there is some process related, look at the rest :

I found that bicubic downsizing alone is lot much better than when whole the macro is processed (I didn't noticed that before, but I'm still looking at this problem - I'm maybe old school but I can't tolerate major's behavior, so I search how to get rid of them).

What ruins the sharpness of the bicubic downsizing is when black pixel layer (for background) and downsized photo pixel layer are merged. (This does not happens with macro in cs6).

And what I noticed, is that after downsizing the largest side of my photo at the size of the square thumbnail side, the other side of my photo is not an integer number but a
decimal number (perfect precision). So what I suspect is that when layers are merging, an other kind of pixel sampling happens to stretch the decimal sized side to an integer value, and ruins the quality of the bicubic algorythm. Maybe cs6 is less fussy about precision and it's bicubic downsizing process round both sides to integers in one step. Or something like that.

 

So about converting vector to bitmap, maybe there is something of the same kind which involve rounding some values at the end of the process and sampling some very small offsets which ruins the final result. PNG doesn't have alpha channel ; I don't know how transparency is stored, but maybe it involved a kind of merging layers process which gives the same result as my macro. It would be interresting to check if the vector to bitmap conversion gives the same result with formats with alpha channels or a better result.

 

And for my case,  is there is a way to force downsizing operation to "snap" to integer pixel number and don't stick to decimal precision when aplying bicubic algorythm ?

 

[NotMyFault]

7 hours ago, R C-R said:

But can a PNG file have more than one layer?

For the scope of this thread, no.

 

[NotMyFault]

6 hours ago, JIPJIP said:

@R C-R

Interresting :

I noticed this afternoon, that there is a step in my macro which kills sharpness of bicubic downsizing in affinity.

I know, this is not about vector to bitmap conversion, but, maybe there is some process related, look at the rest :

I found that bicubic downsizing alone is lot much better than when whole the macro is processed (I didn't noticed that before, but I'm still looking at this problem - I'm maybe old school but I can't tolerate major's behavior, so I search how to get rid of them).

What ruins the sharpness of the bicubic downsizing is when black pixel layer (for background) and downsized photo pixel layer are merged. (This does not happens with macro in cs6).

And what I noticed, is that after downsizing the largest side of my photo at the size of the square thumbnail side, the other side of my photo is not an integer number but a
decimal number (perfect precision). So what I suspect is that when layers are merging, an other kind of pixel sampling happens to stretch the decimal sized side to an integer value, and ruins the quality of the bicubic algorythm. Maybe cs6 is less fussy about precision and it's bicubic downsizing process round both sides to integers in one step. Or something like that.

 

So about converting vector to bitmap, maybe there is something of the same kind which involve rounding some values at the end of the process and sampling some very small offsets which ruins the final result. PNG doesn't have alpha channel ; I don't know how transparency is stored, but maybe it involved a kind of merging layers process which gives the same result as my macro. It would be interresting to check if the vector to bitmap conversion gives the same result with formats with alpha channels or a better result.

 

And for my case,  is there is a way to force downsizing operation to "snap" to integer pixel number and don't stick to decimal precision when aplying bicubic algorythm ?

 

This leads to a completely different area of blurriness by resample, DPI mismatch, non-integer layer positions which has been discussed in full epic detail (to death) in other threads. Would you mind to stay on topic here and continue in one of those threads, or start a new one?

https://forum.affinity.serif.com/index.php?/search/&q=Merge down blurry&quick=1

[JIPJIP]

3 hours ago, NotMyFault said:

This leads to a completely different area of blurriness by resample, DPI mismatch, non-integer layer positions which has been discussed in full epic detail (to death) in other threads. Would you mind to stay on topic here and continue in one of those threads, or start a new one?

https://forum.affinity.serif.com/index.php?/search/&q=Merge down blurry&quick=1

Thanx for the link. Will look at it.

[Designer1]

@walt.farrell
@Alex M

@NotMyFaultYou can also get very good PNG export results if you make 600 dpi and then rasterise before exporting. So 1200 dpi is not necessarily required. The problem clearly lies in the non-smooth representation of vector graphics.

[R C-R]

4 hours ago, Designer1 said:

The problem clearly lies in the non-smooth representation of vector graphics.

Yes, that is an inherent problem in exporting vector objects to any raster image format! Raster image formats do not have an infinite number of pixels, which they would need to render representations of vector objects with perfect smoothness.

[JimmyJack]

FWIW (disclaimer, I did not read all 5 pages. But I'm assuming this is about straight output quality and not what happens when things are resized within Affinity products.)

This is my head to head comparison. Simple stroked vector circle (created in AD) exported to PNG in current AD and AI (not saying which is which atm).

If you guys say there's an appreciable difference I will leave you to your solutions. 🍻

[Old Bruce]

2 hours ago, JimmyJack said:

This is my head to head comparison. Simple stroked vector circle (created in AD) exported to PNG in current AD and AI (not saying which is which atm).

I like the one in the middle.

[User_783649]

@JimmyJack My Friday’s bet will be is that first one is AD.

[NotMyFault]

14 hours ago, JimmyJack said:

FWIW (disclaimer, I did not read all 5 pages. But I'm assuming this is about straight output quality and not what happens when things are resized within Affinity products.)

This is my head to head comparison. Simple stroked vector circle (created in AD) exported to PNG in current AD and AI (not saying which is which atm).

If you guys say there's an appreciable difference I will leave you to your solutions. 🍻

There is a minor difference in gamma used for AA. The left shows slightly darker AA pixels.

Could be caused by by gamma, or the stroke could be minimal different in size.

Can you please give the exact data of the circle (diameter or height /width, position of center point .0 or .5, stroke width in px) ?

Actually, it would be helpful to start with the identical SVG file and see how Aph IS render the same file for export.

[Designer1]

5 hours ago, NotMyFault said:

There is a minor difference in gamma used for AA. The left shows slightly darker AA pixels.

Could be caused by by gamma, or the stroke could be minimal different in size.

Can you please give the exact data of the circle (diameter or height /width, position of center point .0 or .5, stroke width in px) ?

Actually, it would be helpful to start with the identical SVG file and see how Aph IS render the same file for export.

It only makes sense to deal with this topic if an improvement in smoothing can be achieved. It is a real pity that you have to rasterise at 600 dpi or more before exporting. Even free Inkscape does export PNG with smoother contours.

[walt.farrell]

58 minutes ago, Designer1 said:

It only makes sense to deal with this topic if an improvement in smoothing can be achieved.

So far I don't think you have convinced anyone that the output from other applications shows an improvement. We can see that there is a difference, but that doesn't necessarily mean the others are better.

And until there is agreeement about the quality being better in the other applications, it is unlikely we'll convince Serif that they should invest in making changes to the Affinity applications. Once we have agreed, and gotten Serif to agree, there is a hope that sometime in the future they might implement changes to improve the Affinity applications' output.

[Designer1]

46 minutes ago, walt.farrell said:

So far I don't think you have convinced anyone that the output from other applications shows an improvement. We can see that there is a difference, but that doesn't necessarily mean the others are better.

And until there is agreeement about the quality being better in the other applications, it is unlikely we'll convince Serif that they should invest in making changes to the Affinity applications. Once we have agreed, and gotten Serif to agree, there is a hope that sometime in the future they might implement changes to improve the Affinity applications' output.

The best thing is to do a test yourself. Simply export the text or some words from affinity as PNG and from Illustrator or Corel and then compare the quality.

[walt.farrell]

8 minutes ago, Designer1 said:

The best thing is to do a test yourself. Simply export the text or some words from affinity as PNG and from Illustrator or Corel and then compare the quality.

First, I don't have Corel or Illustrator.

But, second, I don't care that they are different. Nothing you have shown so far convinces me that the Corel or Illustrator output is better, in any significant way.

[Old Bruce]

@Designer1,

I am going to steal most of Walt's statement. "Nothing you have shown so far convinces me that the Corel or Illustrator output is better."

[PaulEC]

I am trying to work out which of these is "better":

 

[Old Bruce]

8 minutes ago, PaulEC said:

I am trying to work out which of these is "better":

Red is better than Green. 

[kaffeeundsalz]

15 minutes ago, Designer1 said:

The best thing is to do a test yourself. Simply export the text or some words from affinity as PNG and from Illustrator or Corel and then compare the quality.

Please do such a test, post the export results here so we can compare them and throughly describe what exactly you think should convince us that the image quality is superior in other applications. You've taken the entire discussion this far, yet you never actually told us your definition of "better quality". Why?

[Designer1]

29 minutes ago, kaffeeundsalz said:

Please do such a test, post the export results here so we can compare them and throughly describe what exactly you think should convince us that the image quality is superior in other applications. You've taken the entire discussion this far, yet you never actually told us your definition of "better quality". Why?

Better quality is smooth and not, especially with round shapes, pixelated contours. I don't intend to convince anyone here either. I have simply reported the problem. It is up to Affinity Team to look into it now. I will not participate further in this discussion.