wxport

[Juha Helminen]

Hello,

 > > > BCB do not manage to compile
 > > > extern "C" {
 > > > #include <pano12/filter.h>
 > > > }
 >
 > It is needed when linking objects compiled with gcc (c compiler) and
...>
 > bcb should be able to compile that. whats the error you get?

Error comes from file objbase.h(458): E2132 Templates and overloaded 
operators cannot have C linkage.

I understand this that compiler cannon compile C++ structure in C-style 
;)  --> C++ code cannot be written inside extern "C" { }

filter.h includes files that have C++ code (inline code?) and so it 
makes an error.

 > > > Would it be good idea to copy filter.h, panorama.h and version.h 
to cvs
 > > > as then everyone has correct files? Library is needed but it need 
not to
 > > > be included as BCB uses implib -program to make it from DLL.
 > > Yes do so.
 >
 > I don't think this is a clean solution. we should use the libpano
 > tool lib that is installed on the current system, because the depend
 > on eachother. What does the implib program do? generate headers from
 > a .dll?

Implib do not make headers, just libfile (and lib file do not contain 
them). This use to be problem with DLL:s as they can change and headers 
can change... (not wise to change). I used implib as I didn't see 
already compiled libfile in panotools src -file.
It's was easier to write "implib -a pano12.lib pano12.dll" than compile 
pano12.lib.

 > It depends how much functionality we need from libpano. The model
 > classes in hugin can be seen as data model for libpano. (well probably
 > not a really good one yet, but its on the right path I think).
 > Then some other classes or member functions could work on that model
 > (for example optimizing some variables etc.) I would only write these
 > wrapper classes incrementally, when I need the functionality.
 >
 > It would be nice to have a nicely abstracted object oriented interface
 > to the whole PT functionaly, but doing that will get us distracted 
from our
 > real goal, I think.

PanoTools source is not easy to follow. Is it easier to rewrite 
functionality to C++ than than to make some C++ components that hides 
C-structures. PT is build with global variables (atleast one "global" 
pointer) and all routines are not so nicely converted to C++, or how?

Too much work to rewrite PT, I think, better to make GUI that uses old 
style/library.

 > But some time in the future I might need some functionality from
 > libpano, like partial undistortion of images.

This is good reason to use it directly. I have tried to read how to do 
this but it's not so easy to find out. Final panorama has y=0,p=0,r=0. I 
suppose that y, p and r can be made as variables ;)

Juha