An excercise in binary data manipulation: my PNG decoder.

[notfred]

Ok, this isn't a complete decoder, as it doesn't support a lot of the PNG image format's features yet. However, the parts that are done do work.
Actually, decoding a pNG iamge is a lot easier than one would think, my biggest problem is that the language I'm using (perl) much prefers to treat bytes as ASCII characters rather than binary data, so there's a lot of conversions going on.

I'm testing it on a small (4x4 pixel) image that's just a bunch of random colors. The hex values for each of the pixels are output at the bottom of the output.

Here's a sample output screen:

C:\>png.pl test.png
File Looks like a valid PNG

image contains 5 chunks
Chunk types (in order):
IHDR
gAMA
cHRM
IDAT
IEND

Header information (from IHDR):
Width: 4px
Height: 4px
Bit Depth: 8bpp
Color type: 6 (color used, alpha used)
Compression Method: 0 (only type 0 is defined)
Filtering Method: 0 (only type 0 is defined)
Interlace method: 0 (no interlace)
Filter type of scanline 1: 0
FF0000 FFFFFF F6FF00 FF00F6
Filter type of scanline 2: 0
810025 00FF0C 000000 0006FF
Filter type of scanline 3: 0
2FEE8D 2024CC 0006FF 000000
Filter type of scanline 4: 0
FF0000 FF00B4 FF00F6 880060

What do you think? I think this is pretty cool. (I like messing with pictures). After I get the decoder done, I plan to write an encoder to go along with it (the encoder will be easier I think, it has fewer required features to implement). and then some resizing algorithms.

Does anyone else find this kind of stuff interesting?

BTW, here's the test image I'm using.

 

[notfred]

I need to find a geekier message board.

 

[notfred]

yeah, you guys are officially non-geeks.

 

[DaveSimmons]

Back when I was doing Atari 800 game programming for Adventure International/Scott Adams Inc. I wrote self-modifying 6502 assembly code for drawing points, lines, and flood-fills becuase the BASIC graphics functions were too slow, that's pretty geeky

I've also written code for a couple of websites to dynamically generate state and world-map GIF files from database fields by re-writing the color table of a pre-drawn master GIF, that's mildly geeky

But for image work in our Windows C++/MFC app at work I use canned software, first paintlib and now CxImage. There's too much other work for me to spend time reinventing the wheel. Have fun though, it's cool even with the canned stuff when you get a resize to work or change a metafile on the clipboard into a jpeg.

 

[notfred]

DaveSimmons officially qualifies as a geek

I hate assembly.

 

[Beattie]

That's a good project, challenging and interesting. Right now I am working on a UNIX shell, partly because I find it interesting, and partly because I have to for one of my classes. It's all in C of course, so it's not as "l337" as the assembly stuff.

 

[DaveSimmons]

I hate assembly

It wasn't too bad after a month or two of learning, but it took a lot longer to actually accomplish something than with the C++/MFC I do now. Pretty cool to look back though at having a complete side-scrolling arcade game running at 60 FPS in 16 K (not MB) on a 1.7 MHz Commdore 64.

Right now I am working on a UNIX shell, partly because I find it interesting, and partly because I have to for one of my classes. It's all in C of course, so it's not as "l337" as the assembly stuff.

It wasn't so much l337 as a necessary evil on machines that ran at 1.7 or 1.0 MHz and had only 16 - 48K of memory. On modern machines even the 3D engines and most device drivers are done in C / C++ now so learning assembly is mostly just a way to better understand what's going on behind the scenes. I haven't used 8086 assembly since the DOS days (and even that was in a C app to make a couple of calls to DOS).

 

[n0cmonkey]

The most programming Ive done in a while is a "fix" or two on various linux programs to get them working on OpenBSD or Mac OS X. Before that I "fixed" a program in the book of my C class that wasnt Y2k compliant, and before that I was taking ADA95... :Q