Larry’s Personal & Tech ramblings

“Micro_View” is a product I created several years ago for a client.  It’s a simple imaging library for Win32 and WinCE which allows you to load BMP, GIF and JPEG images into a HBITMAP or it can display them in a window.  The code is fast and small (the Win32 lib file is 96K).  I created a stand-alone command-line driven executable which displays an image in a borderless window and a link library which has 3 functions defined:

int APIENTRY MicroView(TCHAR *filename, int iOptions);
int APIENTRY MVLoadBitmap(TCHAR *filename, HBITMAP *, HPALETTE *);
int APIENTRY MVLoadResource(HINSTANCE hInst, TCHAR *rname, HBITMAP *pBitmap, HPALETTE *pPalette);

If you need to add simple image handling to your application, it doesn’t get much easier than this.  This is something that’s been collecting dust on my harddrive for quite a while, but would probably make a pretty good retail product.  I will see if I can package this up into a reasonably priced product in the next few days.  Please email me (bitbank@pobox.com) if you’re in need of such a library.

It’s taken a lot longer than expected to release the latest version of my image viewer. Many other projects have gotten in the way, but I’ve finally wrapped up version 4 of PQV. The sales pages on Handango and PocketGear are not quite working yet, but the PayPal link works. The $14.99 license is per user, not device. A single license allows you to use the viewer on all your Windows Mobile devices and Windows Desktop. Here’s the new product page:

PQV 4.0

When you install the Pocket PC or SmartPhone versions, the Desktop PC version also gets installed.

The great thing about the ARM architecture is that the more I look at a piece of code, the more ways I find to optimize it. The conditional execution, barrel shifter and optional setting of the processor flags create many opportunities for optimization. I’ve spent some more time optimizing my ARM asm JPEG code and now have some hard numbers to publish. I used a HP iPAQ h2210 Pocket PC (400Mhz PXA255) and a HTC Hurricane SmartPhone (195Mhz OMAP 850) to do the testing. I was able to load the file from RAM on the Pocket PC (to reduce file I/O delays), but not on the SmartPhone. The SmartPhone file system does not use RAM for file storage. The slow speed of reading from the miniSD card overtakes the amount of processing time in the tests, so the only test that was run on the SmartPhone was decompressing a 160×120 thumbnail image in RAM. All tests were to decompress the image to a RGB565 bitmap. The thumbnail test decompresses the 160×120 EXIF thumbnail image. The “DC only” test creates a single pixel from each MCU (the 3072 x 2304 image is loaded as 384×288). The “Full res” test decompresses every pixel of the image.

PPC: thumbnail: 8.8 milliseconds, DC only: 830 milliseconds, full res: 2700 milliseconds.
SP: thumbnail: 15.1 milliseconds

The speed difference between the two devices is to be expected considering the different processor and memory bus speeds. The “DC only” test is useful because it shows the relative speed of Huffman decoding. The file size is 4.3MB, so in 830 milliseconds the code was able to decode all of the MCUs and produce a single pixel from each one.

I’ve uploaded the sample image to my web server here: CIMG2209.JPG

The image was taken with a Casio EX-Z750 and depicts a relatively complex scene with many fine details. Like most cameras, the Elixim series saves JPEG images with 2:1 horizontal color subsampling (when set to maximum quality). It’s not unreasonable for a point-and-shoot camera like the Z750 to save images at a less than optimal compression because the image coming off the CCD isn’t that great to begin with. What irks me is that cameras like the Canon 20D do the same thing. With a good SLR lens and imager, the Canon should allow you to save full res color JPEG images.

Comments?