Almost readable photograph using only 64-bit color

dnaddor

Hi everyone.

I'm toying with the idea of designing a new security product, and I want to use the Prop. There must be a half dozen reasons why this will turn out to be impossible, but I'm really motivated to keep the cost down and using the Propeller is far better than using a PC (like my potential competitors).

The first showstopper is to create a readable photograph using only 64-bit color. I thought about using 4 bits instead of 2 bits per color, but I didn't know how difficult it would be to synchronize multiple cogs, and I didn't want to spin a board to try it. So I explored dithering the existing colors.

I discovered that it isn't necessary to handle each bit separately. I clock 4 bits of the same color horizontally. Because each vertical line is different, dithering compensates.

The attached program generates a photo of me! It probably isn't good enough for a production product, but it is a start, and might actually look better on a tiny LCD display.

I just thought I'd share this with the Parallax community in case it inspires someone.

P.S. Anyone know or want to guess if the Prop II will include more video capability?

jazzed

You could probably get away with even less detail for image recognition software. As it is almost all Propeller memory is used, and that will be a big problem. Good luck.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

scanlime

If memory was the only limitation, and you mostly needed to display stored bitmap graphics, you could try using a compressed framebuffer.

S3TC/DXTC is a compression algorithm that is very simple and fast to decompress, but it also gets decent compression ratios without a lot of quality loss. It's based on blocks of 4x4 pixels, where each block is represented by a 2bpp bitmap and two 16-bit colors. The 4-color palette consists of the two specified colors (endpoints on a line) as well as two more colors interpolated between the two endpoints. It probably wouldn't be too hard to write a video driver cog which decompresses a DXTC framebuffer in real-time.

http://en.wikipedia.org/wiki/S3_Texture_Compression

Baggers

Micah, and dnaddor,
S3TC/DXTC will give you a decent image, 256x192 = will still be 24KB though, and decompression to a scanline renderer will take a good couple of cogs, I only know cos I've done it [noparse]:D[/noparse] the slow part of the decompression is the interpolation between the two specified colours, but you would need more than one prop, as 24KB is a lot of memory, although with it only being 6-bit ( 64 colours not 64-bit ) you could reduce this down further to 18KB, as for creating the image, would it have to be digitized? or is the image just a token display after finding out who it is? ( eg after card swipe etc? ) cos if you're getting it from SD that's gonna need about another 8K ( currently ) for the drivers, if you're digitizin it, not sure how you'd manage that with a prop, it's a bit slow for all those calculations, on a frame, especially for realtime grabs.
jpg, could be read in, ( some cams send you the stream IIRC ) I've already done a jpg reader to display also with PropGFX, but that wasn't re-encoding it to DXTC it was just to a 128x96 bitmap buffer. I suppose that could be done though, although I'm not sure how fast you'd be able to get the data uncompressed and re-compressed to DXTC.
good luck with your task though, keep us informed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Rayman

Very nice! I wonder if you could cover the whole screen by making 4x4 square pixels by repeating each line 4 times...

Baggers

Rayman, this image is output by the propeller ( my PropGFX with SCART output ), doing realtime decoding from DXT1, to 15bit RGB.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·