Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Understanding image (its hex values)

Tags:

pixel

png

I am trying to understand the hex values of a 10 x 10 pixel png image file.

For example: I am using this image http://www.sweethome3d.com/blog/common/images/feed-icon-10x10.png?. I opened it in Sublime Text 2 and saw following values

8950 4e47 0d0a 1a0a 0000 000d 4948 4452
0000 000a 0000 000a 0806 0000 008d 32cf
bd00 0000 0467 414d 4100 00af c837 058a
e900 0000 1974 4558 7453 6f66 7477 6172
6500 4164 6f62 6520 496d 6167 6552 6561
6479 71c9 653c 0000 0167 4944 4154 78da
2c90 3b48 1c51 1885 bf7b 6766 5d7c 63a1
ae5a 180b 9140 086a 213e 106c 042b c1c6
5641 49bb 8d8d 76a6 491b d248 40d2 2888
a585 2058 a960 a168 a128 be90 557c e26b
d575 7667 e6de 9b99 5d8b c3df 7cff 3987
23ce 26be 8dc4 9dd8 3fa7 c8c1 7244 2889
0caf b40b 0a7c c5f3 7d66 545c 4db6 1bbb
ac9a 928e 41cc c331 3ab5 8e15 fb7c 0841
6109 dc77 b023 27bb a29c f8d7 3eac 9a1f
98dc 1bc1 f62c e660 310f a99c 469a 9089
e2c4 c72d eeca 34d2 bda5 a873 1ca7 3b89
ae6e c65b fd89 9751 686d 45a0 c46e 68a1
6478 06f3 7683 dafc 8d7a 39c5 ea9d c29c
6ee3 6f2d 6144 e81a 15e7 6e97 dcdc 10e6
e904 bbff 172a f38a b7b3 10ba 8f11 b8aa
101f 15b6 abea 717a 9298 9365 f4f9 1a76
5792 8f8d 7964 651d b2ae 0de5 9b02 282b
13c8 c65e 681a c05d ff8b ac48 1064 35ea
e91a e74b 7b1e 14af 7fba 4dbc d8a0 abbe
e35d 1ee1 3da7 11b5 ad64 cf0f a134 819f
4e63 b20f c868 cc68 273f b58f 7273 61f1
18fe c51e 681f f598 ca43 ca09 46ff 0b30
0081 6599 b7e4 9326 ee00 0000 0049 454e
44ae 4260 82

I intend to display this particular image on a led matrix and before I move forward with displaying it on led matrix, I intend to develop a program that can decode png file and use its RGB values to program the leds. Please explain how do I understand above values and extract every pixel's RGB value.

Thank you.

like image 869
stuartnox Avatar asked May 30 '15 19:05

stuartnox


2 Answers

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
like image 191
Glenn Randers-Pehrson Avatar answered Oct 21 '22 15:10

Glenn Randers-Pehrson


Reading your image and parsing the bytes according to the official specification, you would indeed get something like the dump at the end.

The compressed IDAT part has been unpacked here by my dump utility, so you can see the various row filters (this image uses Sub, Up, and Paeth), followed by 4 values for each pixel in the order Red, Green, Blue, Alpha. You can see the alpha values are all FF (fully opaque), except for the corner pixels where it is 60 (62% transparent).

To decompress the IDAT chunk (and some other compressed chunks), this requires an implementation of the deflate algorithm (a link for that is in the official specification).

The CRCs are reported as present in the file (I notice this one utility does not actually verify them, I need to add that some time).

If you want to use original PNG files as your input, you need to (a) be able to find, read, and understand the official specifications, (b) have a good grasp of computer imaging terms such as Grayscale, Indexed, Palette, Gamma, interlacing, filtering, Alpha, and RGB, (c) understand deflate enough to integrate an existing implementation into your own source code (which is what I did, rather than going the extra mile and write one from scratch), and (d) combine all of that information into an abstract model that is suitable for converting the data to your output format.

Or you can skip all that and use libpng.

File: test.png
Header 0x89 "PNG" CR LF ^Z LF checks out okay

block:  "IHDR", 13 bytes [49484452]
Width:              10
Height:             10
Bit depth:          8
Color type:         6 = Color + Alpha
(Bits per pixel: 8)
(Bytes per pixel: 4)
Compression method: 0
Filter method:      0
Interlace method:   0 (none)
number of row filters: 10
  [CRC: 8D32CFBD]

block:  "gAMA", 4 bytes [67414D41]
00 00 AF C8
  [CRC: 37058AE9]

block:  "tEXt", 25 bytes [74455874]
53 6F 66 74 77 61 72 65 00 41 64 6F 62 65 20 49 6D 61 67 65 52 65 61 64 79                      | Software.Adobe ImageReady
  [CRC: 71C9653C]

block:  "IDAT", 359 bytes [49444154]
expanded result: 410 (as expected)
(Row   0 Filter:1)
(Row   1 Filter:1)
(Row   2 Filter:4)
(Row   3 Filter:4)
(Row   4 Filter:4)
(Row   5 Filter:2)
(Row   6 Filter:2)
(Row   7 Filter:2)
(Row   8 Filter:1)
(Row   9 Filter:2)
DD 75 2D 60 E5 7A 33 FF EA 81 38 FF ED 86 39 FF F0 8B 3B FF F2 90 3C FF F4 94 3D FF F6 98 3E FF F2 93 3B FF E1 7D 30 60 
E5 7A 33 FF E9 87 49 FF F4 BE 98 FF F3 AA 72 FF F1 8B 35 FF F4 91 36 FF F7 96 38 FF F9 9A 39 FF FA 9D 3A FF F1 91 3A FF 
EA 37 05 FF EE 46 13 FF FC B1 8A FF FF C1 D9 FF FE A3 65 FF FA 6F 02 FF F9 45 AC FF FA 48 AD FF F7 41 AB FF F3 40 B0 FF 
ED 05 01 FF EF FB FB FF F3 B4 7D FF F5 B8 C1 FF FC DC CA FF FF DE D5 FF FD F4 FB FF F7 B0 7E FF F1 A5 7B FF EF A3 7E FF 
F0 05 02 FF F4 17 23 FF FF 6E BB FF FE 61 A8 FF FB 28 39 FF FC 18 15 FF FF 56 90 FF F6 32 4A FF EC FD FC FF EB FE FA FF 
F2 0A 03 FF F4 00 F2 FF F8 12 0D FF FD 4F 83 FF FF 6E C1 FF F9 0D 07 FF F9 24 38 FF FD 6B AE FF E8 F4 F9 FF E8 F7 F8 FF 
F4 0E 04 FF F8 12 0D FF FD 4E 7D FF FC 2A 39 FF FD 4D 83 FF FD 47 77 FF EF E8 DD FF FF 7B C8 FF EA 0E 2B FF E5 F2 F7 FF 
F6 12 05 FF FA 22 26 FF FF 6E BB FF FC 4C 82 FF F4 10 1D FF FF 56 90 FF EB E0 DB FF FC 69 AE FF EF 2F 5E FF E2 ED F6 FF 
F2 93 3B FF FA 9D 3A FF F8 AF 69 FF F2 92 42 FF EC 81 33 FF ED 99 64 FF E5 78 3B FF E5 84 54 FF E0 75 45 FF DF 6D 31 FF 
E1 7D 30 60 F1 91 3A FF F3 90 3D FF EF 89 3B FF EB 82 39 FF E8 7B 37 FF E5 76 36 FF E2 71 35 FF DF 6D 31 FF DC 72 2D 60 
  [CRC: E49326EE]

block:  "IEND", 0 bytes [49454E44]
  [CRC: AE426082]
like image 31
Jongware Avatar answered Oct 21 '22 15:10

Jongware