PNG filesize

[WtFrostyCakes]

Anyone know how to get XnView to make PNGs as small as ShareX's?
If I were to reprocess a ShareX PNG screenshot using XnView, the file size ends up being twice as big.
I tried setting PNG compression level to 9 and checked and unchecked all the other options to no avail.

[Edit] It seems to be mainly happening for black and white screenshots?

[helmut]

Welcome to the XnView forum and thank you for registering here, WtFrostyCakes. I guess the problem of the larger PNG files is a matter of the colour mode (RGB, 8bit, b/w) but I'm really guessing here. Could you perhaps provide a sample PNG so that we can try out and reproduce your problem?

[WtFrostyCakes]

Here's one: https://i.imgur.com/rsXWOSu.png

[Rick]

I reduced it a bit in Affinity Photo by changing the clor space to gray/16 and exporting as gray dithered but I cannot repeat that in XnView

[helmut]

Thank you for your sample PNG file, WtFrostyCakes. I've opened your image and saved it in XnView using various compression levels which can be set in the PNG format options (in "Save As" dialog click on button "Options"). Please note that compression level doesn't affect image quality - in other words above images are 100% identical which can seen in the identical CRC when comparing them using "Tools > Compare..."

Here are the results:
rsXWOSu.png 1.772.315 Bytes - original file
rsXWOSu_xnview_1.png 1.877.088 Bytes - saved with compression level 1
rsXWOSu_xnview_2.png 2.936.202 Bytes - saved with compression level 6 (XnView's default)
rsXWOSu_xnview_3.png 2.922.016 Bytes - saved with compression level 9

Compression level seems to have an effect on file size but personally I'm surprised that the lowest compression level results in the smallest file size.

[XnTriq]

I reduced it a bit in Affinity Photo by changing the clor space to gray/16 and exporting as gray dithered but I cannot repeat that in XnView

PngOptimizer can be integrated into XnView's toolbar and reduces the file size of rsXWOSu.png by 64% to 1'134'757 bytes without quality loss.

[XnTriq]

I converted rsXWOSu.png to BMP format and saved it via File → Export → PNG (non-interlaced + no filtering) in MP v0.99.7:

• Compression level 0 = 5'055'936 bytes
• Compression level 1 = 1'815'184 bytes
• Compression level 2 = 1'783'986 bytes
• Compression level 3 = 1'703'019 bytes
• Compression level 4 = 2'956'139 bytes
• Compression level 5 = 2'774'851 bytes
• Compression level 6 = 2'577'262 bytes
• Compression level 7 = 2'561'261 bytes
• Compression level 8 = 2'550'119 bytes
• Compression level 9 = 2'542'791 bytes

This is clearly a bug!

According to the zlib specification (RFC-1950), the zlib datastream within a PNG file contains a two-bit "FLEVEL" flag:

Code: Select all

FLEVEL (Compression level)

These flags are available for use by specific compression methods.
The "deflate" method (CM = 8) sets these flags as follows:

0 - compressor used fastest algorithm                      [levels 0, 1]
1 - compressor used fast algorithm                         [levels 2-5]
2 - compressor used default algorithm                      [level 6]
3 - compressor used maximum compression, slowest algorithm [levels 7-9]

[helmut]

Thank you, XnTriq, for this valuable info - I also think that there's a bug.

The test image is a bit special because it's a grey scale image. It would be interesting to see whether results are similar for PNG files in RGB.

[XnTriq]

The test image is a bit special because it's a grey scale image. It would be interesting to see whether results are similar for PNG files in RGB.

True. I've repeated my test with PNG_transparency_demonstration_1.png (32-bit RGBA). Results are as expected

XnView MP v0.99.7 and XnView Classic v2.49.2:

Code: Select all

Compression level 0 = 1'923'782 bytes
Compression level 1 =   289'717 bytes
Compression level 2 =   282'301 bytes
Compression level 3 =   274'546 bytes
Compression level 4 =   250'067 bytes
Compression level 5 =   246'170 bytes
Compression level 6 =   243'458 bytes
Compression level 7 =   242'484 bytes
Compression level 8 =   241'682 bytes
Compression level 9 =   239'670 bytes

[XnTriq]

rsXWOSu.png (32-bit RGBA):

XnView MP v0.99.7:

Code: Select all

Compression level 0 = 5'055'936 bytes = 617 IDAT chunks à 8192 bytes
Compression level 1 = 1'815'184 bytes
Compression level 2 = 1'783'986 bytes
Compression level 3 = 1'703'019 bytes
Compression level 4 = 2'956'139 bytes
Compression level 5 = 2'774'851 bytes
Compression level 6 = 2'577'262 bytes
Compression level 7 = 2'561'261 bytes
Compression level 8 = 2'550'119 bytes
Compression level 9 = 2'542'791 bytes

XnView Classic v2.49.2:

Code: Select all

Compression level 0 = 6'740'699 bytes = 822 IDAT chunks à 8192 bytes
Compression level 1 = 1'877'088 bytes = 229 IDAT chunks à 8192 bytes
Compression level 2 = 1'845'872 bytes = 225 IDAT chunks à 8192 bytes
Compression level 3 = 1'793'239 bytes = 219 IDAT chunks à 8192 bytes
Compression level 4 = 3'197'429 bytes = 390 IDAT chunks à 8192 bytes
Compression level 5 = 3'046'655 bytes = 372 IDAT chunks à 8192 bytes
Compression level 6 = 2'936'202 bytes = 358 IDAT chunks à 8192 bytes
Compression level 7 = 2'929'191 bytes = 358 IDAT chunks à 8192 bytes
Compression level 8 = 2'925'946 bytes = 357 IDAT chunks à 8192 bytes
Compression level 9 = 2'922'016 bytes = 357 IDAT chunks à 8192 bytes

[helmut]

... I've repeated my test with PNG_transparency_demonstration_1.png (32-bit RGBA). Results are as expected

Thank you for another test series, XnTriq. Looks like there's a problem when saving specific images in PNG format.

[xnview]

The test image is a bit special because it's a grey scale image. It would be interesting to see whether results are similar for PNG files in RGB.

True. I've repeated my test with PNG_transparency_demonstration_1.png (32-bit RGBA). Results are as expected

you have the problem only when using 'File>Export'?

[XnTriq]

you have the problem only when using 'File>Export'?

• rsXWOSu.png @ XnView MP v0.99.7 → File → Save as… → Options → Compression level

… and…

• rsXWOSu.png @ XnView MP v0.99.7 → File → Export… → PNG → Compression level

… produce identical results:

Code: Select all

Compression level 0 = 5'055'936 bytes
Compression level 1 = 1'815'184 bytes
Compression level 2 = 1'783'986 bytes
Compression level 3 = 1'703'019 bytes
Compression level 4 = 2'956'139 bytes
Compression level 5 = 2'774'851 bytes
Compression level 6 = 2'577'262 bytes
Compression level 7 = 2'561'261 bytes
Compression level 8 = 2'550'119 bytes
Compression level 9 = 2'542'791 bytes

[xnview]

… produce identical results:

so where is the problem??

[XnTriq]

so where is the problem??

Files saved/exported with level 9 (highest compression) are supposed to be smaller than those saved/exported with level 1 (lowest compression), n'est-ce pas?