I think your suggestion lacks a very important factor Hans, which is the fov.
It really only applies to 360 tours and you do not account for your ammount of overlap.
I've tested a bit with different input ammounts and so far they seem to dictate the scratch/memory needs more precisely than the actual focal lengths.
I do small sections at 900mm and they render in just 26 mins delivering 1.5 Gpix. The actual ammount of input data seems to be transformed to 32bit form first, which has to be held in ram+scratch. Then as the rendeirng progresses data is clipped and later stacked/blended and fed back to the scratch. It appears the clipping actually reduces memory usage again. The blending needs to read data from a LOT of files (or memory blocks if held in mem) pr thread in order to blend, especially when stacking.
I wonder if Kolor can chime in here... It appears that the layers are made before stacking, or that stacking happens together with blending. Would it not be faster to do the stacking individually before blending? Maby not due to the anti-ghost processing?
Anyways, if people can test my "<input image rez> * 4 * <input image count> = scratch" idea by noting how large their scratch gets as warping finishes it would be helpfull.
Yes I am talking 360*180 here.
fov is directly connected to focal length. Overlap is generally something like 25%, but I did not want to make things too complex.
When you talk of scratch are you talking about the temp-directory?
Scratch will be bigger then the RAM you have indeed.
Yes when stacking multiply everything with nr of stacks, again, I was keeping things simple and i fuse them before loading them into autopano.
Would be nice to see if your formula is more precise and can be integrated in my descriptions of situations and advices. So your formula giving us a number of GB's which we can then compare to the RAM someones has.