"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c968149@news.povray.org...
> Thorsten Froehlich <tho### [at] trfde> wrote:
> > BTW, such a 1 bit GIF is about 11 KB and a 24 bit PNG about 78 KB, so it
could
> > really work!
>
>   I just tried to compress a 4096x4096 image to PNG with pngcrush (using
its
> brute force search for the best compression settings).
>   At 24 bits per pixel the image file is 58540 bytes long, and at 8 bits
> per pixel it's 2131 bytes long.
>
>   (I really wonder why the 24-bit image is so big. Why not three times the
> size of the 8-bit version?)

I'm just guessing but I would suppose that at 8-bit there are larger blocks
of the same color than at 24 bit and larger blocks are easier to compress?
Correct me if I wrong I'm just taking an educated stab here.

Corey

> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -

Post a reply to this message

When compressing to 8 bit, you gain in two respects- one is that you
have a far smaller palette to work with, so you spend about one third of the
space right off the bat.  But another thing happens as well- smaller
"distances" between colors mean that you will have better image compression
ratios.  Take JPG compression for instance.
    If you are familiar with the first term of palette reduction, you can
see that you could create a small table that represents some basic set of
colors and that table might be far smaller than 256 colors in some images.
You might get by with a mere 50 to 70 base colors.  6 bits might be
sufficient to adequately describe your color subset.
    Then, you create the "templates" that a DCT (discrete cosine transform)
might use to describe how an 8x8 cell of the image might be recreated using
some small number of those colors, using three templates that get overlaid
to describe the RGB components.  There are not many such templates used,
thus resulting in a further compression.
    Overall, JPG is lossy exactly because the data is not perfectly
recreated; it is "derived" from some basic selection of colors and then DCT
templates are used to approximate what they looked like.  Other schemes such
as run length encoding are done it other systems.  GIF is a perfect example.
When you go to a small number of colors and then specify that 61 dots
following this one will all be color 46 from the palette, you can see some
immediate benefits right there.
    Of course, each image format has its advantages and disadvantages, and a
truly universal image compression routines would analyze an image and select
the one that gave best compression and lowest loss and then recommend that
file format for your final image.  There's a useful tool to write.

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

Post a reply to this message

In article <3c968149@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   I just tried to compress a 4096x4096 image to PNG with pngcrush (using its
> brute force search for the best compression settings).
>   At 24 bits per pixel the image file is 58540 bytes long, and at 8 bits
> per pixel it's 2131 bytes long.
>
>   (I really wonder why the 24-bit image is so big. Why not three times the
> size of the 8-bit version?)

I was surprised by the size of the 24 bit image as well.  I suppose it is
because the image data internally is handled in such a way that it gives
better results for images with lots of color changes.

Did you try to play with manually setting the compression window size (if the
program you are using allows this)?  Maybe this will give better results...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
>>   At 24 bits per pixel the image file is 58540 bytes long

> Did you try to play with manually setting the compression window size (if the
> program you are using allows this)?  Maybe this will give better results...

  By setting the compression window size to 512 (which seems to be the maximum
zlib supports; the default seems to be 4), the file was reduced to 55976 bytes.
  It's still oddly large.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On 19 Mar 2002 08:17:32 -0500, Warp <war### [at] tagpovrayorg> wrote:
>   By setting the compression window size to 512 (which seems to be the maximum
> zlib supports; the default seems to be 4), the file was reduced to 55976 bytes.
>   It's still oddly large.

I think it's becouse of some kind of dictionary.

ABX

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   By setting the compression window size to 512 (which seems to be the maximum
> zlib supports; the default seems to be 4), the file was reduced to 55976 bytes.

  Curious. I supposed that converting the image to JPG could make it laughably
small. However, no matter what compression settings I use, I can't get it
smaller than the PNG! :-o

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c950837@news.povray.org...
>   This way some of the images will be smaller than the original and some
> will be equal. None of the images will be larger than the original.

This is not also true in all cases. Have you tried to "compress" just one
pixel? or two?
"Compressed" (means represented in some known format) file can be larger
than the original image,
because it also has to store some extra info.

Regards,

Gleb

Post a reply to this message

Gleb <gk1### [at] sotonacuk> wrote:
>>   This way some of the images will be smaller than the original and some
>> will be equal. None of the images will be larger than the original.

> This is not also true in all cases. Have you tried to "compress" just one
> pixel? or two?
> "Compressed" (means represented in some known format) file can be larger
> than the original image,
> because it also has to store some extra info.

  Read my posts again: The idea was that if the compressed file is larger
than the raw file, then just store the image in raw form.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message