Archive | Software review RSS feed for this section

Fast what? The primer on “fast” RAW image viewers

21 Feb

Over the last few years, various RAW viewers have sprung up, all claiming to be “fast” and putting this in their name. No law suits have apparently been filed, so it’s left for us consumers to figure out which is which. I thought you would appreciate a resource that you can return to when you need to know, so here goes.

The candidates presented here are FastStone Image Viewer, FastPictureViewer, and FastRawViewer. Please note that these are not necessarily the fastest RAW viewers out there (I haven’t tested these or any others for that particular aspect). The purpose of this article is just to clear up the potential naming confusion.

FastStone Image Viewer is actually the oldest of the bunch, launching in 2004. It’s a fully featured image viewer that supports many RAW formats, some colour space operations, and a host of editing steps such as cloning, colour correction, curves, cropping, and sharpening. JPEG rotation is lossless in the FastStone viewer. It also has a few fancy functions, such as emailing contact sheets, and is free for personal or educational use. Commercial use is 35 bucks.

FastPictureViewer dates back to 2008. It exists in three editions, but only the most expensive one supports RAW formats (and the most basic one is free). It doesn’t have any editing capability and instead specialises in image rating and selection. It’s 50 bucks for the version that does RAW.

There is also a FastPictureViewer Codec Pack for ten bucks that simply enables fast raw previews in Windows Explorer, nothing more. However, Microsoft also provides its own codec pack for free, so that’s another option to consider.

FastRawViewer is the new kid on the block, entering public beta in 2014, and is made by the folks whose other commercial project is RawDigger and who maintain open source LibRaw (this will only interest software developers), on which FastRawViewer is based. Considering it’s early stages, it has quite a bit of functionality already. It’s even more focused on viewing and analysing, rather than editing, images than FastPictureViewer, and will only set you back 20 dollars for the full version right now.

JPEGmini: The results are deflating

8 Feb

After reading about JPEGmini, which promises to reduce JPEG file size up to five times, I got curious enough to try it. First off, the web-based version didn’t work in any browser I tried. It turns out it’s actually written as a Flash applet, so it should work the same in all browsers. Writing a tool, publishing it, and then not testing it makes you look like one.

Moving on from that pertinent aside, I should briefly explain that the JPEGmini algorithm is advertised as taking into account properties of human visual processing to produce a JPEG file that is visually indistinguishable from the original, but much smaller. That may have well all been true until JPEGmini met the pixelpeeper that is yours truly.

I mostly photograph birds, which are the most challenging class in terms of photographic technology, because they are both prone to moire and aliasing in their feathers, as well as very noticeable loss of detail from unsharp lenses, strong anti-aliasing filters, lossy file compression, etc. Additionally, they are often so colourful that even when correctly exposed overall, they can blow colour channels, again causing loss of detail. However, they were perfect for this test, where preservation of detail was the major concern.

Using images that had been raw-processed into GIMP using UFRaw and then exported at JPEG quality 100, I created a JPEGmini-converted version in a separate folder, and compared the two versions one on top of the other. Images came from a camera with a weak AA filter, and had no resizing applied to them. So I was looking at real, maximum detail, but downsizing with a detail-preserving algorithm could have shown up more severe differences than here reported.

The compressed size using JPEGmini was approximately the same as a GIMP-exported JPEG at quality 78. The GIMP-exported version did a better job of retaining sharpness, and if there was a difference in colour retention, it was not apparent. Hence, in the case of GIMP, reducing quality directly may be a better strategy than re-running the file through JPEGmini. Having said that, I have always been pleased with GIMP’s JPEG output, even at lower quality settings, so beating GIMP may have been an extreme challenge. Whether this hints that GIMP’s own engine may invalidate some of JPEGmini’s patents (by way of prior art), is for others to decide.

As a concluding remark, you may still see benefits from JPEGmini when working with tools other than GIMP, and with cameras that have a stronger AA filter, or with upsampled (digitally enlarged) images. It’s also a good quick fix when you just need to send an image through email or instant messenger, where size may make a huge difference and detail is less important – opening GIMP for these jobs would be much more time-consuming.

Further testing footnotes

Taking the JPEGmini-converted images back into GIMP and saving them again, or resizing, then saving brought the following results. The original JPEG size was 5.6MB, the minified size was 890kB, a version regimped at GIMP’s suggested 90 setting was 1MB, at 100 it was 2.4MB. If we assume that the GIMP JPEG compression algorithm doesn’t benefit from looking over JPEGmini’s shoulder (and hence manage to compress better just because someone else has shown the way), we’d have to take this a very rough indication that roughly 60% of actual JPEG detail is lost when minifying – remember this includes both colour information and sharpness. I could theorise how JPEGmini does this, but I might be bereaving myself of a patent, so I won’t. 🙂 Regimping after minifying, incidentally, should not really be recommended for any reason – it was merely done here for investigative purposes.