A hex dump of a PNG isn't really human-readable. "od" comes closer:
od -c *.png
0000000 211 P N G \r \n 032 \n \0 \0 \0 \r I H D R
0000020 \0 \0 \0 \n \0 \0 \0 \n \b 006 \0 \0 \0 215 2 317
0000040 275 \0 \0 \0 004 g A M A \0 \0 257 310 7 005 212
0000060 351 \0 \0 \0 031 t E X t S o f t w a r
0000100 e \0 A d o b e I m a g e R e a
0000120 d y q 311 e < \0 \0 001 g I D A T x 332
0000140 , 220 ; H 034 Q 030 205 277 { g f ] | c 241
....
0000660 030 376 305 036 h 037 365 230 312 C 312 \t F 377 \v 0
0000700 \0 201 e 231 267 344 223 & 356 \0 \0 \0 \0 I E N
0000720 D 256 B ` 202
The first line is the 8-byte PNG signature, 4-byte number 13 (length of the IHDR chunk), "IHDR".
The second line is the 13 bytes of IHDR data (width, height, bit depth, color type, etc.), followed by a 4-byte CRC (cyclical redundancy check).
The third line is a gAMA chunk with a 4-byte length (4), "gAMA", 4-byte gamma value, and 4-byte CRC
The fourth and fifth lines contain a tEXt chunk identifying the software that created the PNG, with 4-byte length, 4-byte chunk name "tEXt", the text, then 4-byte CRC.
The next line begins the IDAT chunk which contains a zlib-compressed representation of the pixels, again with 4-byte length.
The final two lines contain the CRC for the IDAT chunk followed by an IEND chunk to mark the end of the PNG: 0000 is the data length, IEND is the chunk name, and 256 B ` 202 is the four-byte CRC for the IEND chunk.
All of this is explained in the PNG format specification, which you can read at http://www.w3.org/TR/PNG
I second Mark Setchell's recommendation to convert the file to the trivial PPM format and then work with that; that's what I usually do even though I'm quite familiar with PNG and libpng.
Here's what your image looks like as a PPM:
convert *.png -compress none ppm:-
P3
10 10
255
221 117 45 229 122 51 234 129 56 237 134 57 240 139 59 242 144 60 244 148 61 246 152 62 242 147 59 225 125 48
229 122 51 233 135 73 244 190 152 243 170 114 241 139 53 244 145 54 247 150 56 249 154 57 250 157 58 241 145 58
[8 more long lines omitted]
That's just "P3" (means RGB, ASCII format);
10 10 (width, height);
255 (maximum intensity value for each channel);
R G B R G B R G B.... until all 100 RGB pixels have been transmitted
Note that the alpha channel, if present, gets lost in the conversion
to PPM. You can convert to NETPBM's PAM format http://en.m.wikipedia.org/wiki/Netpbm#PAM_graphics_format which is similar to PPM but has been extended to include an alpha (opacity) channel (but unfortunately is not human-readable), or to ImageMagick's TXT format instead; that supports alpha but is quite verbose:
convert *.png txt:-
# ImageMagick pixel enumeration: 10,10,255,srgba
0,0: (221,117,45,0.376471) #DD752D60 srgba(221,117,45,0.376471)
1,0: (229,122,51,1) #E57A33 srgba(229,122,51,1)
2,0: (234,129,56,1) #EA8138 srgba(234,129,56,1)
etc., through
7,9: (226,113,53,1) #E27135 srgba(226,113,53,1)
8,9: (223,109,49,1) #DF6D31 srgba(223,109,49,1)
9,9: (220,114,45,0.376471) #DC722D60 srgba(220,114,45,0.376471)
Another useful application is "pngcheck" which lists the PNG chunks and checks their CRC for errors:
pngcheck -v *.png
File: feed-icon-10x10.png (469 bytes)
chunk IHDR at offset 0x0000c, length 13
10 x 10 image, 32-bit RGB+alpha, non-interlaced
chunk gAMA at offset 0x00025, length 4: 0.45000
chunk tEXt at offset 0x00035, length 25, keyword: Software
chunk IDAT at offset 0x0005a, length 359
zlib: deflated, 32K window, maximum compression
chunk IEND at offset 0x001cd, length 0
