Memory management

From Autopano

INTRODUCTION

The notion of memory use and assignment is not really a simple thing.
Indeed it is really hard to estimate the connection between the performance of the computer and the work you expect from it.

Using Autopano allows a large number of possibilities from holiday panoramas (a few pictures) until gigapixel panoramas made of 1000, 2346 or even 12000 pictures, including bracketing and many image formats.

Understanding the management of image stitching (which is less simple than it appears below a cursor and several figures) is not inevitably required to use Autopano.
However, the informations of this page will allow to estimate precisely the amount of work for Autopano considering the specifications of the computer.

DEFINITION

The memory assigned to Autopano is defined as a percentage of available memory when launching the application. All memory is not inevitably used.
Depending on systems, the memory that an application can use is limited (notably for 32 bits systems). Also it is necessary to preserve a margin (leeway?)in order to not overcharge the system.

Example of memory assignment in 32 bits mode	Example of memory assignment in 64 bits mode

Memory is holded to hide pictures used by the software. Currently we discern two types of Cache in Autopano :

• The first one is used to store the pictures displayed in the software interface (in the editor essentially).
• The second one is used for intermediate pictures created during a render.

A third of the available memory is assigned to the first cache within the limits of 500Mo.

PRINCIPLE

First cache

The principle of the first cache is quite simple : If a picture is required, this one is loaded and stored in memory (even if the picture is not used anymore) as long as there is available cache.
It allows to to speed up an eventual access to the picture in the future.

Second cache

It appeared with the launching of Autopano 2.5 and is necessary for the application of complex algorithms on Gigapixel images (Anti-ghost and Gigapixel Multiband).

This one is a bit more complex because nothing can insure that an image can be supported. This cache is divided in identical size blocs.
When the render algorithm works on a part of the image, a bloc is then assigned to this image for the related zone.
Like the same principle as before, as long as cache remains, the zone is stored in memory to speed up a future access.

This blocs concept explains the limitation of render :

• A line of the image must be able to fit in one bloc (that is why there is maximum width limitation).
• For the Anti-Ghost it is necessary to be able to analyse overlayed data at the same time (that is why there is a maximum number of overlayed images limitation).
• At least when a line of the panorama is calculated, it is necessary to load the related lines from source images. It is not necessary to have them in memory together, but if for a line a zone has to be unloaded (write it on the disk) and then has to be reloaded for the next line (Disk reading) a risk of access overload will extend the render time.

The size of the memory blocs changes by steps according to available memory. We try to insure a minimum number of blocs that allows to stitch most of the panoramas.
This step functioning explains the preventive messages that may surprise the user.
In fact it is possible, when increasing memory, that the size of the bloc increases (and therefore the maximum width of the final panorama) but the total amount of available blocs reduces (therefore there is less permitted covering for Anti-ghost).

IN PRACTICE

To illustrate these marginal cases, here is a simple example (6 images) in which every source images can entirely hold in a bloc that belong to the cache (therefore 1 image = 1 bloc).

To apply Anti-Ghost on Image 2, Autopano should know the informations of every picture that covers it, that is to say the 5 other pictures.
Every source picture is related to another one that contains the result of the actual cutting (the algorithm is iterative).
Therefore we must have a minimum of 12 blocs to solve the constraints of Anti-Ghost on image 2 .

In order to render the first line of the panorama Autopano needs :

• 3 blocs : the image 4, 5 and 6.
• 3 blocs : the result of the Anti-Ghost associated with the 3 images. 
• 1 bloc : the first line in the output panorama.

Therefore we must have 7 blocs. This could work if we have less blocs, on the other side there will be a substantial increase in Disk reads.

Imagine that we have only 5 blocs available:
Once picture 4 and 5 are mixed in the line, it is necessary to release the blocs of image 4 to load image 6 in memory and finish the mix of this first line.
On the next line, it will be necessary to reload the blocs of image 4 to start the blending.
As we said that an image fits entirely in one bloc (in this example), the input images will be entirely read again for each line of the output panorama because there is a lack of blocs.

Technical Support / Autopano Pro Documentation / Autopano Giga Documentation