# Web-Optimizing Lossless Images

One subject which has caught my interest in recent times, is how to publish lossless images on the Web – and of course, optimize memory-use.

It has been a kind of default setting on most of my desktop software, that I’ll either save images as JPEGs – that are lossy but offer excellent file-sizes – or as PNG-Format files – that are losssless, but that still offer much better file-sizes than utterly uncompressed .BMP-Files would offer. Yet, I might one day want even smaller file-sizes than what PNGs can offer, yet preserve the crisp exactitude required in, say, schematics.

The ideal solution to this problem would be, to publish the Web-embedded content directly in SVG-Files, which preserve exact curves literally at any level of magnification. But there are essentially two reasons fw this may not generally be feasible:

1. The images need to be sourced as vector-images, not raster-images. There is no reasonable way to convert rasters into vector-graphics.
2. There may be a lack of browser-support for SVG specifically. I know that up-to-date Firefox browsers have it, but when publishing Web-content, some consideration needs to be given to older or less-CPU-intensive browsers.

And so there seems to be an alternative which has re-emerged, but which has long been forgotten in the history of the Web, because originally, the emphasis was on reducing the file-size of photos. That alternative seems to exist in GIF-Images. But there is a basic concern which needs to be observed, when using them: The images need to be palletized, before they can be turned into GIFs – which some apps do automatically for the user when prompted to produce a GIF.

What this means is, that while quality photos have a minimum pixel-depth of either 24 or 32 Bits-Per-Pixel (‘BPP’), implying 8 Bits Per Channel, and while this gives us quality images, the set of colors needs to be reduced to a much-smaller set, in order for GIFs actually to become smaller in file-size, than what PNG-Files already exemplify. While 8-bit-palletized colors are possible, that offer 1/255 colors, my main interest would be in the 4-bit or the 1-bit pallets, that either offer the so-called ‘Web-optimized’ standard set of 16 colors, or that just offer either white or black pixels. And my interest in this format is due to the fact that the published images in question are either truly schematic, or what I would call quasi-schematic, i.e. schematic with colors.

What this means for me as a writer, is that I must open the images in question in GIMP, and change the ‘Image -> Mode’ to the Web-optimized, or the 1-bit Pallets, before I can ‘Export To GIF’, and when I do this, I take care to choose ‘Interlaced GIF’, to help browsers deal with the memory-consumption best.

In the case of a true 1-bpp schematic, the effect is almost lossless, as the example shown below has already occurred elsewhere in my blog, but appears as sharp here as the former, PNG-formatted variety appeared:

In the case of a quasi-schematic, there is noticeable loss in quality, due to the reduction in color-accuracy, but a considerable reduction in file-size. The lossless, PNG-format example is this:

While the smaller, GIF-format File would be this:

There is some mention that for larger, more-complex schematics, GIFs take up too much memory. But when the image really has been large in the past, regardless of what I might like, I’ve been switching to JPEGs anyway.

There could be some controversy, as to whether this can be referred to as lossless in any way.

The answer to that would be, that this results in either 1 or 4 bit-planes, and that the transmission of each bit-plane will be without alteration of any kind – i.e., lossless. But there will be the mentioned loss in color-accuracy, when converting the original pixel-values to the simplified colors – i.e. lossy.

Now I suppose that one question which the reader might be thinking is, ‘Why not just palletize to 1 BPP, and then export to TIFF-Format, with Deflate Compression?’ My answer would be that when given this sort of image, the client-program will try not to consume more than 1 BPP internally, and this shuts off any anti-aliasing which is supposed to take place, and which the viewer-application would normally perform, at full color-depth. After all, TIFF-Format is also supposed to be a ‘Raw Format’, implying a device-compatible format, and defaults to 32-bit, even if the Alpha Channel is not being used.

The strong aliasing which the readers would see at 1 BPP, is unacceptable.

Here are some practical file-sizes:


-rw-r--r-- 1 dirk dirk  5924624 Aug 25 17:37 EngineeredObj-1_1.jpg
-rw-r--r-- 1 dirk dirk 18738929 Aug 25 17:37 EngineeredObj-1_2.png
-rw-r--r-- 1 dirk dirk 47616890 Aug 25 17:37 EngineeredObj-1_3.bmp
-rw-r--r-- 1 dirk dirk 29984855 Aug 25 17:37 EngineeredObj-1_4.bmp.gz
-rw-r--r-- 1 dirk dirk     8692 Aug 26 00:49 Quasi-Schem-1_10_Magick.gif
-rw-r--r-- 1 dirk dirk    22948 Aug 25 17:37 Quasi-Schem-1_1.png
-rw-r--r-- 1 dirk dirk   298922 Aug 25 17:37 Quasi-Schem-1_2.bmp
-rw-r--r-- 1 dirk dirk    16207 Aug 25 17:37 Quasi-Schem-1_3.bmp.gz
-rw-r--r-- 1 dirk dirk     7277 Aug 26 00:19 Quasi-Schem-1_9_GIMP.gif
-rw-r--r-- 1 dirk dirk    16598 Aug 25 17:37 Schem-1_1.png
-rw-r--r-- 1 dirk dirk  1140602 Aug 25 17:37 Schem-1_2.bmp
-rw-r--r-- 1 dirk dirk    14970 Aug 25 17:37 Schem-1_3.bmp.gz
-rw-r--r-- 1 dirk dirk    16734 Aug 25 18:33 Schem-1_7.pdf
-rw-r--r-- 1 dirk dirk     9362 Aug 26 00:19 Schem-1_8_GIMP.gif
-rw-r--r-- 1 dirk dirk     3777 Aug 26 00:41 Schem-1_9_Magick.gif



Hint: When trying to use ImageMagick, it’s important to use ‘-depth 4′ or ‘-depth 1′ , instead of ‘-colors 15′ or ‘-colors 2′.

(Edit 08/26/2017 : I think that when we use ‘-colors 15′ , ImageMagick tries to apply a strategy by which more-exact colors are approximated, by ‘fuzzing’ the reduced color-palette. In the case of schematics, this is the opposite of what’s needed. If on the other hand I give the command-line parameter ‘-depth 4′ , then I’ve fooled ImageMagick out of doing this for the moment, so that only thresholds are used to determine the palletized colors. This effect was most-noticeable with ‘-colors 2′ . )

When I select ‘Web-optimized palette’ within GIMP, the option is checked by default, to remove unused colors. Apparently, ImageMagick has the equivalent capability with ‘-depth 3′ .

(Edit 08/26/2017 : )

I should add, that since the question has been asked elsewhere on the Internet, of How to perform batch-conversion of files using ImageMagick – since ImageMagick has no facility to do this in its own command-line – the answer could come in the form of a shell-script such as the one below:


#!/bin/bash

for f in *.png
do

convert $f -depth 3  echo$f | sed 's/.png/.gif/g'

done




If conversion to different formats is required, of course we can always change Line 7 above, to specify what conversion.

Dirk

This site uses Akismet to reduce spam. Learn how your comment data is processed.