Goal
I would like to know by advance the length of the uncompressed data within a PNG image whether it is encoded interlaced or not. Knowing and comparing the size of interlaced against non-interlaced PNG uncompressed (inflated) data can allow a wiser choice when encoding a PNG image and can also help while decoding. This can also explain why PNG images are usually greater when interlaced. All the following explanations are based on the PNG RFC. I focus on the cases when the pixel size is >= 8 bits.
Interlaced and non-interlaced: what changes in the PNG file?
Let’s assume 2 identical PNG images, one non-interlaced and one interlaced.
The differences between the files describing those images will be:
– In IHDR chunk: Interlace method (0 for non-interlaced, 1 (Adam7) for interlaced). This doesn’t change the file size by itself.
– In IDAT chunks: Compressed (deflated) scanlines starting with filter type containing the encoded image data. This usually changes the file size as explained below.
Uncompressed data size
The uncompressed (inflated) data length can be calculated as follows for the cases when the pixel size is >= 8 bits.
Non-interlaced case
uncompressed_data_length = height * width * nb_bits_per_pixel / 8 + height
Where nb_bits_per_pixel = nb_sample_per_pixel * bit_depth
Where nb_sample_per_pixel depends on the color_type:
color_type to nb_sample_per_pixel:
0 (grayscale) -> 1
2 (RGB) -> 3
3 (palette based) -> 1
4 (grayscale with alpha) -> 2
6 (RGB with alpha) -> 4
So, for example, if we assume a non-interlaced image with the following characteristics, we get an uncompressed data size of 1695885:
height: 677
width: 626
color_type: 6
=> nb_sample_per_pixel: 4
bit_depth: 8
=> nb_bits_per_pixel: 32
Note the “+ height” at the end of the formula giving the uncompressed_data_length. This is due to the fact that for each scanline, a leading filter type byte is necessary and there are as many scanlines as there are lines in a non-interlaced image.
Interlaced case
uncompressed_data_length = height * width * nb_bits_per_pixel / 8 + sum_lines_per_pass
Where sum_lines_per_pass = nb_pass1_lines + nb_pass2_lines + nb_pass3_lines + nb_pass4_lines + nb_pass5_lines + nb_pass6_lines + nb_pass7_lines
Where (calculation due to Adam7 interlace method):
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)
So, for example, if we assume an interlaced image with the following characteristics, we get an uncompressed data size of 1696479:
height: 677
width: 626
color_type: 6
=> nb_sample_per_pixel: 4
bit_depth: 8
=> nb_bits_per_pixel: 32
nb_pass1_lines = 85
nb_pass2_lines = 85
nb_pass3_lines = 85
nb_pass4_lines = 170
nb_pass5_lines = 169
nb_pass6_lines = 339
nb_pass7_lines = 338
=> sum_lines_per_pass = 1271 (which is greater than height 677 for the non-interlaced case)
Note the “+ sum_lines_per_pass” at the end of the formula giving the uncompressed_data_length. This is because the number of filter type needs to be added. Each scanline has a leading filter type. Having passes for the interlaced case leads to a different number of filter types.
Comparison of uncompressed data length formula whether interlaced or not
Is the number of filter types for the interlaced case always going to be greater than the one for the non-interlaced case because of the passes?
It is easy to show that the number of lines for passes 1, 2, 4 and 6 contribute already for at least a number equivalent to height when width > 4. Indeed:
CEIL(height/8) + CEIL(height/8) + CEIL(height/4) + CEIL(height/2) >= height
The number of lines for passes 3, 5 and 7 can contribute to increase the number of filters for the interlaced case above the number of filters for the non-interlaced case.
Thus, the number of filters for the interlaced case will almost always be greater than the one for the non-interlaced case.
Why is this only “almost” always greater?
Let’s take the following particular example:
height: 1
width: 1
color_type: 6
=> nb_sample_per_pixel: 4
bit_depth: 8
=> nb_bits_per_pixel: 32
nb_pass1_lines = 1
nb_pass2_lines = 0
nb_pass3_lines = 0
nb_pass4_lines = 0
nb_pass5_lines = 0
nb_pass6_lines = 0
nb_pass7_lines = 0
=> sum_lines_per_pass = 1 (which is equal to height 1)
This means that the uncompressed data length should be the same for a 1 pixel PNG image whether interlaced or not (particular case).
Conclusion
The conclusion is that the uncompressed data length of identical PNG images (with pixel size >= 8) will almost always be greater in the interlaced case because more filter types must be described in the file. Though, the compression (deflate) applied to the PNG data can lead to some particular cases if we compare the resulting PNG file sizes.