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
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.
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?
> 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.
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.
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.
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.
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
Oh, I forgot to include the link to my exmplae page: http://blogg.huftis.org/arkiv/2005/05/17/192/
> 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.
(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.
> 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.
> 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.
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
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
resolved by the introduction of cchost...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.