in reply to Re: pnt2bmp
in thread pnt2bmp
Well, some of it was just good guessing based on what I remembered.
The Tandy 1000 had a "TGA" adapter, basically EGA with a fixed 4-bit/16 color palette, and the display was 320x200. So I knew I was more or less looking at 32K of pixel data uncompressed.
Looking through a bunch of old files, I could tell where the header was and that it was mostly blank. Given the range in size, I had an idea of what the minimum run length could be. The smallest image was something like 297 bytes.
My initial thought was perhaps that pixels were packed, two to a byte unless it was some special value, then that would indicate run length encoding. I tried to do some statistical analysis of the data in the images, but never my strong suit. So I decided to try something different. Instead of writing a proper bitmap, I encoded each value as a pixel (R=byte value, G=B=0) to visualize it and pretended the bitmap was a width of a power of 2.
Once I could see it, it was a lot more obvious. I could definitely see patterns (though a corrupted image or two almost threw me off), lot's of vertical lines. The lines made me think that pixels were encoded in pairs, but that didn't quite make sense seeing it was compressed. It seemed wasteful to use a byte for a 4-bit pixel and another byte for the runlength, I thought maybe when a byte was some special value, X bits of it and the next were used for the encoding, but the "lines" in the data didn't seem to support that.
Next I visualized it but used 3 bytes for each pixel, and it was just noise, so I knew the byte pair was the right track.
I thought, maybe it's always Odd_byte=2px, Even_byte=run_length. Seemed funny, but then I thought, well, with a 16 color fixed palette, you dither like crazy, so maybe not so unreasonable to compress in pixel pairs.
I gave it a try and while some pics looked like something (thought nothing you'd expect), some seemed tantalizingly close (harder to tell as I hadn't dug up the palette values yet). Though it's been 17 yrs, some of the file names, rang some bells, in particular a 3D mesh cube I drew, with all it's horizontal lines, was very close.
Then I thought, maybe they are smaller than 320 due to the real estate used by the UI. A took it back a few pixels and viola!
Here's a pic of the visualizations of one of the files.
http://www.leeland.net/lib/leeland/decode-progress.gif
And the image decoded. (Terminator 1991).
http://www.leeland.net/lib/leeland/tandy-terminator-1.gif
Keep in mind, 16 color palette, no mouse, lot's of hand dithering. I think they are pretty good for the time. A couple more for those nostalgic for the PCjr days.
Arnold/Terminator unfinished '91 (whose idea was it for no fleshy color in the palette!)
http://www.leeland.net/lib/leeland/tandy-terminator-2.gif
Some art from a game I was working on in 89.
http://www.leeland.net/lib/leeland/tandy-war-1.gif
http://www.leeland.net/lib/leeland/tandy-war-2.gif
-Lee
"To be civilized is to deny one's nature."
The Tandy 1000 had a "TGA" adapter, basically EGA with a fixed 4-bit/16 color palette, and the display was 320x200. So I knew I was more or less looking at 32K of pixel data uncompressed.
Looking through a bunch of old files, I could tell where the header was and that it was mostly blank. Given the range in size, I had an idea of what the minimum run length could be. The smallest image was something like 297 bytes.
My initial thought was perhaps that pixels were packed, two to a byte unless it was some special value, then that would indicate run length encoding. I tried to do some statistical analysis of the data in the images, but never my strong suit. So I decided to try something different. Instead of writing a proper bitmap, I encoded each value as a pixel (R=byte value, G=B=0) to visualize it and pretended the bitmap was a width of a power of 2.
Once I could see it, it was a lot more obvious. I could definitely see patterns (though a corrupted image or two almost threw me off), lot's of vertical lines. The lines made me think that pixels were encoded in pairs, but that didn't quite make sense seeing it was compressed. It seemed wasteful to use a byte for a 4-bit pixel and another byte for the runlength, I thought maybe when a byte was some special value, X bits of it and the next were used for the encoding, but the "lines" in the data didn't seem to support that.
Next I visualized it but used 3 bytes for each pixel, and it was just noise, so I knew the byte pair was the right track.
I thought, maybe it's always Odd_byte=2px, Even_byte=run_length. Seemed funny, but then I thought, well, with a 16 color fixed palette, you dither like crazy, so maybe not so unreasonable to compress in pixel pairs.
I gave it a try and while some pics looked like something (thought nothing you'd expect), some seemed tantalizingly close (harder to tell as I hadn't dug up the palette values yet). Though it's been 17 yrs, some of the file names, rang some bells, in particular a 3D mesh cube I drew, with all it's horizontal lines, was very close.
Then I thought, maybe they are smaller than 320 due to the real estate used by the UI. A took it back a few pixels and viola!
Here's a pic of the visualizations of one of the files.
http://www.leeland.net/lib/leeland/decode-progress.gif
And the image decoded. (Terminator 1991).
http://www.leeland.net/lib/leeland/tandy-terminator-1.gif
Keep in mind, 16 color palette, no mouse, lot's of hand dithering. I think they are pretty good for the time. A couple more for those nostalgic for the PCjr days.
Arnold/Terminator unfinished '91 (whose idea was it for no fleshy color in the palette!)
http://www.leeland.net/lib/leeland/tandy-terminator-2.gif
Some art from a game I was working on in 89.
http://www.leeland.net/lib/leeland/tandy-war-1.gif
http://www.leeland.net/lib/leeland/tandy-war-2.gif
-Lee
"To be civilized is to deny one's nature."
In Section
Code Catacombs