From: Daniel M. G. <dmg...@uv...> - 2006-06-26 21:24:03
|
Bruno Postle twisted the bytes to say: Bruno> Daniel M. German wrote: >> Bruno> 2. Freeze 'pano12' at 2.8.3, fork a library called 'libpano' which Bruno> will not be binary compatible and which will probably change again Bruno> in the future. >> >> If we take this approach I suggest we use 2.8.1. (tag 'release-2-8-1') >> >> Or better, move the library as it was just after 2006-05-06 18:22. I >> checked the CVS logs and this is the last commit before I moved >> PTcommon.h into the library: Bruno> I thought that binary compatibility had been maintained until the Bruno> day before I released 2.8.4? Bruno> Either way, I propose creating a CVS branch for the Bruno> backwards-compatible pano12 and changing the files in the trunk so Bruno> the library is built as pano.dll, libpano.so etc... I feel it would be better in the long term to create a different module (pano12) instead of a branch. It will make it easier to administer and manage each. It is the way Apache handles its branches and it seems to be very effective. dmg Bruno> Though I'd like to hear from people who use the library first as Bruno> they need to make changes too, Max, Pablo, any comments? (Pablo is Bruno> away at the moment). Bruno> -- Bruno> Bruno Bruno> _______________________________________________ Bruno> PanoTools-devel mailing list Bruno> Pan...@li... Bruno> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "To take photographs is to hold one's breath when all faculties converge in the face of fleeing reality. It is at that moment that mastering an image becomes a Henri Cartier-Bresson -> great physical and intellectual joy." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2006-06-20 15:36:42
|
Rik Littlefield wrote: > >> What is remaining in PTmender? > > Morphing? > z-line extended depth of field? I tried morphing with PTmender briefly and it seemed to behave as I expected. Though I've never used the feature so I'm not the best person to evaluate it. The depth of field stuff needs testing. -- Bruno |
From: Daniel M. G. <dmg...@uv...> - 2006-06-20 15:59:48
|
Bruno Postle twisted the bytes to say: Bruno> Rik Littlefield wrote: >> >>> What is remaining in PTmender? >> >> Morphing? >> z-line extended depth of field? Bruno> I tried morphing with PTmender briefly and it seemed to behave as I Bruno> expected. Though I've never used the feature so I'm not the best Bruno> person to evaluate it. Bruno> The depth of field stuff needs testing. Yes, I agree it needs testing, but it should be in. This is what is missing (it might not be complete): * Processing of fisheye lenses (it only processes rectilinear). * Brightness or colour correction only * Feathering The following output formats: * QTVR * IVR_java * VRML * IVR * PAN Bruno> -- Bruno> Bruno -- Daniel M. German "Let us show our friendship for a man when he is alive and not after he is dead. F. Scott Fitzgerald -> " http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Jim W. <jwa...@ph...> - 2006-06-20 15:51:57
|
On Tue, June 20, 2006 5:00 am, Bruno Postle said: > Daniel M. German wrote: > >> Perhaps one solution to reduce this problem is to have a different >> name. pano13 might find confusing, how about creating a new module >> (called pano12) and copy all the files from the current libpano to >> that. Then we keep developing "libpano". pano12 will always be >> compatible with PTstitcher (at least as long as OSs can load it and >> execute it) and libpano will be the "next generation" library. > > I have no real problem forking the project like this, it would be > easy to switch the actively developed tools to use the new library. > > What would be wrong is if it ended up with two separate projects > being actively developed - This is the situation the sourceforge > project was created to fix (at one point there were four different > forks and people had to switch libraries to get the feature they > wanted). If the changes/features can be made to work with the current PTStitcher then that is the way to go. The topic of creating a new library has come up several times in the past. I believe there has been a few things that never got implimented because we could not change the structures. Correcting CAt comes to mind. There are likly others. If it is forked then it will be neccessary to maintain both for a while. > If PTmender gets finished, PTStitcher and the old pano12 can be > officially retired and there is no problem - Though developers who > link to pano12 will have to get used to the API/ABI changing > occasionally. PTStitcher is only one of the helper programs. PTOptimizer is already done. But there are a few others. Most of which I use but too should be updated. PTCrypt.jar PTEditor.jar - non-java FSPViewer like app would be my preference. PTPicker.jar - not needed PTAverage.exe PTInterpolate.exe PTMorpher.exe PTOptimizer.exe - Done PTStereo.exe PTStitcher.exe - PTMender PTStripe.exe > What is remaining in PTmender? > * Feathering - Is this really necessary. Feathering is usefull for preview. At least a crop to the midle of the seam. The other programs are too slow for preview. > > -- > Bruno -- Jim Watters Yahoo ID: j1vvy ymsgr:sendIM?j1vvy jwatters @ photocreations . ca http://photocreations.ca |