Images @ OpenBSD.

David Walker <[email protected]>
Newsgroups gmane.os.openbsd.www
Message-ID <[email protected]>
Bonjour.

If there's interest, I can convert the images at the website to PNG
(i.e. from GIF and JPEG to PNG).

Why?
* I have a slowish broadband connection. I get the red x when loading
pages with lots of images (i.e. lyrics). On dial up it will obviously
be worse.
*  On one common browser Superfish (4.8) consistently fails to load
even by itself. This image is quite large but I think there is another
reason

Proposal:
* PNG is the open standard designed as a replacement for GIF. I'm not
one of these "lets change the page to 2010" people for the sake of it.
I think working on simpler and/or older browsers is worthwhile. In
this case PNG is a commodity format and in the spirit of standards and
optimization.
From Wikipedia:
"Portable Network Graphics (PNG) was designed as a replacement for the
GIF format in order to avoid infringement of Unisys' patent on the LZW
compression technique. PNG offers better compression and more features
than GIF ... PNG is more suitable than GIF in instances where
true-color imaging and alpha transparency are required."
There are a few caveats with PNG - notably it is unsupported on some
older browsers. I am confident in saying that considering there is no
transparency on any images at OpenBSD that any browser since the late
90's will be fine. However, I don't use all browsers and am happy to
be corrected.
I notice that some of the images (especially the larger ones with
gradients) are in JPEG format. This is probably due to GIFs inability
to do more than 8bpp - they would look a little "blocky". However,
unlike GIF, PNG does "true colour" (48bit); and unlike JPEG is
lossless. It will do what either of these on their own cannot do and
makes a smaller file size at the same time. I tried (on a handful of
candidates besides the examples below).

Results:
* On the hackathons page where almost exclusively the images don't
contain gradients and have a small palette, even without reducing the
palette, the filesize reductions are on the order of 25%.
* On the lyrics page even without indexing the palette (i.e. using
true colour) this will shave off 5% to 10% off the image size. This
will get the JPEGs into PNG and allow for a faster load.
* Much of the smaller artwork is in GIF format with large file sizes.
A direct replacement to PNG does not produce worthwhile results.
However, indexing the palette produces savings and again, gets
everything in one format.
* Some of the smaller artwork is in JPEG format with overly large file
sizes. Conversion to PNG with an indexed palette yields significant
benefit.

Example:
http://www.openbsd.org/images/ElPuffiachi.jpg

JPEG: 129,594 bytes
PNG (256 colour palette): 42,010 bytes)

~ 32% of the original filesize.

How does it look?
http://www.users.on.net/~diw/openbsd/png_versus_jpg_and_gif_test.html

Notes:
I haven't tested on too many browsers right now. My work environment
is limited at the moment. If there's interest I'll check and then
offer to convert every image.

Extra:
It looks like during the "shrinking" process from the large artwork to
the thumbnails on the hackathons page (have a look and click on one of
the images) that there is degradation of the quality.
E.g. compare:
http://www.openbsd.org/images/hackathons/f2k9-s.gif
http://www.openbsd.org/images/hackathons/f2k9.gif
It is reasonable to do this "shrinking" without losing so much detail,
converting to PNG and getting a smaller file size.
Again:
http://www.users.on.net/~diw/openbsd/png_versus_jpg_and_gif_test.html
Yep, it's a marginally smaller filesize also.
The n2k10 conversion also results in a smaller filesize.

Anyway, there may be some reason I may have missed to not use PNG
(i.e. an unsupported browser), if so, let me know.

http://www.libpng.org/pub/png/pngintro.html

Best wishes.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.