A rise in megapixel count in a camera may not necessarily result in a better photo, but one thing it surely implies is a bigger file, and hence a longer time to open it on a typical computer. CPU speeds, unlike digital photo sizes, have not been getting appreciably faster over the years. Moore’s Law states that the transistor count on chips will double every couple of years–and this has certainly happened, explaining why the pixel count of your pictures has increased so dramatically. On the other hand, CPUs have hit a clock frequency ceiling with manufacturers unable to crank up clock speeds in the way they have in the past, mainly because higher speeds means increased power consumption resulting in thermal limitations.
This has resulted in larger photos taking longer to show up on your computer screen. Arun Sagar has invented a new technology called MagiXcan, that can decode media files, like digital photos, extremely fast using parallel processing. This technology is showcased in a free, downloadable tool called Aros Magic Viewer, by a Washington-based company called Aros Magic.
Based out of Washington, Arun has filed a patent for this parallel-processing technology. He has been creating software since 1986 ranging from fun toys and utilities to high-speed servers used at major companies that he’s worked for in his career.
In addition to superfast viewing speeds, Aros Magix Viewer 3.0 beta also gives you the ability to easily and swiftly connect your photos to a few online photo services, or Tweet/Facebook them. There is a small floating pane on the right that lets you browse through directories on your computer and then through photos in an album. The UX of the tool is nothing extraordinary, but I realized that’s not what it is for, from the little experiment I conducted.
I downloaded the tool, currently in beta and only for Windows, and ran a few tests to ensure it does what it says. With an attempt to get a large photo, I tried shooting RAW, but a 16MP RAW image from my D5100 was only 23 MB. Also, since the tool only supports JPG images as of now, I compressed it to find only 5.5 MB left. I wanted a bigger image to better compare load times, and hunted down this panorama of Lake Tahoe I clicked one chilly morning at King’s Beach, California, earlier this year:
The original image is 14,695 pixels by 3,470 pixels (48 MP), and uses up a whopping 49 MB on the hard disk. It has been scaled 23:1 to fit here. The actual size of the picture can be imagined from the following small 1:1 cross section of the red rectangle in the above image:
I tested it on a Windows XP and an Ubuntu 10.04 computers, the configurations of which were:
-Ubuntu 10.04 running on Quad Core Intel Core i5-2540M CPU @ 2.60GHz each, 8 GB RAM
-Windows XP SP3 on Intel Core 2 Duo P8700 CPU @ 2.53 GHz each, 4 GB RAM
Time taken to load the image on various software was as follows (average of 5 times):
|Dual Core Windows||Windows Picture and Fax Viewer||6.6s|
|Quad Core Ubuntu||Eye of Genome||3.3s|
|Quad Core Ubuntu||GIMP||4.9s|
|Dual Core Windows||MagiXcan||1.1s|
Cores and processing
A general trend in processor clock speeds, screen display resolutions, and photo sizes over the past two decades:
|1990:||0.05GHz CPU,||0.5MP display,||0.5MP photos.|
|2000:||2GHz CPU,||2MP display,||2MP photos.|
|2010:||4GHz CPU,||3MP display,||16MP photos.|
In my little experiment above, I was surprised to find a dual core Windows XP perform better than a Quad Core Ubuntu machine for the same file.
The number of cores in a computer doesn’t necessarily mean better performance, as Sagar explains:
Unfortunately, when it comes to the using of many cores with parallel algorithms, we run into Amdahl’s Law. This roughly says that there are limits to how fast you can process data if certain parts of it are serial. Because clock speeds have languished and photo (and other media) files are largely decompressed sequentially, we have reached a limit in terms of how fast we can decompress, i.e. consume, them. Even if we had 32 MP displays available today, our present (and foreseeable) CPUs simply wouldn’t be able to decompress and feed images of that size to those displays fast enough, because conventional methods aren’t fast enough. The increased core counts that are available these days are of no help in this situation (and wouldn’t be even if we had 100-core CPUs).
The Road ahead
MagiXcan is currently implemented for JPEG photo viewing speedup on Microsoft Windows only. MagiXcan needs to be implemented for other file formats – photos, documents, audio, video, etc. It also needs to be ported to MacOS and Android. It needs to be deep inside an operating system for it to yield maximum performance. The more formats magiXcan supports, the faster your computer will become. Arun Sagar is trying to crowdfund further development via this Indiegogo project.
MagiXcan is a significant breakthrough, and it is not just sheer speed that is revolutionized. Arun postulates:
Say we have a 100-core machine and have effectively achieved all the speed improvement we care for. Then this capacity for faster processing can be traded off against energy consumption. So instead of processing photos 100X faster on this 100-core machine, we could process them merely 10X faster, but at the same time using up only a tenth of the original power required – by lowering the clock frequency by the same factor.
Faster photo viewing is only the tip of the iceberg. Ultimately magiXcan is the technology that may enable your n-core computer to run n-fold faster for all the stuff that really matters than it currently does. If you are like most consumers, the single most taxing task your CPU does is digital media processing, which is fundamentally just decompression. A lot of the rest of the time your CPU is just idling. Thus, decompressing data n-times faster is, practically speaking, the same as speeding up your machine n-fold.
Less energy consumption directly translates into longer battery life (or smaller, thus less polluting, batteries). If this technology can be ported to mobile devices, phones and tablets running for a week on a single charge wouldn’t be imaginary.