Home > Archive > Compression > April 2006 > JPEG2000
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| alfred.kidd@gmail.com 2006-03-29, 7:55 am |
| Hi everyone,
I am using the following open source code to implement jpeg2000
encoding and decoding:
http://www.openjpeg.org/index.php?menu=doc
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.
When decompressed the *.bmp image must be more or less the size of a
drivers licence photo.
Any help whould be most appreciated.
Kind Regards
Alfred
| |
| Thomas Richter 2006-03-29, 7:55 am |
| Hi,
> 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.
Define "small".
> When decompressed the *.bmp image must be more or less the size of a
> drivers licence photo.
I mean, "in pixels". (-: How large you print the image is just
a matter of the rendering process.
For example:
$ ../j2k6/transcoder -b 0.001 shipbig_o.pgm s.j2k
$ ls -l s.j2k
-rw-r--r-- 1 thor mathphys 365 2006-03-29 12:36 s.j2k
is a 1280x1024x1 image, compressed to 0.001 bpp. "Small enough" as an
output file for you. But the quality is very lousy at this rate, and
you cannot really tell what's on it if you compress an image that
large to a rate that small. The above code is the Pegasus JPEG2000
codec, see www.jpg.com.
So long,
Thomas
| |
| alfred.kidd@gmail.com 2006-03-29, 7:55 am |
| Hi Thomas
Thanks for the reply,
Is there any opensource solutions avaidable?
Alfred
| |
| alfred.kidd@gmail.com 2006-03-29, 7:55 am |
| >>But the quality is very lousy at this rate, and[color=darkred]
This is a problem, do you know of any alternative compression tools?
And if so, is there software avaidable for it... I want to port it to
my eVc++ project.
Kind Regards
Alfred
| |
| Thomas Richter 2006-03-29, 7:55 am |
| Hi,
[color=darkred]
> This is a problem, do you know of any alternative compression tools?
Whether this is a problem depends on whether you want to compress
images of that size. So, what *are* the sizes of your images?
So long,
Thomas
| |
| alfred.kidd@gmail.com 2006-03-29, 7:55 am |
| Thomas
We have Not decided on a *.bmp image size. The size of the bmp image
will be determined by the abillity of the compression tool to compress
the *.bmp file to a file smaller than 500bytes. If a big bmp image can
be compressed to file under 500 bytes we will use a big one.
Lets say the bmp image must be more or less 100x100.
Kind regards
A
| |
| Thomas Richter 2006-03-30, 3:55 am |
| Hi,
> We have Not decided on a *.bmp image size. The size of the bmp image
> will be determined by the abillity of the compression tool to compress
> the *.bmp file to a file smaller than 500bytes. If a big bmp image can
> be compressed to file under 500 bytes we will use a big one.
> Lets say the bmp image must be more or less 100x100.
Ok, I run a couple on tests on a 128x128 image, compressing it to less
than 500 bytes. None of the results are really usable, regardless of
whether you pick JPEG2000 or JPEG-1. For JPEG-1, the quality level has to
be set to 3 (on a scale of 0..100) and the result looks more or less like
a checkered box. For JPEG2000, the target size can be specified directly,
and the result looks more or less like a blurry blob. Let's put it like
this: Target sizes as small as the one you specified do not leave enough
room to describe even a small image realistically.
So long,
Thomas
| |
| alfred.kidd@gmail.com 2006-03-30, 3:55 am |
| Thanks for the help
It is most appriciated. I will take a look at other encodeing
metohds... wavelet ect..
Kind regards
Alfred
| |
| Jasen Betts 2006-03-30, 7:55 am |
| On 2006-03-29, alfred.kidd@gmail.com <alfred.kidd@gmail.com> 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
> 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.
Bye.
Jasen
| |
| Thomas Richter 2006-03-30, 7:55 am |
| Hi,
> It is most appriciated. I will take a look at other encodeing
> metohds... wavelet ect..
Sorry for not making myself clear enough; what I was trying to say
is that your expectations are unrealistic. I doubt you'll find
*any* compression scheme that returns halfway usable images when
compressing down to this size.
So long,
Thomas
| |
| cr88192 2006-03-31, 7:55 am |
|
"Jasen Betts" <jasen@free.net.nz> wrote in message
news:1f66.442b94a9.59fe0@clunker.homenet...
> On 2006-03-29, alfred.kidd@gmail.com <alfred.kidd@gmail.com> wrote:
>
>
> 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.
>
>
> 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
| |
| Jasen Betts 2006-03-31, 9:55 pm |
| On 2006-03-31, cr88192 <cr88192@NOSPAM.hotmail.com> wrote:
>
> "Jasen Betts" <jasen@free.net.nz> wrote in message
> news:1f66.442b94a9.59fe0@clunker.homenet...
> 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.
>
>
> 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...
>
what does xface use? it's only 48x48 x 1bpp but compresses a reasonable
likeness of me to ~280 printable ascii characters (base 96 encoding?)
half the battle is getting a good 1bpp imagem, (Floyd-steinberg dither helps
with that)
> 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, ...).
gzip (or bzip2) with a pre-loaded tables ?
Bye.
Jasen
| |
| cr88192 2006-04-01, 6:55 pm |
|
"Jasen Betts" <jasen@free.net.nz> wrote in message
news:574d.442d8775.deb1@clunker.homenet...
> On 2006-03-31, cr88192 <cr88192@NOSPAM.hotmail.com> wrote:
<snip>[color=darkred]
>
>
> what does xface use? it's only 48x48 x 1bpp but compresses a reasonable
> likeness of me to ~280 printable ascii characters (base 96 encoding?)
> half the battle is getting a good 1bpp imagem, (Floyd-steinberg dither
> helps
> with that)
>
dunno.
48x48 is a little larger that 36x36.
64x72 looked quite a bit better than 36x36, even though not even doubling
the resolution (64x72 looked passable for identification purposes, 36x36 was
imo not). note all this was still with full precision.
>
> gzip (or bzip2) with a pre-loaded tables ?
>
gzip: maybe, doubtful though (for individual images), as the natural
overhead is unlikely to be acceptable (for lz77, problem is, there is very
little data to try to compress, and unlikely in a form that can be
effectively used...). deflate, in general, needs to store the huffman
tables, which is likely to be too expensive in this case.
bwt: I doubt it would be able to do much of anything useful in this case...
plain arithmetic coding (of filtered results) may give the best results here
(one can initially use some default statistics for the image, or use a fixed
model).
if anything, a custom algo...
>
> Bye.
> Jasen
| |
|
|
| alfred.kidd@gmail.com 2006-04-12, 3:55 am |
| Ok people
Last w I successfully ported the open source JPEG2000 code to eVc++.
I played around with the compression parameters and found a way to
compress a 200x250 image to 500 bytes exactly. Although the quility is
20% to 30% worse than other products on the market. For now I will use
the opensource code. And if the project is succesfull... Maybe buy
something better.
Thanks
A
Nicolas wrote:
> alfred.kidd@gmail.com a =E9crit :
>
> Maybe you can try this :
>
> http://www.letitwave.com/index.php?...page=3Did_phot=
o_codec.htm
>=20
> Nicolas
|
|
|
|
|