I devised an image compression scheme in my head. Because high-color images need for instance 24 bits for each pixel, one could find similar colors and only store that large color value once and then store a bunch of cordinates. This will compress because instead of specifying a bunch of pixel color values in left-right-up-down associativity, you could instead use an 11 bit vector for a row and another small number for a collumn. This has probably already been done...

This FAQ is excellent. In particular the Introduction to Fractal compression one. It seems the jury is still out on whether its bullsh*t or not. For example

"There is reason to believe that Barnsley's company has *no algorithm* which takes a given reasonable image and achieves the compression ratios initially claimed for their fractal methods. The 1000-to-1 compression advertised was achieved only for 'rigged' class of images, with human assistance. The best unaided performance I've heard of is good lossy compression of about 80-1."

quote:

---

Original post by ParadigmShift
Who knows? With quantum computers it might be possible to store two or more bytes in the same physical location. Each bit can be in multiple states at the same time, it would just be a matter of figuring out which bit states comprise number A and which comprise number B. You might even be able to do calculations on the multiple values in parallel.

---

Although you can place n quantum bits into a superposition of all 2ⁿ possible bit strings, you can only ever read out one of them. You can prove that a quantum computer isn't able to do compression better than normal computers.

[edited by - sQuid on May 25, 2003 10:43:41 PM]

New Compression Method?:of 24-bit bitmap
????????????????????????????????????????????????????????????????????????
1. classify all picture elements into groups of colors
_______a. this will leave each unique color specified once
_______b. assuming a bitmap wastes space by storing duplicate color vectors
2. somehow index the RGB color values into single componet vectors
_______a. could be similar to color indexing
_______b. might be pointless
3. index all picture element coords linearly
_______a. for instance: the "pixel location" in an MxN bitmap would be M,N, the first pixel would be at row 1, collumn 1, and would simply be indexed as the first pixel.
_______b. so basically each color index will have a sub index of pixel position indexes--not in any special order.
???????????????????????????????????????????????????????????
Would this compress a bitmap as significantly as JPEG compression would? Or can more be done to this algorithm such as checking for 2D blocks of monotonic colors?

Something interesting I just found out: I first made a 24-bit bitmap of just solid black (every RGB pixel was 0,0,0). I checked the bitmap''s properties and it''s size is 477 KB. I then "compressed" the solid black bitmap into the JPEG format and found its size to be 3.21 KB. Now I wonder, why would any compression scheme not include the checking for massive blocks of the same color. If I created my own compression scheme, I''d check that solid black bitmap for blatant similarities such as it is, and I would specify something like (color,row,column), and that 3.21 KB JPEG could easily fit into 4 bytes. Peh--3,000 bytes for absolutely 0 variation in a picture, OMG :O Yes, I know that JPEG would be more effective on a real photograph.

leinad:
Check the more intresting stuff
The image thet represent checkerboard , you will get very intresting results on a diffrent compressors.

I made a checkered image of 16 squares. The compression ratio for JPEG from bitmap stayed the same. The smallest size was GIF and the second smallest was PNG. I bet if I saved an image as 256 color it would be much smaller, because the image was only 2 "primary" colors b/w.