[ptx] branching libpano

[dmg]

Sorry, I thought I had sent this to the list. I sent it only to
Max. This addresses the issue that is breaking PTstitcher and other
tools that use dynamically pano12.

In retrospective patching the binaries is not a long term solution.

dmg


----------------------------------------------------------------------

 >> I have made a major change:
 >> 
 >> * I added a struct CropInfo to the Image image. When the TIFF is read
 >> this struct is populated. 

 Max> I agree that this is a much simpler approach than the one I took when adding 
 Max> the cropped TIFF logic.  And, I really wanted to do this when I added the 
 Max> cropped TIFF logic.  

 Max> However, I decided against it because it "breaks" PTStitcher.  The problem is 
 Max> that the Image struct is used by PTStitcher as well as the pano12.dll library.  
 Max> PTStitcher was compiled with a version of Image struct that looks different 
 Max> from the one that now exists in the pano12.dll library.  So, PTStitcher no 
 Max> longer works with the new version of pano12.dll ( I get an error message when 
 Max> trying to stitch a project with the PTStitcher and the new version of 
 Max> pano12.dll).

I think I know where the problem is. It should be the
malloc(sizeof(Image)). We could try to patch these changes in
PTStitcher and see if that fixes the problem.

 Max> I think that it would be OK to break PTStitcher (although still not preferable) 
 Max> if PTMender was a complete replacement for PTStitcher.  But, there are still 
 Max> some reasons why folks might want to use PTStitcher (e.g. feathering) rather 
 Max> than PTMender, and this version of pano12.dll prevents users from using 
 Max> PTStitcher.

 Max> There may also be consequences for any applications that call pano12.dll 
 Max> directly.  I don't know if any of the other GUI developers have developed code 
 Max> to do this, but changing the Image stuct may "break" code within their GUIs.

 Max> There are two ways I can think of to resolve this problem:

 Max> 1. Roll back the changes, and remove CropInfo from the Image struct.

 Max> 2. Add all the remaining "missing" PTStitcher features into PTMender, draw a 
 Max> line in the sand, and tell folks that they can no longer use PTStitcher.  We'd 
 Max> probably want to publish somewhere an authoritative list of which versions of 
 Max> PTMender and PTStitcher will work with which versions of pano12.dll, and GUI 
 Max> developers would need to handle different versions of pano12.dll differently.

 Max> If there is third alternative that allows us to take advantage of having 
 Max> CropInfo inside Image, and allow PTStitcher to keep working, then I think this 
 Max> would be best, but I don't know if this is possible.

Another alternative is to branch the libraries (pano14.dll), with
different version numbers. Somebody will keep maintaining the branch
while new development continues.

 >> This will make it possible to remove a lot of passing of the crop info
 >> from one place to another. In fact, we should refactor a lot of the
 >> code. I think this will be a good idea. MOst of the cropped logic is
 >> heavily cloned and very brittle. We can now have functions that take
 >> an Image as a parameter to determine if a point or line is in the
 >> region of interest. It will also remove redundant calls to
 >> getCropInformationFromTiff. 

 Max> If we keep the CropInfo stuct inside Image, then I agree...a lot of this stuff 
 Max> can be simplified (although as it stands, we now have a hybrid approach...the 
 Max> CropInfo struct is inside Image, and is now being populated when a TIFF file is 
 Max> read, but isn't being used by the existing functions).  In any case, I think we 
 Max> should all agree on the consequences with PTStitcher before moving forward with 
 Max> this...

 >> Hopefully this will be the last bug of the cropped logic.

 Max> I encountered a strange situation last night where the mapping function that 
 Max> converts a source image coordinate to the corresponding destination image 
 Max> coordinate returned "-1.#IND00".  I'm adding a test for _isnan to protect 
 Max> against this, but I think there may be a subtle problem somewhere in the 
 Max> mapping fuction...I'll add this code later.


--
Daniel M. German                  "Diminutive as a mote of dust,
                                   a mere peck of the pen, a crumb on the
                                   keyboard, the full stop --the period--
                                   is the unsung legislator of our
    Alberto Manguel ->             writing systems"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

 


--
Daniel M. German                  "Do not confuse luck with skill.
                                   "
                                   The Replacement Killers"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .