## Dealing with a picture frame that freezes.

I recently bought myself a (1920×1080 pixel) digital picture frame, that had rave reviews among other customers, but that began the habit of freezing after about 12 hours of continuous operation, with my JPEG Images on its SD Card.

This could signal that there is some sort of hardware error, including in the internal logic, or of the SD Card itself. And one of the steps which I took to troubleshoot this problem was, to try saving the ‘.jpg’ Files to different SD Cards, and once even, to save those pictures to a USB Key, since the picture frame in question accepts a USB Memory Stick. All these efforts resulted in the same behaviour. This brought me back to the problem, that there could be some sort of data-error, i.e., of the JPEG Files in question already being corrupted, as they were stored on my hard drives. I had known of this possibility, and so I already tried the following:


find . -type f -name '*.jpg' | jpeginfo -c -f - | grep -v 'OK'



Note: To run this command requires that the Debian package ‘jpeginfo’ be installed, which was not installed out-of-the-box on my computer.

This is the Linux way to find JPEG Files that Linux deems to be corrupted. But, aside from some trivial issues which this command found, and which I was easily able to correct, Linux deemed all the relevant JPEG Files to be clean.

And this is where my thinking became more difficult. I was not looking for a quick reimbursement for the picture frame, and continued to operate on the assumption that mine was working as well, as the frames that other users had given such good reviews for. And so, another type of problem came to my attention, which I had run in to previously, in a way that I could be sure of. Sometimes Linux will find media files to be ‘OK’, that non-Linux software (or embedded firmware) deems to be unacceptable. And with my collection of 253 photos, all it would take is one such photo, which, as soon as the frame selected it to be viewed, could still have caused the frame to crash.

(Updated 1/16/2020, 17h15 … )

## 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.