Memory management
Contents
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.
How available memory is computed ?
First, the operating system is asked for the total free memory on the computer.
If free memory is very low, Autopano will request 128Mb to the system. It is a strict minimum for the application to work, and many panorama will not be stitched or rendered in this situation.
If free memory is lower than 6Gb, Autopano will let a third of the memory to system and other applications, and reserve the 2 other thirds.
If free memory is larger than 6Gb, Autopano will reserve all but 2Gb.
Of course, Autopano will only reserve the specified percentage of the available memory. On 32 bits system the default percentage is 70% instead of 100%. This memory allocation policy aims at providing the best performance for stitching and rendering.
This amount of memory is shared between the 2 caches:
- First cache will take a third of that, never exceeding 2Gb
- Second cache will have the other part
Examples
- 32 bits - 2Gb RAM - 1.5Gb free
Available memory = 2/3 * 1.5Gb = 1Gb Reserved memory = 70% * 1Gb = 700Mb First cache memory = 1/3 * 700Mb = 233Mb Second cache memory = 700Mb - 233Mb = 477Mb
- 32 bits - 4Gb RAM - 3.5Gb free
Available memory = 2/3 * 3.5Gb = 2.3Gb Reserved memory = 70% * 2.3Gb = 1.6Gb First cache memory = 1/3 * 1.6Gb = 533Mb Second cache memory = 1.6Gb - 533Mb = 1.06Gb
- 64 bits - 6Gb RAM - 5Gb free
Available memory = 2/3 * 5Gb = 3.3Gb Reserved memory = 100% * 3.3Gb = 3.3Gb First cache memory = 1/3 * 3.3Gb = 1.1Gb Second cache memory = 3.3Gb - 1.1Gb = 2.2Gb
- 64 bits - 16Gb RAM - 12Gb free
Available memory = 2/3 * 12Gb = 8Gb Reserved memory = 100% * 8Gb = 8Gb First cache memory = 1/3 * 8Gb = 2Gb Second cache memory = 8Gb - 2Gb = 6Gb
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 stored in memory. 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.
The bloc size can be changed in Autopano settings. In settings, limitations of the sofwtare are displayed:
- As a line of the panorama must be fit in one bloc, the chosen bloc size limit maximum panorama width.
- For the Anti-Ghost it is necessary to be able to analyse overlayed data at the same time. Because of algorithms internals, it means that 3 blocs per overlapping image must be loaded.
- 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.
Limitations on panorama width and image overlapping are real constraints. Autopano will not render your panorama is those cases.
The limitation on number of images on a same line is a strong advice. Indeed, if violated, the rendering time will become very very long.
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).
Examples
Note: Each pixel is 4*4 = 16 bytes for final rendering.
- 64 bits - 12Gb - 5Gb free
Bloc size = 1 Mb Maximum panorama width = 1*1024*1024 /(4*4) = 65536 pixels First cache size = 5*1024 /3 = 1706 Mb Second cache size = 5*1024 - 1706 = 3414 Mb Number of blocs = 3414 / 1 = 3414 blocs Maximum overlapping = 3414 / 3 = 1138 images
- 64 bits - 12Gb - 5Gb free
Bloc size = 2 Mb Maximum panorama width = 2*1024*1024 /(4*4) = 131072 pixels First cache size = 5*1024 /3 = 1706 Mb Second cache size = 5*1024 - 1706 = 3414 Mb Number of blocs = 3414 / 2 = 1707 blocs Maximum overlapping = 1707 / 3 = 569 images
- 64 bits - 12Gb - 5Gb free
Bloc size = 8 Mb Maximum panorama width = 8*1024*1024 /(4*4) = 524288 pixels First cache size = 5*1024 /3 = 1706 Mb Second cache size = 5*1024 - 1706 = 3414 Mb Number of blocs = 3414 / 8 = 426 blocs Maximum overlapping = 1707 / 3 = 142 images
As you can see, when you increase bloc size, you can render a larger panorama, but limitation on overlapping images becomes stronger.
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.
When things go wrong
Two error messages can appear when things go wrong on memory side:
- Not enough memory for rendering one line. Cache is maybe too divided, check memory parameters in general settings.
The bloc size is not large enough to store one line of the final panorama. The only solution is to increase bloc size. As stated before, it makes the other limitations stronger.
- Not enough memory for using antighost, too many pictures are may be overlapped.
One common mistake when using bracketed pictures is that exposure stacks were not created. In this case, check the detection group, and create stacks. If not related to bracketed pictures, then you need more blocs in the cache, so the solution is to reduce the bloc size.
As you can see these 2 suggestions are contradictory. There is indeed a range (panorama size, overlapping images) in which you can work. If solving one of the limitation violates the other one, the only solution is to add more memory to your system.
BACK TO: Documentation / Autopano Documentation