Looking back on my crash history it all makes sense to me now.  Sometimes a que of one went fine, but a cue of 3 renders crashed with usually only one or two files completed.

So until a v2 is out, one might  only render one file at the time one a fresh boot. ( Maybe its possible to save some ram fragmentation by loading the batch script directly one a fresh boot )

If ram fragmentation is random, maybe it will help to turn off some window services ?

Today situation about this project :

Part 1 : fixing smartblend memory fragmentation issue

* We are still waiting the feedback of the memory expert. They should have provided us the way to do it one week ago, but no answer yet.
This part is reall not easy but I think that team should be able to make it ( they worked on far bigger project than us ).
* As soon as we have the feedback, we'll work on a 2.0.7 version to release a fix for that ( we'll fix also some other bugs ).

Part 2 : New Smartblend from scratch

This job is making good progress. We have quite finished all the needed algorithms and new memory manager background. In fact, quite everyone here is working
just on that topic. So what has been done so far :
- New memory manager that is working differently : one big allocation at the beginning and everything else is managed ourself. And of course, fragmentation cannot happen with that system.
- New cache system that will be used by the memory manager. You will be able to setup several temp folder, etc.
- Then the rendering engine status : we decided to remove everything and start again from scratch. There were several reason for that : memory management, but also multithreading integration. We want a far better scalability with the number of core.
So, we are currently doing that part. Actually, we are finishing porting the old smartblend engine over this new engine ( BTW : we improved the anti-ghost system ). We should be able to do our first full rendering with that new system soon.
- What's missing ? The HDR integration is also under heavy revamp into this new engine. It will be totally different than the old workflow and I'm sure it will meet your quality criterion.

Awesome! Great news, and I think this will be a great improvement to APP!

I'm especially looking forward to the new HDR functionality.

Some good and bad news :
- Bad : Part 1 is still under heavy work. It's really a complicated task and it takes longer than planned ( I'm sure you've noticed that ).
- Good : Part 2, the new smartblend engine is done. Everything is working really good ( and faster ! ). We are quite happy with that new system. We still need on this part to stabilize the code ( even balance between memory usage / disk usage / core used, etc ).

Great news! I suppose the new Smartblend uses multiple cores and plenty of memory, instead of putting stress on the HDD?

AlexandreJ wrote:

Some good and bad news :
- Bad : Part 1 is still under heavy work. It's really a complicated task and it takes longer than planned ( I'm sure you've noticed that ).
- Good : Part 2, the new smartblend engine is done. Everything is working really good ( and faster ! ). We are quite happy with that new system. We still need on this part to stabilize the code ( even balance between memory usage / disk usage / core used, etc ).

Good to hear from you. Looking foward to seeing the fruits of your labours.

Sounds good to me.

Last edited by mediavets (2010-02-25 20:05:48)

What kind of projects do you run, Zab? I'm on W7x64 with 8 and 16 gigs of ram (two separate PCs), Q6600 CPU on both. Crashes are really really rare and mostly related to CP editing.

It may be a memory issue. Try that out: render the panorama at 100% Output Size, but select Multiband blender, instead of Smartblend and report back.

Using Multiband you should not have any problems with projects of this size (10 x 20mp jpegs). You wrote the crash comes in the final stages of rendering - that usually signifies the use of Smartblend running out of memory (or more precisely - of defragmented memory).

What output setting you're using - file type? bits? What final file size Autopano computes for the whole panorama?

Zab, the detection quality setting just cannot cause this. This settings just change the number of control point calculated and these are not used during rendering ! We used the result of the calculation done on them, not them. So this is not the explaination.
More interesting is the fact that you changed the temporary folder location. It can explain crashes far more easily if you run out of space on the first location during rendering.

AlexandreJ wrote:

How smartblend works :
* take image 1 and 2, calculate the transition seams, do the blending. You'll get new blended image 1_2
* then SB blends the 1_2 with image 3 and you'll get image 1_2_3
* etc for all images

Alexandre,

I know you made a new Smartblend version already, so my comment may be useless. Let me make it anyway ... I have two comments to make, actually.


1. The working image (image 1_2_3_..._n) grows really big:

The following procedure would prevent this from hapenning, though:

A. You could first sort the images 1, 2, .. by their upper left coordinate, x first, then y (for example).
B. When computing image 1_2_3_..._n, you could then REMOVE all parts from this image which ONLY have overlap with previous images. The REMOVED parts are first saved as tiles for construction of the final result.
C. As a result, the number of pixels within image 1_2_3_..._n only grows with linear dimension, not square of it. That should resolve all issues and even make it very fast by avoiding swapping altogether.
D. Make a special rule for 360° panos (e.g., don't allow the seam to wrap around).

This makes the existing SmartBlend algorithm perform faster w/o altering its behaviour.


2. Ideas for a better SmartBlend algorithm:

In the above, images 1, 2, 3, ... are all used with equal precedence. In practice however, some images are better than others (e.g., less blur from a freehand shot; or some shots use a longer focal length to embedd interesting detail at higher resolution; or some shots need less perspective correction than others, depending on selected viewing direction).

Therefore, SmartBlend should know about a quality index (contrast + focal length + proximity to image center) and use its quality index alongside other criteria for seam computation. It should start with images with highest quality index too.


Just my two cents.
(I have trouble to use SmartBlend on larger panos too.)

Some news :

The 2.0.7 is on internal testing ( we expect a public release next week ). It contains only bug fixes plus some new features, expecially the one for smartblend crashes. BTW : don't make me say it will work every times, it won't. You will never be able to render a 20G panorama on a small laptop. Nevertheless, this huge internal study gave us some confidence it should work most of time.
If some people are interested into participating into the private beta, email to me directly with platform details.

---

The next big release will be called 2.5 and contains HDR, a new rendering engine ( totally different from smartblend and because it has been created from scratch, it doesn't have the same flaw as smartblend ), plugin system, manual control point editor, etc. The timeline is quite clear here too with a first public preview last week of may.