Lastest Beta

From Autopano

Jump to: navigation, search

If you do not feel confident, please download and use the last stable 1.4.0 version available here: http://www.autopano.net/download

Contents

1.9.0 Alpha 1 Rev 3

This is the second alpha serie of autopano 2 generation. We decided to release a Giga version that everyone could use with their actual serial number for 1.4.2 Autopano Pro version. So every beta tester have a free Autopano Giga, ain't that cool :)

Download Links

BTW : we may drop support of G4/G5 processors on Mac. It's really a nightmare to support and we won't be able to use every optimization trick we are using now on them. So for the moment, we won't release any Mac compilation for G4, G5 processors.

Release Date : 10 September 2008

Fixes between Alpha 1 Rev 1

  • NEW - group properties, now, you have access to all settings for the group ( including rendering settings )
  • FIX - BUG control point editor that didn't work
  • FIX - BUG flash export : missing logo
  • FIX - BUG extended save as
  • FIX - BUG with exif default value
  • FIX - BUG main progress bar
  • FIX - BUG Raw didn't work with new cache system
  • FIX - Many fixes in detection process
  • FIX - Crash during rendering ( new cache system issues )
  • FIX - a lot of refresh issue in the interface are fixed with qt 4.4.1
  • IMPROVED - shell extension to manage new projection mode and vista far better

Readme

1. SETTING MANAGER

This wasn't really clear in the previous version. In fact, we were mixing 2 kind of settings together and it made the interface not clear and straightforward. I had a lot of discussion about how to make a good documentation of autopano and it highlights me that in fact a design issue was done that prevent to make a really good documentation.

So here's the clean up : we now have 2 kinds of settings : 

- panorama related settings : settings that are associated to single panorama
example : defaut render size=100%, defaut color anchor, detection quality, etc
- software related settings : related to the software so it's the same for all panorama
example : cache path, grid in the editor, separate group by focale, etc.

Having cleaned that, it's now more obvious were you will found any settings.
In general setting menu, you'll get one menu (general) for the software, and the other are all
default value for panorama :
Images -> NEW : how should images be handled : default exif, raw decoding setting, etc
Detection -> classique default detection settings
Panorama -> NEW : panorama layout default value, anchor type, etc
Render -> classique default rendering value
Those 4 dialog boxes set everything you need to describe a panorama.

So when creating a group, a copy of those settings is done to the group. It will use them to generate panorama during detection. One question remains : The group option dialog box is in fact the detection setting tab. It allows to override on the concerned group the default setting. In fact, we should add the same 4 tabs there too because you surely want sometimes to override some other settings like for example 100% in rendering on that single group, right ? I was wondering if we should do that or not. I'm open to discussion on this topic.

Every other menu in panorama editor, settings, are now software only setting. If you need to change something which is related to the panorama, there should be a tool to do that, not a setting ( example, color anchor editor, render dialog box to change rendering options, etc ). There will be no more panorama related option in other settings dialog box.

Status of this job : everything has been done on this work except settings related to optimizer and control point editor. So you don't need to check those, there are not fixed yet. But everything related to detection / panorama layout / rendering should work.

2. PROJECTION

That was also something we need to revamp. There are some thread in bug report which talks about crash when switching to planar projection. It has a strong theorical issue. So we had to change everything and that has been done. The projection code is now clear and far more optimized than before. You won't get that crash anymore even with big planar panorama. In fact, it allows a lot of new possibilities : - new projection modes. We checked that with the mercartor projection and it was integrated in less than 2 hours. We will add more projection to the software : if you have any good suggestion ... ( to GURL : we'll do your idea, it's just a kickass idea ! ) - new possibility. In general settings, you can see, automatic projection mode ! Yes, easy to implement, it will determine the best projection according to the panorama layout : rectilinear for small fov, 360 x small vertical fov will be cylindrical, full sphere will be spherical. This works great. You don't have yet editable switch limits, but that's planned.

Test this feature, I really enjoy this better planar mode.

3. MOTORIZED PANOHEAD SUPPORT

This feature was something I really wanted for v2. It seems easy, but it is not because we need to change the design of the detection algorithm. When using panorama head, you either have access to a file which gives you location of each picture ( merlin head for example ), or at least you know that the panorama has some structure : one image has some neightboor, not all image are neightboors : it's a template of shooting in fact : 8 rows, 6 columns. So the software needs to know about this structure to work better : faster detection, no false link, singleton images should be well located directly.

Panorama head support gives us also the opportunity to work differently in the software and use plugin based on wizard. Just look at the File, Import, menu to check this feature. The gigapan support has been largely debugged, but not the clauss rodeon yet. BTW : you can try gigapan on large panorama ( we did 800 pictures ), but it's not perfect for the moment, because the algorithm used to cope with unlinked picture is not finished yet.

4. STACK NOTION

What is a stack ? Easy, 2 to n pictures that are in fact to be threated together. The most common case is a bracket stack. We introduces this notion to be able to use this structure notion in each part of the software to optimize it. Like with panohead, a images bracket serie has a structure that APP should know about. If it does know about, it can do many things better like for example detection. How does it works ? Easy : if you used bracket, pictures in the group view will be regrouped logically together into a stack with a BKT icon. If there is a stack in the group, the detection will use this structure notion to make a better detection. In fact you have 2 options to control that : Detect links in ()one stack level, ()all stack level. Let me illustrate that with a 3 bracket 5 positions panorama. 

  POS.1  POS.2  POS.3  POS.4  POS.5               POS.1  POS.2  POS.3  POS.4  POS.5    
                                                                                            
0 eV   IM01 - IM04 - IM07 - IM10 - IM13         0 eV   IM01 - IM04 - IM07 - IM10 - IM13     
       |      |      |      |      |                   |      |      |      |      |            
-2 eV  IM02   IM05   IM08   IM11   IM14         -2 eV  IM02 - IM05 - IM08 - IM11 - IM14     
       |      |      |      |      |                   |      |      |      |      |           
+2 eV  IM03   IM06   IM09   IM12   IM15         +2 eV  IM03 - IM06 - IM09 - IM12 - IM15     

         One stack : only the ev0 links                All stack level : every stack level will be
         will be detected                              analysed to find link

The links within a stack are always detected. We could imagine to add an option to prevent that too, because if you were accurate during shooting, they should match perfectly.

We did some testing of this stack feature. Panoramas with 9 bracket level or 11 bracket are now better supported than in previous version. But that's not the only reason to add this new notion. It will be the background for 'N to 1 plugin'. An 'N to 1 plugin' is easy to understand, it uses N images in input and creates one in output. When thinking back to bracket, what is the more obvious 'N to 1 plugin' ? Merge to HDR. From N LDR plugins, we get a HDR picture. Those plugins will be introduces in alpha 2 or alpha 3. So that's the second and but main reason to support stack.

5. DETECTION

We talked a little about that already when defining the panohead support. Yes, detection has been totally changed. The main change was to use the structure notion of the group. If we have stack, we need to use this new information. If images comes from a panorama head, we need to use this information too.

Another topic that often arise when talking of detection is raw support. Many users don't understand why detection is so quick when using jpeg and so long when using raw. In fact, it's the raw decoding that is really long, the detection is fast.

So here's what has been done in detection :

  • we now use the structure notion of stack and panorama head
  • when detecting raw, you can see in the progress bar a step that wasn't before there : raw decoding. So you are now informed it doesn't do the detection, but raw decoding
  • last but not least, the detection is now fully multithreaded, 1 core => 20s, 4 cores => 5 seconds. We did a lot of work on that it scales perfectly. It's so amazing that now I'm using 100 images panorama when debugging rather than some of my old 15 images panorama before.

Really, if you had to remind only one fact in this first alpha, it should be multithreading in detection :)

BTW : didn't I notice that this full revamp has improved a lot detectivity ? Now panorama that weren't detected well before are good with standard detection quality. I checked on old nightmare cases which are now often directly perfect.

6. SOFTWARE OPTIMIZING

For autopano engine 2, our way to work on the code was pretty clear : follow the images ! First detection, then control point validation, optimizing, rendering, etc ... As you can see, this alpha 1 has done some major breakthrough in the detection and point validation.

The next step is the optimizer. That's for alpha 2. I really want to step into this huge hidden part of the software. Some jobs have already been done. You could find that if you do big panoramas. The optimizer is faster, far more faster. But that's the first improvement only. BTW : to get better quality, ie RMS, for big panorama, it's now good to use robust algorithm. It really stabilize the layout and RMS drops a lot.

Warning : current version of optimizer is not totally finished, so as always with alph, save before if you can. Second note : it uses far less memory now ! So for crazy people, optimizing a 2000 images panorama on 32bits is possible. I didn't make an estimation of the new top limit, but it should be far bigger than 2000 images ... let's shoot guy :)

Another next step is the rendering. We dig up a lot of stuff already. In fact, we were forced to because we did GPU processing. Yes, we managed to do full GPU rendering :) Pretty nice. This technical achievement raised a lot of questionning in our rendering pipeline. How can we do a clever CPU core usage, how can GPU be integrated into that, could we use both together, etc. A lot of work still has to be done so that's why we disabled any GPU rendering in the current alpha, even if it's present.

7. FLASH OUTPUT

I really enjoy to work with klaus on this topic. He's a really good man and the KRPano viewer is fantastic. To show you that, we decided to make a quick and 'a bit dirty' output in flash directly in this alpha ( alpha means work in progress, so don't ask for the full perfect swf output yet ! ). Two ways to access this feature :

  • rendering dialog box, swf format
  • main menu, tools : dialog box to convert a picture into swf

Nothing really fancy, but you can already start playing with flash VR with that.

8. MISCELLANOUS

In several part of the software, we made some minor changes. I cannot list them all here, but here's the principals :

  • we removed the popup progress bar that show and hide when detecting groups. It's an idea that came up many time in the future thread to have a global progress bar clearly visible. So we did this behavior and put a global progress bar in the main window ( it's not yet totally bug less ).
  • The browse folder dialog box has been revamped. It's a bit bigger but has new feature like the "group by focal" option. It creates one group per focal, easy and useful.
  • The cache. This is typically a hidden feature but so useful in the software. We rewrote it from scratch. It's faster and works now with multithreading.
  • Default exif : you can set default exif value ( lens type ) for pictures which don't have exif. For people working with HDR pictures for example,

that's a great feature to put automatically the right focal / lens type.

9. ROAD TO ALPHA 2

There are still some big feature to code and improve in alpha 2 :

  • The optimizer. That will be my first topic when getting back from holiday
  • GPU. Lionel will continue to work on this part to get the best out of it
  • Real Time preview. This is a sidework related to GPU
  • Continue flash integration
  • "N to 1 plugin" interface to prepare HDR integration

Alpha 3 will be targetted on HDR only

I think that when those features are stable and working great, we'll have a good v2.0

Retrieved from "http://www.autopano.net/wiki/action/view/Lastest_Beta"
Personal tools