3

I need to read a PNG file and interpret all the information stored in it and print it in human readable format. While working on PNG, I understood that it uses CRC-32 for generating checksum for each chunk. But I could not understand the following information mentioned on the PNG file specification site: The polynomial used by PNG is: x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1

Here is the link for reference: http://www.w3.org/TR/PNG/

Can anyone please help me in understanding this?

Zoe
  • 27,060
  • 21
  • 118
  • 148
name_masked
  • 9,544
  • 41
  • 118
  • 172

3 Answers3

6

http://en.wikipedia.org/wiki/Computation_of_CRC ?

According to list of CRCs in wiki, this polynomial (aka AUTODIN II polynomial ) is one of the most used. CRC-32-IEEE 802.3 x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1

Used in (Ethernet, V.42, MPEG-2, PNG, POSIX cksum, Arj, Lha32, Rar, Zip, and more..)

Rewritted with power marked by ^:

 x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1.

So you can read source of cksum, e.g. here

http://www.opensource.apple.com/source/file_cmds/file_cmds-188/cksum/crc32.c

The 32-bit AutoDIN-II CRC is built upon the following shift-register reference model.

Polynomial: g(x) = 1 + x + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 + x^12 + x^1 + x^22 + x^23 + x^26 + x^32

Input data bit 0 first

Leading-zero checking is performed by the following procedure:

 1. The crc register is initialized to 0xffffffff, not zero.

 2. When a crc is appended, the 32 bits of the crc are inverted.

 3. When checking a good message with an appended crc, the register
    will return to the fixed value of 0xdebb20e3, rather than zero.
osgx
  • 90,338
  • 53
  • 357
  • 513
  • 1
    can you elaborate a little bit? https://stackoverflow.com/questions/62168128/understanding-cyclic-redundancy-code-algorithm-for-beginners What is X here supposed to represent exactly? the current bit of the 32-bit initialized CRC? but how exactly? – B''H Bi'ezras -- Boruch Hashem Jun 03 '20 at 08:19
4

That's the CRC-32 algorithm implemented in zlib. Please don't implement your own when you can use that library instead.

[EDIT]: How to use the CRC calculator from zlib (an example in C extracted from the zlib docs).

#include <zlib.h>

uLong crc = crc32(0L, Z_NULL, 0);

while (read_buffer(buffer, length) != EOF) {
   crc = crc32(crc, buffer, length);
}
if (crc != original_crc) error();

If you have the block of data that you want to get the CRC for, you don't need that while loop; you just get the initial value (first assignment to crc above) and then compute the value over the data that you have (second assignment to crc).

Community
  • 1
  • 1
Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • 1
    Hi Donald, I need to check if the checksum matches for each chunk with my own computed checksum value. What should be the procedure in this case? – name_masked Mar 28 '10 at 00:30
  • 3
    "Please don't implement your own when you can use that library instead." Stop with this nonsense. – MarcusJ Nov 15 '18 at 19:35
0

Every x term refers to a 1 in the binary representation of 0xedb88320, which is 11101101 10111000 10000011 00100000. The number on the left (least-significant) end, 1, is the (coefficient of the) constant (x^0) term. The next number from the left, 1, is the coefficient of the x term. The next number, 1, is the coefficient of the x^2 term. The next number, 0, is the coefficient of the x^3 term (which is absent because 0*x^3 = 0). And so on. There is an implied 1 to the right of the right (most-significant) end that is the coefficient of the x^32 term.

greg-tumolo
  • 698
  • 1
  • 7
  • 30