i found this while reading the discussion on /. about GIF patents. I'm a
proponant of png's, and i always hate it when the size of png's is used as
an argument for using jpg's instead (and then see jpg's posting to p.b.i
that are greater than 300k). Generally, GIMP seems to do a decent job of
keeping png sizes down, but this might be usefull for some. i havn't tried
it yet. have you?

http://pmt.sourceforge.net/pngcrush/

Post a reply to this message

Ross <rli### [at] everestkcnet> wrote:
> i found this while reading the discussion on /. about GIF patents. I'm a
> proponant of png's, and i always hate it when the size of png's is used as
> an argument for using jpg's instead (and then see jpg's posting to p.b.i
> that are greater than 300k). Generally, GIMP seems to do a decent job of
> keeping png sizes down, but this might be usefull for some. i havn't tried
> it yet. have you?

  I have.

  What pngcrush does is to test (by default) most common zlib compression
settings or all of them (with an option) to see which one of them
compresses the given image the best.

  Compared to the maximum png compression of most programs (eg. gimp)
pngcrush compresses the file 0-5% smaller. In a few special cases it
can compress even more, like 10-20%, but this is quite rare.

  Being a lossless image format PNG can't compete with JPEG in compression
when storing photographs or other similar images. It can only compete
with line-drawing-type images, cartoony images (which don't have color
gradients) and such. Also if the image can be represented well with 256
colors then a 256-color png can often compete with a jpg (but not always).

  When I take png snapshots of things I always recompress with pngcrush
because that 1-5% is still better than nothing... :)

-- 
#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

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

>   Being a lossless image format PNG can't compete with JPEG in compression
> when storing photographs or other similar images. It can only compete
> with line-drawing-type images, cartoony images (which don't have color
> gradients) and such. Also if the image can be represented well with 256
> colors then a 256-color png can often compete with a jpg (but not always).

However, for intermediate images during processing, the lossless 
compression and 16 bit depth available in PNG make it far superior to 
JPEG. I usually render to 16 bit PNG, I can reduce it later if 
necessary, and the extra precision is useful for any post adjustments.

However, my preferred format is actually TIFF...LZW compressed TIFF has 
performed better than PNG in my tests. The Unisys patents have expired, 
leaving only the patent belonging to IBM, which from what I've read 
doesn't apply to image formats. (Correct me if I'm wrong here...but in 
any case, *that* patent's going to expire soon as well. If IBM did try 
to push it for some insane reason, they wouldn't get much benefit out of 
it.)

Anyway, aside from the compression, TIFF supports an arbitrary number of 
channels, image layers, floating point and logarithmic encodings in 
several levels of precision, and many more features.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> However, my preferred format is actually TIFF...LZW compressed TIFF has 
> performed better than PNG in my tests.

  When I have tested 256-color images zlib has clearly a better compression
ratio than lzw. I haven't tested with true color images, though.

-- 
#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

There's another png recompression utility out there:
http://advancemame.sourceforge.net/comp-download.html

  I compared it to pngcrush with four images.
  What I did was to take the image to gimp, save it to png, and then I
recompressed the gimp-generated image with pngcrush and advpng. I used
the maximum compression settings in all three programs:


  POV-Ray for Windows snapshot (full color):
  http://www.cs.tut.fi/~warp/snaps/pngcomptest/povsnap.png

    Gimp: 33335
pngcrush: 24281
  advpng: 21537


  POV-Ray for Windows snapshot (256 colors, no dithering):
  http://www.cs.tut.fi/~warp/snaps/pngcomptest/povsnap256.png

    Gimp: 16862
pngcrush: 16845
  advpng: 15371


  Chess image (full color):
  http://www.cs.tut.fi/~warp/snaps/pngcomptest/chess.png

    Gimp: 416401
pngcrush: 410235
  advpng: 416401 (no change)


  Chess image (256 colors with dithering):
  http://www.cs.tut.fi/~warp/snaps/pngcomptest/chess256.png

    Gimp: 202560
pngcrush: 198917
  advpng: 187830

-- 
#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