[ptx] Re: [PanoTools-devel] branching libpano

[Max Lyons]

I think my e-mail account is having problems, because this is the first time 
I've seen Daniel's comments!

In any case, it might be interesting to see if patching the PTStitcher binary 
would work (I wouldn't know how to do this), but probably isn't the best long 
run solution.  After all, changing the pano12.dll interface by modifying the 
existing structures in the header files can "break" any existing applications 
that try to use the new  version.  This will include the Photoshop plugins, any 
other Panorama Tools executables (e.g. PTMorpher, PTInterpolate, etc.) that use 
the Image struct, and any GUIs that call pano12.dll as well.

Given this, I think that either branching the code into two versions or rolling 
back the changes are the two remaining options.  Having two different versions 
of Panorama Tools might be fun for developers but I fear will completely 
confuse the average user, and I suspect will cause all sorts of angry "I 
downloaded the latest version and now my XYZ program is broken" sort of e-mails 
to the various developers who (a) work on Panorama Tools or (b) work on 
programs that depend on Panorama Tools.

So, I think that the leaves rolling back the code changes as the best option.  
I know I wouldn't have coded the cropped TIFF stuff the way I did if I hadn't 
been constrained to retain compatibility with previous versions of pano12.dll.  
But, I think that living with a little less-than-optimal code may be the least 
bad choice of the bunch.  Maybe there is a way to retain compatibility, and 
tidy the code up as well...I'm certainly open to this approach as well.

That's my vote, but I'm happy to be vetoed by others if there are other 
opinions.

Max


 
> 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).