Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
User Journal

Journal Some_Llama's Journal: JPEG compression, is this any better? 1

SO I was thinking (off hand for a few minutes) about how images are compressed using the format JPEG.

Could it be done better? I think maybe yes...

With current processors (64 bit) and storage space I was thinking of an algorithm that would go like this (I might repeat myself but this is for clarity):

Hard code all pixel color values for 32 bit color, this would mean 16 million colors (each exact shade) indexed with a particular Byte value.. say 00000001 for absolute black (255,255,255?).

So this would create a lookup table within the algorithm (that could be optimized i'm sure) for each of the 16 million colors for 32bit pics.

You would also need about 200 other Bytes defined as instructions (go to, increment, decrement, number of pixels,etc)

So, a 1600x1200 32 bit picture would give you 1,920,000 "Bytes" of color information, with each pixel being represented by one distinct Byte per color for that specific pixel.

1.9 MB is pretty standard for raw pic info, but the way it could be optimized (compressed) and would result in no loss of clarity would be to have the program that interprets the dat do so thusly:

For all values of adjacent pixels that have the same "Byte" value you place a Go To Byte value... so say you have 15 pixels across a picture (from left to right) that have a Byte value of 00000001, the Go To value is 10111110, and number of pixel value of 1111110 (equaling 14), with 3 bytes you could store 15 bytes worth of pixel info with no loss.
The program would read the string of bytes 00000001:10111110:11111110 as:
  this first pixel is black:go to:pixel 15

And just write the same pixel value for all pixels in the "go to" range.

So for pictures where adjacent colors are the same value you would save a lot of space with no loss, of course IRL colors are not so accommodating, BUT colors do tend to gradually increment shades and such, to a different way to express this would be:
byte value:increment value by 1:go to:5

So say you have a gradual increment in shades for even 5 pixels you could shave this down to 4.

You could do the same thing for alternating pixels that go up then down a shade of color, like for borders.

This has probably already been done, and in a more efficient way, but it has interested me before so I wanted to write down my thoughts while they were fresh... if you have any insight please post.

This discussion has been archived. No new comments can be posted.

JPEG compression, is this any better?

Comments Filter:

If you want to put yourself on the map, publish your own map.

Working...