Navigate: Advice Beginners BIOS Guide CPUs Links Mainboards Memory Network Storage Video/Sound Cards Contact Forum SiteMap Sponsors WebNews Home	.	.
Prices: Mainboards ABIT ASUS Chaintech Shuttle Soyo Tyan CPU Intel P4 2.4C-800 P4 2.6C-800 P4 2.8C-800 P4 3.0-800 P4 3.2-800 AMD AthlonXP XP 1700+ XP 2000+ XP 2400+ XP 2500+ XP 2700+ XP 3000+ XP 3200+ Athlon64 Athlon64 3200+ Athlon64 FX-51 Opteron Opteron 240 Opteron 242 Opteron 244 Opteron 246 Memory Corsair Crucial Kingston Mushkin OCZ Search Prices:

LOSTCIRCUITS	SHORTCUTS: Another $64-bit Question PanoramaFactory Revisited Test Configurations Wizard and Stitch Alignment and Geometry Transformations Redering and Blending The Final Crop Conclusions Give Us Some Feedback on this Review
Intel Pentium4 600 64-bit Performance PanoramaFactory Revisited
(Review by MS March 2, 2005)

PanoramaFactory

PanoramaFactory is a photo-stitching software that automatically aligns photographs and stitches them together to a panoramic view of e.g. a 36 degree sourround view. Panorama Factory mostly targets this “consumer application” environment, however, the software itself is extremely powerful for all kinds of application. For example, we have used it for a complete reconstruction of a 5 x 10 matrix of microphotographs taken at 1000x (100x lens, 10x ocular) of microcircuitry and it did a perfect job. The process is very simple, all that is required is to load the images in sequence, and hit the “run” button, everything else is automatic. Panorama Factory performs a pattern analysis of the individual frames, determines the overlap of adjacent pictures, lines them up and corrects for distortions and exposure fall-off and repeats these steps throughout the entire sequence of loaded photographs. The only requirements are that the pictures are the same size and that the overlap is somewhere between 10 and 90% - preferably between 20 and 80%.

In a case like that described above, it is necessary to use a two-pass approach, that is, to generate a series of stitched pictures in one axis first and then crop and stitch those pictures in a second pass. Suffice it to say that the software was capable of correcting spherical aberrations as well as chromatic and exposure fall-off at the edges of each frame as long as there was enough overlap between adjacent frames. The result was a composite reconstruction with almost no visible distortions in geometry or color. Unfortunately, it is not possible to show the results, the pixel dimensions were ~ 35000 x 2500 pixels and, moreover, the content is confidential, sorry…

The Benchmark

As shown in our earlier article, a 64-bit version of PanoramaFactory is available, also, there is a a benchmark available to test 32-bit vs. 64-bit performance, courtesy of the AMD performance group. The benchmark consists of 21 individual frames with the result of a total of no less than about 4 GB of data that are loaded into system memory. System memory in this case includes the virtual memory or swapfile as well. It certainly comes as no surprise that the overall amount of system memory (in this case RAM) plays an important role in the overall runtime of the benchmark since more memory incurs less use of the swapfile on the hard disk drive. Moreover, it is not only the runtime but also the variability between runs that is sensitive to the amount of system RAM, which is not too surprising. In other words, in order to benchmark the processor rather than a system bottleneck in form of the ATA interface, it is desirable to run 2 GB of memory, even in the timing benchmark that consists of “only” four pictures.

Out of 2GB total system memory, only 2.8 MB are left, which means that all 2GB are allocated. The kernel memory usage is 61MB, everything else is used by applications with the lions share going to PanoramaFactory. If one adds the 2.5GB of virtual memory (page file usage), that means that close to 4 GB of memory are being used as application memory, which is way above the 2GB limitation of a 32-bit memory addressing scheme.

In general, PanoramaFactory is somewhat gentle to the system in that always two consecutive pictures are handled at any time with the bulk of the data being written back to the HDD. As a result, each pass within the workflow runs at a rather constant memory size and swapfile usage. The critical moment happens when the entire picture is blended and then finally analyzed to rotate it to get the maximum out of trimming and cropping the actual picture portion without the jagged white background transitions resulting from lining up and warping the individual overlapping portions of the pictures stitched together. To give an idea of what the load on the system is, we monitored no more than 3 MB of free system memory (out of 2GB running) left with a page file size of 2.5GB. The Performance Monitor in the Windows Task Manager goes into temporary catatonia and but finally catches on again while the task is completing. During that period of complete non-responsiveness, the system acts as if frozen solid and only a hard reboot would revive it .. patience grasshopper, it will come back to life or … we’ll have some details later.

Note that the pagefile usage - which is part of the total memory addressing - reaches a whopping 3.19 GB which is above the application memory limitation in a 32-bit Windows environment, even with the 3GB switch set in the Windows.ini file

One potential issue with PF is that it can hardly be described as multithreaded, consequently, there will hardly be any use of HyperThreading. In hard numbers, the maximum CPU usage as monitored in the Windows performance monitor never exceeded 66% with load-balancing over the two virtual cores. Keep in mind here that the 66% are not indicative of the real CPU usage, rather, this number is a fictive value based on 100% usage of two hypothetical processors. In real life, we estimate the actual CPU usage substantially higher than the 60% shown.

next page: => Test Configurations =>