Bug 3347 - PNG files not optimized
PNG files not optimized
Status: CLOSED FIXED
Product: openclipart.org
Classification: Unclassified
Component: clipart
unspecified
All All
: high enhancement
Assigned To: default user for a product
:
Depends on: 3225
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-19 21:35 UTC by matt
Modified: 2006-09-06 20:13 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description matt 2005-05-19 21:35:48 UTC
PNG compression output from inkscape is about 30% inefficient.  Using a more
powerful library for compression such as pngout will allow for a better
compression ratio while maintaining the lossless quality of the PNG format.  

Decreasing the file size will save on bandwith costs down the road as well as
storage space, especially as the library grows.  (this is easiest realized on
the website catalog but will significantly impact the download of the
openclipart.org library.)

Statistics: png's in the library account for approx. 15 MB.  These can be shrunk
to about 12 mb using pngout.  Individual files will lose about 1-2 kb each (20-40%)

article on the subject: http://www.twilightuniverse.com/2003/09/ping/
pngout for linux: http://jonof.edgenetwork.org/?p=pngout
Comment 1 Nathan Eady 2005-05-20 10:25:53 UTC
I see about three ways to triage this:
1. Punt: It's an Inkscape issue, not an OCAL issue.
2. Table it until we figure out the other thumbnail-generation issue,
   namely, bug 3225
3. Work on it now.

I tend to prefer option 2.  Marking dependency.
Comment 2 Jonathan Leighton 2005-05-20 10:33:09 UTC
I'm more in favour of option one -- making it a dependency doesn't actually
solve the issue, it just puts it aside. Also, if Inkscape used better
compression, then lots of people would benefit, rather than just OCAL.

Perhaps a bug should be filed against Inkscape?
Comment 3 Nathan Eady 2005-05-20 10:58:24 UTC
> I'm more in favour of option one -- making it a dependency doesn't
> actually solve the issue, it just puts it aside.

Except that one of the proposed solutions for bug 3225 is to use something
besides Inkscape to generate the thumbnails.  There has also been a proposal
to have the thumbnails generated at upload time, using a library or tool for
that purpose (not Inkscape).  Some if this was discussed on the mailing list,
before we had a bugzilla component.  If either of those is implemented, the
Inkscape issue no longer would directly impact OCAL.

Of course, filing a bug against Inkscape doesn't hurt anything, since
arguably Inkscape itself would be improved by exporting more optimal PNGs,
but that may not matter directly for OCAL.
Comment 4 Andrew Archibald 2005-05-20 11:03:02 UTC
A simple solution would be to run pngcrush over all the images. This has the
same effect and avoids having to wait for inkscape to improve.
Comment 5 Nathan Eady 2005-05-20 11:10:51 UTC
The generate-thumbnails tool could be made to incorporate (or largely consist
of) whatever we do in bug 3225 and here, and yes, we could just run it over all
the images.
Comment 6 Andrew Archibald 2005-05-20 22:15:31 UTC
This bug could readily be fixed with a single-line change to
generate-thumbnails.pl if one of the programs pngcrush, optipng, or pngout were
installed on the server.  The first two are definitely packaged for Debian; the
last is supposedly (according to the author) the most efficient.
Comment 7 Karl Ove Hufthammer 2005-05-20 23:51:08 UTC
The best program to use, is OptiPNG. And it's actually better (more
user-friendly) to make the files slightly larger, by using Adam7 interlacing.

Adam7 is a technique where the user can see a (low-resolution) version of the
(entire, undistorted) image as soon as 1/64 is downloaded. This is gradually
improved as 1/32, 1/16, 1/8, 1/4, 1/2 and the rest of the image is downloaded --
all in all 7 passes.

This is much more user-friendly for low-bandwidth users than making the images
even smaller by not using Adam7. (The downloadable archives should use
OptiPNG-optimised images without Adam7 interlacing.) Adam7 is well-supported by
browsers (though IE uses a rather stupid rendering algorithm).

Here are some images domonstrating and explaining Adam7:

http://www.schaik.com/png/adam7.html
http://nuwen.net/png.html

And here's my own page, showing all 7 Adam7 passes on a couple of the
OpenClipart.org images (the smiley and the four-leaf clover). The actual page is
in Norwegian, but the images should speak for themselves.

This is the command which should be run on the files to get interlacing and
(almost) optimal compression:

optipng -o7 -i1 filename.png
Comment 8 Karl Ove Hufthammer 2005-05-20 23:54:06 UTC
Oh, I forgot to include the link to my exmplae page:

http://blogg.huftis.org/arkiv/2005/05/17/192/
Comment 9 Nathan Eady 2005-05-23 11:21:52 UTC
> if one of the programs pngcrush, optipng, or pngout were installed 
> on the server

At this time, what's installed on the server is almost totally irrelevant.
Thumbnails are not generated on the server.  There has been talk of having
thumbnails generated at upload time, but at this time that is very much 
LATERed, as there are substantially more important changes that need to be 
made to the upload facility, e.g., to correctly handle non-ASCII characters
in the metadata being added.

> The best program to use, is OptiPNG. And it's actually better (more
> user-friendly) to make the files slightly larger, by using Adam7

I do not understand how the technical details of how the images are 
internally encoded could possibly make any difference whatsoever in terms
of user-friendliness.  End users do not know or care about that stuff.
Making the download filesize smaller is the only difference I can
possibly imagine improved PNG optimization making to the end user.

> This is much more user-friendly for low-bandwidth users than making the
> images even smaller by not using Adam7.

I especially don't understand how larger filesizes improves anything
for low-bandwidth users.  Please explain.
Comment 10 Andrew Archibald 2005-05-23 13:35:02 UTC
(In reply to comment #9)
> > if one of the programs pngcrush, optipng, or pngout were installed 
> > on the server
> 
> At this time, what's installed on the server is almost totally irrelevant.
> Thumbnails are not generated on the server.  There has been talk of having
> thumbnails generated at upload time, but at this time that is very much 
> LATERed, as there are substantially more important changes that need to be 
> made to the upload facility, e.g., to correctly handle non-ASCII characters
> in the metadata being added.

So, just to be sure: who runs generate_thumbnails.pl? It would be simple to add
a line calling any of optipng, pngcrush, or pngout, provided the user has them
installed. 

> > The best program to use, is OptiPNG. And it's actually better (more
> > user-friendly) to make the files slightly larger, by using Adam7
> 
> I do not understand how the technical details of how the images are 
> internally encoded could possibly make any difference whatsoever in terms
> of user-friendliness.  End users do not know or care about that stuff.
> Making the download filesize smaller is the only difference I can
> possibly imagine improved PNG optimization making to the end user.
> 
> > This is much more user-friendly for low-bandwidth users than making the
> > images even smaller by not using Adam7.
> 
> I especially don't understand how larger filesizes improves anything
> for low-bandwidth users.  Please explain.

This interlacing scheme renders the images progressive - it becomes possible to
render previews as they are downloaded, so that users can see a lower-resolution
version and abort if this is not the image they want.  

Since our PNGs are 128x128, and Adam7 is by no means universally supported (for
 example, I don't think the python-imaging library can read them at all) I don't
think this interlacing is a good idea. 
Comment 11 Karl Ove Hufthammer 2005-05-24 00:32:26 UTC
> This interlacing scheme renders the images progressive - it becomes
> possible to render previews as they are downloaded,

Exactly.

> Since our PNGs are 128x128, and Adam7 is by no means universally supported

I don't know anything about PIL, but I know Adam7 *is* universally supported by
browsers (i.e. all browser that support ordinary PNGs support Adam7). But of
course, if it's not possible to have differently-encoded for the Web site and
the downloadble archive, using non-Adam7-encoded images may be better.
Comment 12 Jonadab the Unsightly One 2005-05-30 06:41:03 UTC
> So, just to be sure: who runs generate_thumbnails.pl?

Whoever does the release can run it, although I have not been doing so every
time, on the grounds that svg_validate already generates thumbnails.  But it
would not be at all hard to add running generate_thumbnails.pl to the release
procedure.

> But of course, if it's not possible to have differently-encoded for the 
> Web site and the downloadble archive

It's not impossible, but I don't know that it's really a good idea to have
differently-encoded files for the website versus the downloadable packages.
For one thing, that adds significantly to the release process; more 
importantly, it breaks the unstated but nearly universal assumption that the 
files are the same.  There would have to be a pretty good reason, I think.
Comment 13 Patricia FIDI 2006-07-12 13:48:58 UTC
Hi all,

When openclipart starded, few browsers were able to show svg. 
But now, why we don't ask people to upload directly svg clipart in this format :
- in inscape, File --> document property : fill 80px for large side and "ajust
image"

For the release, we won't waste time to do .png files and it will be faster for
publishing all incoming new clipart on OCAL. And we don't need to implement a
library or tool in the upload.

If everybody is OK, I will turn this bug as closed (last message date: 2005-05-30).
Please give me your advice.
Thx, Patricia
Comment 14 Patricia FIDI 2006-07-13 04:56:08 UTC
Hi all,
I've sent an SVG clipart with 80px of large like PNG used in OCAL (name is
headphone in incoming files of http://www.openclipart.org).
At the very beginning of OCAL, browsers couldn't read and show SVG files but now
it's OK for all browsers.
We may ask people to upload only SVG files with 80px of large.
-> less work for us with thumbnails, PNG files...
-> no implementation of library or tool during upload...
(my answer is in bug 3225 and 3347, if everybody is OK, we may closed this old
discussion from 2005)
Patricia
Comment 15 ryanlerch 2006-09-06 18:37:34 UTC
resolved by the introduction of cchost...