[ptx] What does PTmender mean to hugin?

[Daniel M. German]

Ippei UKAI twisted the bytes to say:

 Ippei> Hi,
 Ippei> I'm wondering where PTmender is going, and how hugin is going to  
 Ippei> support it.

 Ippei> My thoughts are:

These  are my opinions. 

 Ippei> 1. If it's gonna be just a perfectly compatible open-source version  
 Ippei> of PTstitcher, then we can just change wherever says "PTstitcher" to  
 Ippei> "PTstitcher compatible" on hugin.

As time passes by, PTmender will have a superset of the functionality
that PTstitcher. The idea is that we do not need PTstitcher any more.

 Ippei> 2. If it's gonna be a yet another stitcher, we should make one more  
 Ippei> stitcher selection in the stitching panel along with nona and  
 Ippei> PTstitcher.

 Ippei> 3. If it's merely a command line interface to an open-source library  
 Ippei> that is capable of stitching photos, hugin should use it directly  
 Ippei> instead of through command line program for the sake of stability.

I think both can co-exits. I have separated the functionality into
functions that can be inserted into the libpano library . The
"Progress" function can be replaced so hugin can report progress of
the process.

I do like the ability of being able to run the tools from the command
line (simplifies testing, for example). So I think that having a
single code base, with multiple "drivers" is better. I don't think it
will be a good idea to embed the code into hugin.

 Ippei> It looks like we are taking the option 1 for the moment, if I  
 Ippei> understand the situation correctly.

 Ippei> I'm kind of confused because PTmender is developed under the panolib  
 Ippei> package on panotools project. Does that mean its functionality is  
 Ippei> more of panolib than the command line program itself? Then I think  
 Ippei> hugin should use the same functionality directly.

The only reason is there is because I put it there :) I know, it is
not a good reason, but I am open to suggestions. 


 Ippei> If not, shouldn't PTmender consist of the core library that hugin can  
 Ippei> link against and command tool wrapper that keeps compatibility with  
 Ippei> PTstitcher? I think there is no point developing an open-source  

I totally agree. And if you look at PTcommon.c that is exactly what
that file contains: core libraries that PTmender, PTblender, and
PTtiff2psd use.

 Ippei> command line tool only to parse the output in order to make its GUI  
 Ippei> wrapper. I remember after all we abandoned PTOptimiser in favour of  
 Ippei> directly using the same functionality of panolib from hugin itself.

I think they can co-exist. Command line tools are good for testing and
batch processing.




--
Daniel M. German                  "Security is not a product
                                   that can be purchased off the shelf,
                                   but consists of policies, people,
    Kevin Mitnick ->               processes, and technology."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .