Re: JPEG2000


"Jasen Betts" <jasen@xxxxxxxxxxx> wrote in message
news:1f66.442b94a9.59fe0@xxxxxxxxxxxxxxxxxx
On 2006-03-29, alfred.kidd@xxxxxxxxx <alfred.kidd@xxxxxxxxx> wrote:
Hi everyone,

The problem I have, I tried to compress a *.bmp image to under 500
bytes with no success.

We are in need of a compression meganism that is capable of compressing
a small *.bmp image to a file under 500 bytes.

I don't think jpeg works well on images that size

yeah, difficulty would be fitting the headers and huffman table in that
space, much less any payload...

quick check of my jpeg decoder shows it taking 600 bytes already before the
image data is even reached.

When decompressed the *.bmp image must be more or less the size of a
drivers licence photo.

Any help whould be most appreciated.

use larger pixels/fewer bits per pixel.

if you made the image one bit per pixel and 20x20 pixels no compression
would be needed.

since it is 500 bytes, one can go a little higher:
32x32 at 1bpp is 128 bytes, up to 4bpp can be fit in 512 bytes.
36x36 at 3bpp takes 486 bytes (this might be enough to distinguish that it
is a head...).

quick check (convinient self image), yeah, one could determine that it is a
head, no real hope of determining whos though...

maybe huffman and some manner of filtering "could" get it a little higher,
but not by any standard means (no space to store the tables, no space to
store predictor info, ...).

64x72, facial recognition is likely possible.
at 4bpp this would take 2.3kB, a little over the limit.
squeezing it a little more could be possible (again, fixed predictor and
huffman). however, even a flat black square will still likely cost 600 bytes
in this case (arith coding could initially do better, but to make work at
all the probabilities would likely need to be set initially). that or the
huffman coder has rle (likely repeating some run of 0's).

example codes:
0 0
1 100
F 101
2 11000
E 11001
3 11010
D 11011
4 111000
C 111001
5 111010
B 111011
6 111100
A 111101
7 111110
8 1111110
9 11111110
RLE 11111111 LLLL

or, rle could have a shorter code, depending on the frequency of runs,
assuming ~2 runs/scan (flat color either side of the head), 108 bytes would
go just to RLE runs.
the number of remaining bytes would have a lot to do with the image content.

dunno if any of this helps much...


so, take it or leave it...

Bye.
Jasen


.

Relevant Pages

  • Next set of vetting
    ... Harrington's Compression Method, ... The First Fundamental is the Huffman. ... Pascals triangle has applications in many many different fields. ... possible outcomes of that many bits, ...
    (comp.compression)
  • Re: Next set of vetting
    ... design a model for a data source that fits to that. ... In typical compression the usage ... You forget here that the input of the huffman must be "out of balance" ... you will find that the result is in balance. ...
    (comp.compression)
  • Re: huffman compression
    ... >i want a full code of huffman data compression for text files in C++. ... other algos, eg, huffman, for some increase in total compression ratio). ... faster than I can get an arithmatic coder. ... with static huffman, eg, chunking and stream encoding concerns). ...
    (comp.compression)
  • Re: huffman tree save to file
    ... > Could you suggest different ways for saving huffman tree in the ... > compressed file header? ... non-trivial size, imo, the huffman tree size doesn't matter that much. ... computer), but, as a cost, the compression ratio was rather poor. ...
    (comp.compression)
  • New compression theory announcement soon
    ... This compression method will define a new range for Entropy, ... The First Fundamental is the Huffman. ... possible outcomes of that many bits, ...
    (comp.theory)