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

[Daniel M. German]

I guess the rollback is inevitable, but it will then require to fix
the bug that the last fixed. This is the CVS transaction:

The time of the transaction:

2006-06-16 06:24:51 (commited by me)

This is the log:
----------------------------------------------------------------------
* ppm.c (makeTempPath): Added zeroes to temp files, so they are nicely sorted when listed.

* panorama.h: Added crop info to Image data structure.

* tiff.c (writeTIFF): Added cropInformation parameter to function call.
(setCropInformationInTiff, getCropInformationFromTiff): Moved
functions to this file from 
PTcommon.c
----------------------------------------------------------------------

And these are the file revisions changed:

-------------------------+------------+-------
 dmg:2006/06/16 06:24:51 | ChangeLog  | 1.48
 dmg:2006/06/16 06:24:51 | panorama.h | 1.12
 dmg:2006/06/16 06:24:51 | ppm.c      | 1.3
 dmg:2006/06/16 06:24:51 | PTcommon.c | 1.27
 dmg:2006/06/16 06:24:51 | tiff.c     | 1.11
----------------------------------------------------------------------

and this commit will have to be redone (a trivial change really).

2006-06-16  dmg  <dmgerman at uvic.ca>

* PTcommon.c (CreatePanorama): The process for creating PSD_mask
  and PSD_nomask was inverted.

-------------------------+------------+-------
 dmg:2006/06/16 07:39:59 | ChangeLog  | 1.50
 dmg:2006/06/16 07:39:59 | PTcommon.c | 1.29
----------------------------------------------------------------------


=============================================================================-

Now, back to the discussion.

I think the Image data structure needs to be further changed. For
instance, the ICC, and EXIF data should also be included in it. We
need to be able to move both ICC and EXIF along the process of
creating the images, and the Image data structure is the perfect place
to do it. 

Otherwise we will keep patching the code, and finding bugs in places
that we forget to "update".


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

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.


dmg



--
Daniel M. German                  "We die. That may be the meaning of life.
                                   But we do language. That may be
   Toni Morrison ->                the measure of our lives."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .