Image compression...
Airpalaz
I have this little problem,
I have to produce a screenshot with very higth frequency,
and I have a bad CPU (533 Mhz MAX).
When I make a ScreenShot, I obtain a bitmap image;
I want to make a little compression (beacuse I want to send them on the
Net).
Actually I use a PCX compression,
and it make compression of m image in 0.7 sec.
Exist a more ligth and speed algoritm ?? (only in compression)
Thanks a lot
Byez
Airpalaz
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
user
> Hi, I'm Andrea,
> I have this little problem,
> I have to produce a screenshot with very higth frequency,
> and I have a bad CPU (533 Mhz MAX).
> When I make a ScreenShot, I obtain a bitmap image;
> I want to make a little compression (beacuse I want to send them on the
> Net).
> Actually I use a PCX compression,
> and it make compression of m image in 0.7 sec.
>
> Exist a more ligth and speed algoritm ?? (only in compression)
>
> Thanks a lot
> Byez
> Airpalaz
>
.jpg ??
--
--
700+ Radio Stations on SW http://swstations.tk/
Shortwave transmissions in English, Francais, Nederlands, Deutsch,
Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish,
Portuguese, ...
http://radiolanguages.tk Updated every month or so ....
[Jongware]
> Hi, I'm Andrea,
> I have this little problem,
> I have to produce a screenshot with very higth frequency,
> and I have a bad CPU (533 Mhz MAX).
> When I make a ScreenShot, I obtain a bitmap image;
> I want to make a little compression (beacuse I want to send them on the
> Net).
> Actually I use a PCX compression,
> and it make compression of m image in 0.7 sec.
>
> Exist a more ligth and speed algoritm ?? (only in compression)
That's not extremely fast, 0.7 sec to package an image. What software
are you using?
PCX is an extremely simple (and therefore fast) compression -- it's a
simple Run-length encoding, using (from memory) index #192 as the toggle
between copying and repeating. You can't get any lighter than that.
However, PCX -- in its native form -- is a 256-color format. Possibly
your screenshots are in high or true color mode and have to be
downgraded to 256 colors, and THAT can be a costly operation.
And obviously size does matter. Is your screen 640x480, or larger? Do
you need every single image to be a complete grab, or can you send one
complete image, followed by just the changes?
[Jw]
Kaba
> However, PCX -- in its native form -- is a 256-color format. Possibly
> your screenshots are in high or true color mode and have to be
> downgraded to 256 colors, and THAT can be a costly operation.
Let's correct that:) I use PCX myself as my only output format. It
supports the following formats (bpp = bits per pixel):
1 bpp for black/white images
4 bpp for 16 color images using a palette
8 bpp for 256 color images using a palette
24 bpp for (8, 8, 8)-bit rgb images.
They are all 'native forms' per their file format specification.
http://www.qzx.com/pc-gpe/pcx.txt
It is true that the rgb format was added only for the latest version 5
of the specification in 1991, but that's a long time ago:)
It would seem logical that 2 bpp would be supported as well, but no
image program seems to do this.
Airpalaz
> That's not extremely fast, 0.7 sec to package an image. What software
> are you using?
> PCX is an extremely simple (and therefore fast) compression -- it's a
> simple Run-length encoding, using (from memory) index #192 as the toggle
> between copying and repeating. You can't get any lighter than that.
> However, PCX -- in its native form -- is a 256-color format. Possibly
> your screenshots are in high or true color mode and have to be
> downgraded to 256 colors, and THAT can be a costly operation.
> And obviously size does matter. Is your screen 640x480, or larger? Do
> you need every single image to be a complete grab, or can you send one
> complete image, followed by just the changes?
> [Jw]
My screen is 1280x1024,
24 bit color...
This is the problem...
I can send just the change,
but it's very frequently the change of all image.
Probably I find something doesn't exist...
I can spend much time of PCX only if I obtain much compression (very much
with low cost of CPU). Beacuse I want to trasmit the image on the net.
Example:
For compress image PCX I spend 0.7 sec = 560 Kb
Another format 0.9 sec = 200 Kb .... it's better...
Do you have some suggestion ??
(and if it's possible a link of a brunch of code)
Thanks ALL
Airpalaz
> It is true that the rgb format was added only for the latest version 5
> of the specification in 1991, but that's a long time ago:)
> It would seem logical that 2 bpp would be supported as well, but no
> image program seems to do this.
I use 1280x1024, 24 bbp...
I can spend much time of PCX only if I obtain much compression (very much
with low cost of CPU). Beacuse I want to trasmit the image on the net.
Example:
For compress image PCX I spend 0.7 sec = 560 Kb
Another format 0.9 sec = 200 Kb .... it's better...
Do you have some suggestion ??
(and if it's possible a link of a brunch of code)
--
Airpalaz
> ..jpg ??
I think it's not Ok,
it's not lighter for my CPU,
but, I can try..
have you a link with brunch of code for creating a JPG image ???
Thanks a lot
[Jongware]
> [Jongware] wrote:
>> However, PCX -- in its native form -- is a 256-color format. Possibly
>> your screenshots are in high or true color mode and have to be
>> downgraded to 256 colors, and THAT can be a costly operation.
>
> Let's correct that:) I use PCX myself as my only output format. It
> supports the following formats (bpp = bits per pixel):
>
> 1 bpp for black/white images
> 4 bpp for 16 color images using a palette
> 8 bpp for 256 color images using a palette
> 24 bpp for (8, 8, 8)-bit rgb images.
>
> They are all 'native forms' per their file format specification.
>
> http://www.qzx.com/pc-gpe/pcx.txt
>
> It is true that the rgb format was added only for the latest version 5
> of the specification in 1991, but that's a long time ago:)
And it's *still* using the original RLE compression? (With amendments
for 24bpp etc). That wouldn't come far with a typical photo (altho'
typical screenshots of programs would work fine, I guess).
[Jw]
Kaba
> And it's *still* using the original RLE compression? (With amendments
> for 24bpp etc). That wouldn't come far with a typical photo (altho'
> typical screenshots of programs would work fine, I guess).
Yes. For a scanline, it first stores the reds, then greens and then
blues. Scanlines are then encoded with RLE.
I agree that such a compression scheme is quite useless with real-world
photos. For example, a photo I picked up on my computer which takes
20.25 Mb uncompressed (or BMP), takes 20.95 Mb in PCX format. However,
the positive thing is that the PCX is only marginally larger (in
percentage) than the uncompressed image.
Kaba
> I use 1280x1024, 24 bbp...
> I can spend much time of PCX only if I obtain much compression (very much
> with low cost of CPU). Beacuse I want to trasmit the image on the net.
> Example:
> For compress image PCX I spend 0.7 sec = 560 Kb
> Another format 0.9 sec = 200 Kb .... it's better...
>
> Do you have some suggestion ??
> (and if it's possible a link of a brunch of code)
Nope:)
But I was wondering how much time you have to send a single image end-
to-end?
Airpalaz
> Nope:)
Tipically, I use a 64Kb packet,
the time is = (latency time) X (num_packet)
in the future, I can use much great packet,
and the problem is much visible (beacuse the net wait a compression).
Now I try to dowgrade my image in 8 bbp (256 color).
In teory this reduce a speed in factor near 1/3....
I no have another idea...
DO you have another ???