Why to have one more image viewer? My thing is that I did not satisfied with any existing one, so I decided to continue working under my own one. Some (commercial) viewers are working (starting, at least) slow and do not actually support well image types, listed as "supported". Other (free) viewers are not stable, work slow with a big list of files or fail opening some images (sometimes because they are big, sometimes because the image format is not supported well). The best and stable from others for this moment I think is the freeware Irfan viewer. (I hope mentioning it here will not be considered both as an advertisement or detraction, I anyway respect to the authors of so comprehensive tool). But... I do not like its interface and capabilities. E.g., some options suitable in my opinion to be changed quickly are hidden in very overloaded Options dialog (I mean gamma-correction). Also, I do not want to modify the image on the disk just to see it rotated for a several seconds. Hmm, it seems trying to load any image into memory, and certainly it is failed to load images bigger than 4 Gigabytes and working very slow with even smaller images. But this seems a problem of the most of graphic applications and not only viewers. A list of such opuses can be long enough for any image viewer I have seen before.
Initially, Zoomer 1.0 was appear... mmm... do not remember exactly how many years ago... may be 5?... this isn't matter though... I created it just to test my idea of image zooming in several times with preserving as so many quality as it is possible. Then I improved it a bit, to view images really fast: since the Zoomer was very small and could handle only several basic image types, it was started very quickly. (Hope it is still starting fast enough and such its characteristic did not degrade a lot from the first version).
Certainly, first versions were very bugged. A lot of images (damaged, with some specific data or created with some special parameters, etc.) could not be loaded. The application was crashing or went into the infinitive loop or sometimes was crashing the system. May be you do not know, but the Zoomer is written in Delphi using Key Objects Library (I am an initiator and continuous chief of a team creating that Library, but a lot of people took a part in improving it, great thanks to all of them, I am happy to say this). Some years ago this programming tool could not boast of firm stability and safety. But a time is not staying the same, the library was developed, bugs were fixing, support was added for a lot of image types, for variations of Windows versions, and finally, now we have very stable instrument allowing to do almost any thing fast and fine.
In version 3, the support of TIFF, PSD and some other more rare file types was added to the Zoomer. But it worked very slow with big enough images. And certainly it could not handle at all really big images. And several more interesting new things were added in version 3, such as images encoding, move-to with a single right mouse click. These features were mostly experimental though.
And when I started working under version 4, initially just for fun, I found that I can not fix newly "created" bugs in a multi-thread environment. Problem seemed to be so hard to solve that I delayed working for about a 6 months. During that time I improved KOL a lot, have created several complex programming tools allowing to search and fix very serious and hard-to-detect errors in code. For example, I created a small memory manager, which checks entire memory heap on each call, and works very slow, but allows to detect memory bounds violation almost immediately after the problem occur. To get an ability to repeat the execution from time to time with the same data and catch on the second run the error detected on the first run, but in the multi-thread application, I made a some kind of thread emulation system. Actually, all the execution was running in the single thread in this case, but the application without any change in code supposed that it contains several different threads. And finally, the Bug was found...
Spending really a lot of time to the Zoomer I decided that it must become a commercial application. And a work has continued. At this time you can see version 4.02 which is (by my plan) is about a 1/3 of that really will be at the finish. Already now, the Zoomer is not just a stupid image decompressor / viewer. To allow zooming in images with ratio 512:1, the Zoomer has its internal manager of fragments: it allows to load into memory only a small part of the image, zoom in it and show.
To allow loading really big images, which unpacked size can be greater than several Gigabytes, a special internal format similar to tiff was developed. The giant JPEG or PNG image is unpacked, divided onto tiles and repacked to a temporary file on disk, where tiles are stored uncompressed or compressed with lossless jpeg compression. After repacking finished, the Zoomer can show the image fast, allowing to do the most of usual operations sufficiently fast (scaling, gamming, rotating, cropping, etc.) To view giant TIFF files, a code handling this file format was changed so it now allows to extract only pieces of the image that are needed at this time. The effect even better than for gigantic JPEG or PNG, still it is even not necessary to repack the entire image, and large TIFF file can be viewing directly from its location on the disk. As I know there are no another image viewer with such characteristics at this time. If you are not believe me, try to load jpeg image about 30,000x30,000 pixels into any other image viewer or even into any well-known image editing application, and when it it is loaded try to scroll it or view in its original size in that viewing tool.
To allow canceling the long operation (and to get know which part of time-consuming work is already done), I provided a progress for almost any loading procedure. Due a lot of image formats having its own loader and impossibility to change code of each loader, it seems not possible to do so, but I found the solve: for case when the loader has not have a callback, allowing to control loading process, the callback is adding to the streaming object. And if it is necessary to stop loading in such case, the data stream just positioned to the end of file and the loading is stopped (failed, certainly) almost immediately. In result of press Cancel, the image is loaded partially like it was truncated while downloading it from the Web. But this is much better than to cancel the operation together with the viewing application from the system Task manager.
In comparison with the version 3, you also can find many other features starting from better (I hope) application appearance and mouse / keyboard interface to some very interesting options such as display resolution correction (which allows to view images with its actual ratio even on monitors with non-square pixels, now go and find any other viewer having such unique feature!). When I decided to add a capability to use the Zoomer as a wallpaper set tool or as a screen saver, I also add there some fresh ideas which I suppose can be useful not only for me. Actually, I do not create this application just to sell it, but for my own usage too (and mainly for myself). I am sure that a thing made by the author for himself certainly will beat other competition tools just because the creator love this work, and makes all things as good as possible, rather then the thing is made just for money (or just for fun, too).
What are my plans now? First, adding a capability to print images. And this option is already available in the pre-beta version 5.00, but for beta-testers only. This is not because printing is a big problem, but there is another reason to delay including it to the final version. The point is that printing in the future version of the Zoomer will allow not only print a single image, but a collage of images created in a special mode named as "Edit Collage and Print". Actually, a capability to create a collage containing of many other images makes the Zoomer a full-featured... image editor. It is suitable for this mode to add a lot of editing operations such as resizing, distorting, cropping, color-deiting and many-many others. So, before publishing the Zoomer in such configuration I should spend some additional time to add these options and to test it well. This will be about 2/3 of my project, and I hope to finish it to the end of year 2007. What will be in the last 1/3... I prefer to stop telling about it now. First, let me finish the second 1/3 of the Zoomer, and then it will be more clear.
And, what about a price? Some people finding the proggy on the Internet which costs so small amount of money (10 Euro!) may be think: "this is so negligible price just because the proggy is not smart enough". Ah, this is wrong. Some time a thing coasts much more but can do much less... As well as some people finding so small proggy also think: "this proggy is so small in bytes, what interesting it can do? May be it just able to run and then can do nothing except saying good bye and exit". In some cases this is true, but this really wrong in this case, too, I'm sure :) And, a sentence about the nag screen, as final today word. You may be angry when see it and move the Zoomer to the trash immediately, but think first how many other things can be bought for the 10 Euro. May be, you can eat a lot of food an a restaurant or buy a some new clothes for it... This is for your decision, though.
Vladimir Kladov, 05-Nov-2007.