2

Ok, so I tried to use the imagemagick command:

"convert picA.png -interlace line picB.png"

to make an interlace version of my .png images. Most of the time, I got the resulting image is larger than the original one, which is kinda normal. However, on certain image, the resulting image size is smaller.

So I just wonder why does that happen? I really don't want my new image to lose any quality because of the command.

Also, is there any compatibility problem with interlaced .png image?

EDIT: I guess my problem is that the original image was not compressed as best as it could be.

CSDD
  • 339
  • 2
  • 14

2 Answers2

4

The following only applies to the cases where the pixel size is >= 8 bits. I didn't investigate for other cases but I expect similar outcomes.

A content-identical interlaced PNG image file will almost always be greater because of the additional data for filter type descriptions required to handle the passes scanlines. This is what I explained in details in this web page based on the PNG RFC RFC2083. In short, this is because the sum of the below number of bytes for interlaced filter types description per interlacing pass is almost always greater than the image height (which is the number of filter types for non-interlaced images):

nb_pass1_lines = CEIL(height/8)

nb_pass2_lines = (width>4?CEIL(height/8):0)

nb_pass3_lines = CEIL((height-4)/8)

nb_pass4_lines = (width>2?CEIL(height/4):0)

nb_pass5_lines = CEIL((height-2)/4)

nb_pass6_lines = (width>1?CEIL(height/2):0)

nb_pass7_lines = FLOOR(height/2)

Though, theoretically, it can be that the data entropy/complexity accidentally gets lowered enough by the Adam7 interlacing so that, with the help of filtering, the usually additional space needed for filter types with interlacing may be compensated through the deflate compression used for the PNG format. This would be a particular case to be proven as the entropy/complexity is more likely to increase with interlacing because the image data is made less consistent through the interlacing deconstruction.

I used the word "accidentally" because reducing the data entropy/complexity is not the purpose of the Adam7 interlacing. Its purpose is to allow the progressive loading and display of the image through a passes mechanism. While, reducing the entropy/complexity is the purpose of the filtering for PNG.

I used the word "usually" because, as shown in the explanation web page, for example, a 1 pixel image will be described through the same length of uncompressed data whether interlaced or not. So, in this case, no additional space should be needed.

When it comes to the PNG file size, a lower size for interlaced can be due to:

  1. Different non-pixel encoding related content embedded in the file such as palette (in the case of color type =! 3) and non-critical chunks such as chromaticities, gamma, number of significant bits, default background color, histogram, transparency, physical pixel dimensions, time, text, compressed text. Note that some of those non-pixel encoding related content can lead to different display of the image depending on the software used and the situation.
  2. Different pixel encoding related content (which can change the image quality) such as bit depth, color type (and thus the use of palette or not with color type = 3), image size,... .
  3. Different compression related content such as better filtering choices, accidental lower data entropy/complexity due to interlacing as explained above (theoretical particular case), higher compression level (as you mentioned)

If I had to check whether 2 PNG image files are equivalent pixel wise, I would use the following command in a bash prompt:

diff <( convert non-interlaced.png rgba:- ) <( convert interlaced.png rgba:- )

It should return no difference.

For the compatibility question, if the PNG encoder and PNG decoder implement the mandatory aspects of the PNG RFC, I see no reason for the interlacing to lead to a compatibility issue.

Edit 2018 11 13:

Some experiments based on auto evolved distributed genetic algorithms with niche mechanism (hosted on https://en.oga.jod.li ) are explained here: https://jod.li/2018/11/13/can-an-interlaced-png-image-be-smaller-than-the-equivalent-non-interlaced-image/

Those experiments show that it is possible for equivalent PNG images to have a smaller size interlaced than non-interlaced. The best images for this are tall, they have a one pixel width and have pixel content that appear random. Though, the shape is not the only important aspect for the interlaced image to be smaller than the non-interlaced image as random cases with the same shape lead to different size differences.

So, yes, some PNG images can be identical pixel wise and for non-pixel related content but have a smaller size interlaced than non-interlaced.

Community
  • 1
  • 1
luvzfootball
  • 710
  • 1
  • 9
  • 21
  • 1
    The interlacing is most likely taking more CPU and contributing to (minor) power consumption. It made sense with slow data connections. It might be useful for thumbnail creation, but it is mainly useless today and slightly complicates encoders/decoders. The likelihood of an interlaced PNG being smaller would complete this answer. The referenced link shows only results for 1px width images. Ergo is this the only type of image that this is worth trying? I think so? – artless noise Nov 30 '21 at 16:13
  • Indeed, we can expect interlaced PNG images to use slightly more CPU, power, computation time and complexity in general. PNG interlacing in general is also, indeed, less and less relevant because of the higher bandwidths we usually enjoy. Linked page mentions a general shape experiment result showing that tall images are the best ones for the set goal. Width was explored. See section 7 here https://www.researchgate.net/publication/330082484_Genetic_algorithms_with_niche_and_parameters_auto_optimisation_to_find_PNG_interlaced_image_smaller_than_non-interlaced – luvzfootball Nov 30 '21 at 21:41
1

So I just wonder why does that happen?

From section Interlacing and pass extraction of the PNG spec.

Scanlines that do not completely fill an integral number of bytes are padded as defined in 7.2: Scanlines.

NOTE If the reference image contains fewer than five columns or fewer than five rows, some passes will be empty.

I would assume the behavior your experiencing is the result of the Adam7 method requiring additional padding.

emcconville
  • 23,800
  • 4
  • 50
  • 66
  • Ok, that's probably to much info for me. In the end, I just want to know if this reduced in file size resulted in quality loss? – CSDD Jun 17 '16 at 04:57
  • @CSDD: PNG compression is *always* lossless: ".. an extensible file format for the lossless, portable, well-compressed storage of raster images.." (from [The Specifications](http://www.w3.org/TR/PNG/)). It's more likely that some of your original files were not compressed as well as it could have. – Jongware Jun 17 '16 at 09:40
  • @Rad Lexus I see. Think that is a compression problem too, as when I use a program called Png Optimizer to compress it, I got 67% the original size. So I guess problem solved. Thank you. – CSDD Jun 17 '16 at 14:37
  • "Adam7 method requiring additional padding." In that case, one would expect the interlaced image to be larger, no? – leonbloy Jun 21 '16 at 19:48
  • @leonbloy, correct. From OP: "Most of the time, I got the resulting image is larger than the original one". With Adam7 being the only interlacing method (I think), we can assume that padding was at play for the majority of the time. With OP not defining compression methods, or providing what "certain image(s)" is/are, we can also assume Adam7 padding was minimal, and the default compression method cleaned-up quite nicely. – emcconville Jun 21 '16 at 20:40
  • Interlaced PNG is usually (nearly always) bigger, but not because of the padding but because the rearrangement of pixels lowers the local redundacy that is seen by the compressing filter http://optipng.sourceforge.net/pngtech/optipng.html https://blog.codinghorror.com/getting-the-most-out-of-png/ – leonbloy Jun 21 '16 at 20:48
  • Your absolutely right! Flagging this answer as community wiki, and perhaps will follow up with examples demonstrating how interlacing + compressors will impact file size. – emcconville Jun 23 '16 at 13:53