How can an Interlaced .png file's size be smaller than the original file?

Question

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.

Answer 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.

Answer 2

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.