[ptx] Re: Hugin windows snapshot hugin_2004_07_03-13_53_win32.zip with autopano

[Pablo d'Angelo]

On Thu, 15 Jul 2004, Ian Sydenham wrote:

> Ian Sydenham wrote:
> >Have any windows users found a way to make the autopano button (any
> >autopano) work with the latest hugin snapshot?
> 
> I've now managed to do this with both autopano-sift1.4, and 
> autopano1.03beta.
> 
> For anyone else brave enough to attempt it the two script files I used 
> are available at:
> for autopano1.03beta: 
> http://www.asahi-net.or.jp/~rq4b-sydn/Panorama/win-autopano1.03-cmdline.vbs 
> 
> for autopano-sift1.4:
> http://www.asahi-net.or.jp/~rq4b-sydn/Panorama/win-autopano-sift-cmdline.vbs

great! If they work for other people as well, we should distribute them
somehow. Maybe the win-autopano-sift-cmdline could be added to the
autopano-sift package.

As for the win-autopano1.03, we should probably wait until autopano 1.03
is released, maybe the command line parameters change a bit, and the script
isn't needed anymore. However, the drag and drop functionality might be nice to
have anyway, even for non hugin users auf autopano.

> *Hugin snapshot* bugs/recommendations that I have identified as part 
> of this process:
> 1. The path to the autopano command or script file must not contain a 
> space. Strangely this problem is not there when calling enblend from 
> hugin so I expect that there is some difference in the way hugin calls 
> enblend and autopano.

Strange, I thought there wasn't a difference between the calls.
The newest snapshot also quotes the executable filenames. hope it works
well.

> 2. After successfully importing the identified control points into the 
> hugin project an error message is displayed stating that it is not 
> possible:

fixed.

> 3. The file selection box for the first time the autopano button is 
> used defaults to looking for a *.exe file. It would be good to include 
>  *.vbs or *.cmd as well.

fixed

> 4. After reading the control points from the generated autopano file 
> (autopano_result.pto) the file is not deleted. It would be best if it 
> did so that the file could not be read again accidentally if the 
> script throws an error and fails to generate a new file (as it did for 
> me a few times during testing)

fixed

> 5. As stated in the autopano1.03beta comments hugin does not read 
> correctly control point pairs generated by autopano1.03beta. Each -c 
> line in the .pto file generated by autopano1.03beta needs to be 
> assumed to have a "t0" control point type (normal)

fixed, both on reading the autopano result, and with reading .pto
files.

ciao
  Pablo