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:

schem-1_8

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:

quasi-schem-1_1

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

quasi-schem-1_9

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.

Continue reading Web-Optimizing Lossless Images

IRISNotes Digital Pen

There exist so-called Digital Pens, which will record what they are writing electronically, while writing on paper. These pens belong to two categories:

  1. The kind that require special paper.
  2. The kind that require a receiver be attached to the top of the sheet, which senses the positions of the pen during writing, but which do not require special paper.

The is a digital pen of the second kind, of which I happen to own one.

In general, I do not find this type of pen very useful, because the need does not arise often, to be writing on paper, yet to be digitizing what is written anyway. However, I have this pen, and have in the past installed Windows software to download its writings onto my PC.

I felt that it would be a challenge to get this relic to work again, while using Linux software to download its data. For that purpose, it was helpful to note, that the hardware is of the ‘‘ variety, regardless of how it was branded. And then it was easy to find a special, Linux, software-project, the aim of which was to do exactly that.

This software only comes in binary form, packaged for Ubuntu. Using Debian, we do not have a mechanism for PPAs. And so the only way for me to get it running, was to custom-compile it, which I easily did.

Aside from custom-compiling, I needed to create the following file:

 


/etc/udev/rules.d/50-hidraw.rules :

ACTION=="add", KERNEL=="hidraw*", MODE="0666"


 

I should note that my version of pen is first-generation. I cannot guarantee that any of this will work with an or an -type pen. I just happened to own a pen which was collecting dust, with the idle thought of wanting to reactivate it.

The version of this pen which I have, has two modes of operation: USB-mode and Bluetooth-mode. The BT-mode has always been rather pointless, because it would need an active wireless connection while I was writing. It was originally meant to work with Android and iOS devices, but lacked in performance.

The ability to download pages of writing that are saved in the receiver-module, has always been limited to working in USB-mode.

And so I am happy to announce, that my project was a success, and that I am able to use the command-line tool to convert captured data to SVG (image) files.

The ability to do OCR on the writing has always required Windows or OS/X, and under Linux, whatever ability we want, to convert the SVG drawings to text, must be supplied by the user or not at all. I am not that far along with it yet.

Continue reading IRISNotes Digital Pen