[ptx] Crash on optimise

[Rik Littlefield]

Thanks, Jim!

Pablo, I would rather get out of the loop on dll downloads.  I think 
we're all trying to get into the mode of having fewer versions & 
download sites  instead of more, so I would prefer that hugin link to 
Jim's page instead of to mine.

Pablo, from your description I am puzzled why the new optimizer is 
working at all with hugin.  To make the improvements, I had to make 
coordinated changes in several functions.  I tried to design and code 
those changes so as to make no changes to the interfaces for any current 
callers, but some of the internal interfaces changed a *lot*. 

For example my fcnPano() does what it used to do unless a new function 
setFcnPanoNperCP(2) gets called.  That  pops fcnPano() into "strategy 2" 
where it returns latitude/longitude distances as two separate errors 
instead of one.  This means that it writes twice as many values into the 
error vector that it was passed.  RunLMOptimizer() has a corresponding 
change -- when it switches to strategy 2, it allocates an error vector 
twice as long, calls setFcnPanoNperCP(2), and expects fcnPano to behave 
accordingly.

If you provided a modified version of fcnPano, overriding the version in 
pano12.dll, than I would expect things to break completely because your 
fcnPano would not coordinate properly with my RunLMOptimizer.

So why is it working?

--Rik

PS. In reviewing my code in the new optimizer, I see there is a subtle 
bug in the interface.  RunLMOptimizer() explicitly calls 
setFcnPanoNperCP(istrat) to make fcnPano do what RunLMOptimizer needs, 
but it neglects to setFcnPanoNperCP(1) when it is finished.  So if 
somebody on the outside calls fcnPano after RunLMOptimizer does, then 
fcnPano will still run in strategy 2 instead of the old strategy 1 they 
are probably expecting.  This will not produce the right result, and 
they might get a buffer overflow on the error vector.  Does this 
situation occur in hugin?

Jim Watters wrote:

> I have also added a MinGW build back on my panotools page. If it is a 
> matter of adding some functions into the export table lets do that.  
> If it is a matter of modifying fcnPano() so it has some compile 
> switchs to behave differently on Linux lets do that.
>
>
> Jim Watters
>
> Graphic Software Developer
> http://photocreations.ca
>
>
>
> Pablo d'Angelo wrote:
>
>> On Fri, 15 Oct 2004, Rik Littlefield wrote:
>>
>>  
>>
>>> Mike & Pablo,
>>>
>>> I don't know what's going on, but it seems to be associated with 
>>> building pano12.dll using Microsoft Visual C.
>>>   
>>
>>
>> Hmm, the pairwise optimisation code incrementally optimizes the panorama
>> starting from one image, including a neighbour reoptimize, include next
>> neighbour etc. This was very useful before your optimisation 
>> improvements.
>>
>> However, do to so I needed some internal functions, and had to create 
>> my own
>> version of fcnPano(), that doesn't output to the terminal on linux, 
>> so that
>> it could be integrated into the GUI. So I needed some internal 
>> functions,
>> like distSquared, pt_getXY,  distLine that are not accessible outside of
>> pano12.dll. Something broke there with the MSVC build.
>>
>> But I guess, the real fix would be to add such a mode to pano12.dll 
>> itself,
>> if it is still needed.
>>
>>  
>>
>>> Anyway, I posted the pano12.dll 2.7.0.7 mingw build at 
>>> http://www.janrik.net/ptools/index.html .
>>>   
>>
>>
>> Thanks! I have linked that from the hugin download site. Is that ok?
>>
>> ciao
>>  Pablo
>>
>>
>>
>>  
>>
>