Panorama Tools

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

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

First I mistakenly sent this message to Max Lyons only, now I hope that 
it will go to the list.

Sorry for the duplicate.

Max Lyons ha scritto:
> 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
>
>   
Hello,

I subscribed to this list from its start, but I never posted here
because I am not developing pano12, at the moment.

Anyway, I have read about branching the library because the new Image
struct is not compatible with older programs like PTStitcher.
I think that there is another option: keep the older structure and code,
change name to the new Image struct (something like "ImageEX"...) and
write new functions that use the new struct with a different name, for
example from "FuncName" to "FuncNameEX". With a little luck we could
find some code that will not need to be duplicated so this solution
would save some work and a lot of confusion for users.
Older programs would keep calling the old interface and would keep working.
Newer programs would call the new interface and use the new structure.

BTW, you could use a trick used in the Windows API: the first field of
the struct could contain the struct size. A caller using a newer version
of the struct would pass a larger value and the called program would
know that it is receiving a different version of the struct.

I don't know if this solution is practical since it is a long time that
I do not look at the code, but it should save some work compared to
branching.

Just my 2 cents.

Fulvio Senore

On Tue, June 20, 2006 11:43 am, Fulvio Senore said:

> BTW, you could use a trick used in the Windows API: the first field of
> the struct could contain the struct size. A caller using a newer version
> of the struct would pass a larger value and the called program would
> know that it is receiving a different version of the struct.

There is a magic number already used in the structure to keep track of version. But not
size of structure.


-- 
Jim Watters

Yahoo ID: j1vvy ymsgr:sendIM?j1vvy
jwatters @ photocreations . ca
http://photocreations.ca

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 .

Fulvio> I subscribed to this list from its start, but I never posted here
 Fulvio> because I am not developing pano12, at the moment.

 Fulvio> Anyway, I have read about branching the library because the new Image
 Fulvio> struct is not compatible with older programs like PTStitcher.
 Fulvio> I think that there is another option: keep the older structure and code,
 Fulvio> change name to the new Image struct (something like "ImageEX"...) and
 Fulvio> write new functions that use the new struct with a different name, for
 Fulvio> example from "FuncName" to "FuncNameEX". With a little luck we could
 Fulvio> find some code that will not need to be duplicated so this solution
 Fulvio> would save some work and a lot of confusion for users.
 Fulvio> Older programs would keep calling the old interface and would keep working.
 Fulvio> Newer programs would call the new interface and use the new structure.

 Fulvio> BTW, you could use a trick used in the Windows API: the first field of
 Fulvio> the struct could contain the struct size. A caller using a newer version
 Fulvio> of the struct would pass a larger value and the called program would
 Fulvio> know that it is receiving a different version of the struct.

 Fulvio> I don't know if this solution is practical since it is a long time that
 Fulvio> I do not look at the code, but it should save some work compared to
 Fulvio> branching.

In principle it is doable. I was looking at the Image struct, it does
not have a field that will let us know what "version" it is, but one
can be added (there is a field with the name of the image taking 256
bytes, it would be easy to steal 2 or 4 bytes from it to use for this
purpose).  I would rather create a pointer using those bytes to
another area, so the struct remains the same size (to make sure that
arrays keep working).


While this allows the library to continue offering backwards
compatibility it makes it a pain to maintain.

The current code of PTcommon and PTmender look the way they do because
I reproduced the Helmut's code. But it needs to be cleaned up and
improved. By forcing backwards _binary_ compatibility we are basically
forcing the developers to spend an unnecessary amount of time having
to make sure that the changes don't break it. And what is even worse,
_I cannot_ run PTstitcher because it is not even supported in my
development platform (OS X).

Also, who uses the library directly?

* Helmut's applications
* Hugin

Anything else?

Maintaining binary compatibility is very difficult (but not
impossible), and in my opinion it is not worth it. It makes
programming more convoluted, testing more difficult, and it removes
some of the fun from contributing to the project.


--
Daniel M. German                  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Jim Watters twisted the bytes to say:


 Jim> If the changes/features can be made to work with the current
 Jim> PTStitcher then that is the way to go.  The topic of creating a
 Jim> new library has come up several times in the past.  I believe
 Jim> there has been a few things that never got implimented because
 Jim> we could not change the structures.  Correcting CAt comes to
 Jim> mind.  There are likly others.  If it is forked then it will be
 Jim> neccessary to maintain both for a while.

What is worth discussing is what is necessary to maintain in pano12? I
would say it only needs to have bug fixes, and nothing else. No new
features. The time invested in doing so will be significantly less
than the time invested making sure that improvements work with the old
binaries.




--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

On Tue 20-Jun-2006 at 09:29 -0700, Daniel M. German wrote:

> Also, who uses the library directly?
>
> * Helmut's applications
> * Hugin

* PTgui, PTassembler and PTmac (I think)
* Pano2QTVR
* PTlens
* Photoshop panorama plugin (but not the Gimp plugin)

...but these can all adjust to changes in the interface since they 
are actively maintained.

The options seem to be:

1. Carry on with changes to pano12, anyone who wants to use Helmut's 
binary tools needs to be capable of managing multiple library 
versions on their system.

2. Freeze 'pano12' at 2.8.3, fork a library called 'libpano' which 
will not be binary compatible and which will probably change again 
in the future.

-- 
Bruno

Bruno Postle twisted the bytes to say:

 Bruno> On Tue 20-Jun-2006 at 09:29 -0700, Daniel M. German wrote:
 >> Also, who uses the library directly?
 >> 
 >> * Helmut's applications
 >> * Hugin

 Bruno> * PTgui, PTassembler and PTmac (I think)
 Bruno> * Pano2QTVR
 Bruno> * PTlens

I don't think so. It will be against the license of the library. They
probably use PTstitcher and friends as external binaries. 

 Bruno> * Photoshop panorama plugin (but not the Gimp plugin)

 Bruno> ...but these can all adjust to changes in the interface since they 
 Bruno> are actively maintained.

 Bruno> The options seem to be:

 Bruno> 1. Carry on with changes to pano12, anyone who wants to use Helmut's 
 Bruno> binary tools needs to be capable of managing multiple library 
 Bruno> versions on their system.

 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.

I agree. Let me check the history of the changes. I think we should
rolled it back to the point that I moved PTcommon.c to the main
directory of the library.


--
Daniel M. German                  "Nothing is worse than to see ignorance
   Goethe ->                       in action."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

On Tue 20-Jun-2006 at 14:09 -0700, Daniel M. German wrote:
>
> >> Also, who uses the library directly?
>
> Bruno> * PTgui, PTassembler and PTmac (I think)
> Bruno> * Pano2QTVR
> Bruno> * PTlens
>
> I don't think so. It will be against the license of the library. They
> probably use PTstitcher and friends as external binaries. 

Distributing PTStitcher is against the license too.  I guess that 
when it started, Helmut gave them implicit approval and it carried 
on from there.  Once hugin came along I stopped worrying about it.

-- 
Bruno

>> Also, who uses the library directly?
 >> 
 >> * Helmut's applications
 >> * Hugin

 Bruno> * PTgui, PTassembler and PTmac (I think)
 Bruno> * Pano2QTVR
 Bruno> * PTlens
 Bruno> * Photoshop panorama plugin (but not the Gimp plugin)

 Bruno> ...but these can all adjust to changes in the interface since they 
 Bruno> are actively maintained.

 Bruno> The options seem to be:

 Bruno> 1. Carry on with changes to pano12, anyone who wants to use Helmut's 
 Bruno> binary tools needs to be capable of managing multiple library 
 Bruno> versions on their system.

 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:


 2006-05-06 18:22:27 | dmg:2006/05/06 18:22:27           | ChangeLog  | 1.15


There are only commits to the library between 2.8.1 and 2006-05-06
18:22:27:


dangelo     | 2006-04-28 06:39:00 | export exectute_stack_new in windows .dll
dangelo     | 2006-05-05 05:44:55 | updated MSVC project file. Use
                                    $WXWIDGETS_HOME and $JDK_HOME
				    environment variables  instead of hardcoded paths
dangelo     | 2006-05-05 05:46:22 | MSVC does not provide atanh.
dangelo     | 2006-05-05 05:46:48 | fixed return code


Following are the changes to the library after that. There are a
couple of bug fixes that are easy to duplicate. I think the advantage
is that the library is in the state before we moved PTmender routines
into it (and started creating a bunch of bugs and linking problems).




======================================================================



 dmg:2006/05/06 18:22:27         | Added missing entries to Changelog

 dmg:2006/05/06 18:42:13         | * PTcommon.c, PTcommon.h, PTmender.c, Makefile.am: Moved
                                   CreatePanorama to PTcommon.c and all the functions required by it.
                                   
                                   * PTcommon.c (CreatePanorama): Added an error when the type of
                                   panorama is not valid.
                                   
 dmg:2006/05/06 19:48:56         | 2006-05-06  dmg  <dmgerman@...>
                                   
                                   * version.h: Updated version to 2.8.2 and improved ifdefs for
                                   easier maintenance
                                   
                                   * pano12.def: Added ColourBrightness, PTcommon definitions.
                                   
                                   * Moved ColourBrightness.{c,h}, PTcommon.{c,h} to this directory.
                                   

                                   2006-05-06  dmg  <dmgerman@...>
                                   
                                   * PTStitcher.cpp: sent to the attic.
                                   
                                   * PTblender.c, PTtiff2psd, PTmender: Changed name of quietFlag to
                                   ptQuietFlag. I replaced their own version number with libpano.
                                   
                                   * PTcommon.c, PTcommon.h, PTmender.c, Makefile.am: Moved
                                   CreatePanorama to PTcommon.c and all the functions required by it.
                                   
                                   * PTcommon.c (CreatePanorama): Added an error when the type of
                                   panorama is not valid.
                                   
 dmg:2006/05/06 22:03:57         | 2006-05-06  dmg  <dmgerman@...>
                                   
                                   * Makefile.am (STD_HDR): Install PTcommon.h
                                   
 dmg:2006/05/06 22:58:09         | * PTcommon.h (CreatePanorama): Added StringtoFullPath
                                   
                                   * pano12.def: Exported StringtoFullPath
                                   
                                   * PTcommon.h: removed <tiffio.h> from its includes.
                                   
 dmg:2006/05/07 07:53:45         | 2006-05-07  dmg  <dmgerman@...>
                                   
                                   * version.h: Updated version to 2.8.3
                                   
                                   * PTcommon.c (SetBestAlphaChannel16bits): Implemented function.
                                   
                                   2006-05-06  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c: (BlendLayers): Added support for 16 bit images.
                                   
                                   * PTcommon.c (BlendLayers16Bit): Added function.
                                   
 maxlyons:2006/05/15 03:59:29    | Changed #include <filter.h> to #include "filter.h" (this prevented compilation with MingW)
                                   
 maxlyons:2006/05/15 03:59:56    | Changed #include <filter.h> to #include "filter.h" (this prevented compilation with MingW)
                                   Changed call to execute_stack to execute_stack_new (necessary as a result of modification to Transformation function type)
                                   Removed InsertFileName definition.  This is already defined in PTPicker, and prevented compilation with MingW.
                                   
 maxlyons:2006/05/15 04:00:16    | Updated Makefile.win32 to include missing references to sys_common.c, PTCommon.c, hdrfile.c, rgbe.c, ColourBrightness.c...should now build correctly using MingW
                                   
 maxlyons:2006/05/15 04:00:36    | Removed duplicate entry for "StringtoFullPath" (exported twice).
                                   
 maxlyons:2006/05/15 04:01:21    | Fixed comparison between pointer and integer error (line 102)
                                   
 maxlyons:2006/05/15 04:04:59    | Removing old versions of ptcommon and colourbrightness from the tools...these have already been moved into libpano main directory
                                   
 maxlyons:2006/05/15 04:06:22    | no message
                                   
 brunopostle:2006/05/15 20:30:29 | make version 2.8.3 same everywhere
                                   
 maxlyons:2006/05/16 02:21:30    | Fixing bug in fast transform logic that caused crash when destRect.left != 0 (i.e. producing cropped TIFF output)
                                   
 maxlyons:2006/05/16 02:22:31    | no message
                                   
 dmg:2006/05/16 04:12:19         | 2006-05-15  dmg  <dmgerman@...>
                                   
                                   * resample.c: Fixed compilation warnings by moving #define
                                        unsigned inside the body of the functions.
                                   
 dmg:2006/05/16 04:18:13         | 2006-05-15  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c (CreatePanorama): Fixed a typo related to QTVR
                                        images. I also renamed Unknown07 to Create_QTVR
                                   
 dangelo:2006/05/21 16:02:28     | fixed "SetMakeParams: Unsupported input image projection" error when using
                                   circular fisheye input images.
                                   
 dangelo:2006/05/21 16:04:24     | bugfix: vararg processing of PrintError() was broken
                                   
 dangelo:2006/05/21 18:29:00     | stdint is not provided by M$ Visual C.
                                   
 dmg:2006/05/22 05:54:21         | -05-22  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c: Checked return value of each TIFFWriteScanline. It
                                   now returns an error when it cannot write to the output (instead of
                                   just continue blindly). Added Error and Warning handler for TIFF
                                   library so the errors are now reported using the PTtools error
                                   handler.
                                   
                                   2006-05-20  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c (CreatePanorama): Fixed a bug in TIFF_mask (the
                                   program was not ending after where it should have)
                                   
 dmg:2006/05/22 09:43:57         | (CreatePSD): Make sure PSD is 8 bit if it contains more than 1
                                   layer (we do not support multi-layer 16bit images). Cleaned up the
                                   function and added some comments.
                                   (ComputeStitchingMask8bits): Cleanedup the function (still more
                                   work to do)
                                   
 dmg:2006/05/23 00:00:36         | 2006-05-23  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c (TiffGetImageParameters, TiffSetImageParameters):
                                   Make sure compression is propagated at further stages
                                   (CreatePanorama): Implemented support for C:NONE
                                   (CreatePanorama): Implemented support for C:DEFLATE
                                   
 maxlyons:2006/05/23 12:42:46    | Removing old comments
                                   
 maxlyons:2006/05/23 12:45:25    | Adding CropInfo struct...used for processed cropped images
                                   
 maxlyons:2006/05/23 12:55:36    | Fixing bad CR/LF combinations
                                   
 dmg:2006/05/23 22:54:48         | 2006-05-24  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c (TiffSetImageParameters, TiffGetImageParameters):
                                   Make sure ROWSPERSTRIP is propagated.
                                   
 maxlyons:2006/05/24 05:00:31    | changed #include syntax
                                   
 maxlyons:2006/05/24 05:03:21    | writePSD, writeLayerAndMask, writeChannelData, getImageRectangle, addLayer.  Reworked to handle "cropped" files.
                                   
 maxlyons:2006/05/24 05:04:43    | All logic has been reworked so that "cropped" TIFF files can be used throughout the stitching process for all currently supported output formats.  (Cropped TIFF files are those that are just large enough to contain       the remapped image, and the offset/full size information is stored in the TIFF header).  Modified functions include ReplaceAlphaChannel, CreateAlphaChannels, AddStitchingMasks, FlattenTIFF, createPanorama.  New functions include getCropInformationFromTiff, setFullSizeImageParameters.
                                   
                                   Simplified ComputeStitchingMask8bits syntax
                                   
                                   CreatePanorama.  Reworked logic to handle intermediate output files and produce final output in various formats.  Added logic that decides when to use cropped TIFF as intermediate format based on chosen output format.  TODO: this could use some tidy up, and it might be a good idea to have cropped TIFF as the default intermediate format for TIFF_m and TIFF_mask, and include a function to "expand" the cropped TIFFs to full size when finished (if the user requests non-cropped TIFF).
                                   
                                   Reluctantly commented out calls to TIFFSetWarningHandler and TIFFSetErrorHandler...these cause to GCC to abort, with a series of errors about multiple definition of TIFF functions in libpano and libtiff.
                                   
                                   Changed title bar of progress dialog to indicate currently processing image number (indexed at 1) and total images to be processed.
                                   
 maxlyons:2006/05/24 05:05:07    | getCropInformation. Adding declaration.
                                   
 maxlyons:2006/05/24 05:05:19    | readTIFF.  Storing filename of TIFF in im->name.
                                   
 maxlyons:2006/05/24 05:12:30    | Cropped TIFF modifications (mostly)
                                   
 dmg:2006/05/27 22:35:00         | 2006-05-27  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c (TiffGetImageParameters): Fixed incorrect error message.
                                        Removed tabs from entire file (some of them completely messed the
                                        format), reindented entire file
                                   
                                   * tiff.c: Changed TIFFTAG_ROWSPERSTRIP to 1.
                                   
 dmg:2006/05/28 01:32:45         | Added PTuncrop, a program to conver cropped tiffs to regular tiffs
                                   
 dmg:2006/05/28 01:36:54         | * PTcommon.c (CreatePanorama): Removed some ugly formatting I
                                        introduced in a recent commit
                                   
 dmg:2006/05/28 02:34:56         | * PTcommon.c (CreatePanorama): Removed some ugly formatting I
                                        introduced in a recent commit
                                        (CreatePanorama): Fixed bug of the missing column/row introduced
                                        in cropped files.
                                   
 dmg:2006/05/28 02:43:50         | I forgot to add PTuncrop.c
                                   
 dmg:2006/05/28 03:37:00         | created first battery of tests for a simple, 2 images, panorama
                                   
 dmg:2006/05/28 03:46:47         | added tiff_lzw
                                   
 dmg:2006/05/28 03:52:30         | Ok, the previous ones were way too large, these are significantly smaller
                                   
 dmg:2006/05/28 03:55:26         | script should be fast transform
                                   
 dmg:2006/05/28 03:57:14         | committed lzw
                                   
 brunopostle:2006/05/28 20:35:45 | install pt_stdint.h with `make install`
                                   
 maxlyons:2006/05/29 17:11:27    | changes fix various compilation problems:
                                   
                                   * Moved declaration of three functions from ptcommon.h to new ptttiff.h file.  * Updated includes in PTcommon.c and PTuncrop.c
                                   * Updated pano12.def and libpano12.def to  include the same, latest, exports
                                   
 maxlyons:2006/05/29 18:22:57    | changes fix various compilation problems:
                                   
                                   * Moved declaration of three functions from ptcommon.h to new ptttiff.h file.  * Updated includes in PTcommon.c and PTuncrop.c
                                   * Updated pano12.def and libpano12.def to  include the same, latest, exports
                                   
 maxlyons:2006/05/30 02:46:02    | CheckParams: allowing optimizer to work with new projections
                                   
 maxlyons:2006/05/30 02:48:53    | * Moving uncrop logic from ptuncrop.c to ptcommon.c.  Creating uncropTiff function
                                   * Adding uncropTiff function declaration to pttiff.h
                                   * Making cropped TIFF the intermediate format for all processing, regardless of output format.  Uncropped TIFFs can be generated, if needed, from intermediate cropped TIFFs by calling new uncropTiff function.
                                   
 maxlyons:2006/05/30 02:50:44    | no message
                                   
 brunopostle:2006/05/30 19:56:28 | Replace old build instructions with correct instructions
                                   
 maxlyons:2006/06/01 02:49:27    | PTCommon.c: Fixed bug in getROI
                                   
 maxlyons:2006/06/01 02:50:19    | no message
                                   
 maxlyons:2006/06/04 21:42:11    | Changed behavior for input file name parsing.  If the script is specified on the command line with a path (e.g. c:BACKSLASHsomeBACKSLASHpath]myscript.txt), this path was prepended to all of the image names in the script, regardless of whether those image names were also specified with a full qualified path.  This change adds a check so that the script path is only prepended to the image names, if the image names don't already contain path information.
                                   
 maxlyons:2006/06/04 21:43:30    | Fixing bug with morph-to-fit.  Memory allocated with malloc was being incorrectly freed with myfree leading to random crashes.
                                   
 maxlyons:2006/06/04 21:45:17    | no message
                                   
 dwilkins42:2006/06/05 06:28:10  | Put the tests subdirectory under autotools control. Ensure all files all in the dist tarball
                                   
 dangelo:2006/06/06 19:55:48     | moved InsertFileName to PTcommon.c
                                   
 brunopostle:2006/06/11 09:44:33 | put pttiff.h in the tarball
                                   
 maxlyons:2006/06/11 17:01:22    | Changes to support "cropped tiff" processing when using colour/brightness correction in PTMender.  Changes also allow pttiff2psd to work with cropped tiff output as well.
                                   
 maxlyons:2006/06/11 17:03:56    | no message
                                   
 dmg:2006/06/12 03:21:05         | Updated tests, use tiffcmp instead of diff
                                   
 dmg:2006/06/12 03:41:21         | Made sure that tests work under linux
                                   
 dmg:2006/06/12 03:41:51         | Create .psd not .PSD extensions for photoshop files
                                   
 dmg:2006/06/12 03:55:52         | removed a temp file that was left during the uncropping
                                   
 dmg:2006/06/12 04:54:31         | improved behaviour during errors
                                   
 brunopostle:2006/06/12 21:05:45 | Increment version to 2.8.4
                                   
 jim0watters:2006/06/13 03:55:49 | updated VC project file and fixed compile problems of missing header files.
                                   
 dmg:2006/06/13 06:08:53         | Do not run tests in every make, only with indicated: make test
                                   
 dmg:2006/06/13 06:13:56         | 2006-06-12  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c (ReplaceAlphaChannel): The images created in this
                                   routine were not labeled as cropped. This patch fixes the
                                   problem. The test case did not catch this problem. We need a
                                   360/180 one.
                                   
 dmg:2006/06/13 06:18:27         | 2006-06-12  dmg  <dmgerman@...>
                                   
                                   * Makefile.am (all): Undo the changes below... I decided instead
                                   to remove the test directory from the make in the root
                                   directory. Too bad CVS does not support transactions and rollbacks.
                                   
                                   * README.txt: run "make test" to, you got it, run the test
                                   * Makefile.am (all): Removed test from default Make.
                                   
 dmg:2006/06/13 06:54:31         | Cleaned up most compiler warnings, reinserted tiff error handler for everything but windows
                                   
 dmg:2006/06/13 07:19:41         | Fixed minor typo in ChangeLog
                                   
 jim0watters:2006/06/13 11:26:20 | *** empty log message ***
                                   
 maxlyons:2006/06/14 03:17:07    | Adding new dieWithError function to print error message and exit program with non-zero exit code
                                   
 maxlyons:2006/06/14 03:28:26    | Modifying getROI function to better calculate ROI for images in projects with 360/180 FOV.  Not sure if this completely eliminates problems, but is certainly a step in the right direction.
                                   Adding error checking to setCropInformationInTiff function.
                                   Removing check for cropped TIFF in uncropTIFF...it is possible for a cropped TIFF to have x and y offset equal to zero, so this check could have caused problems.
                                   
 maxlyons:2006/06/14 03:31:57    | no message
                                   
 brunopostle:2006/06/14 20:17:43 | Put tests in tarball, but only run them with 'make check'.
                                   
 dmg:2006/06/16 06:24:51         | 2006-06-15  dmg  <dmgerman@...>
                                   
                                   * 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
                                   
 dmg:2006/06/16 06:54:20         | 2006-06-15  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c: Major reindent, removed tabs
                                   
 dmg:2006/06/16 07:25:24         | update tests
                                   
 dmg:2006/06/16 07:27:36         | updated test
                                   
 dmg:2006/06/16 07:35:52         | 2006-06-16  dmg  <dmgerman@...>
                                   
                                   * panoAutomateTest.pl: Added PSD_mask to the tests.
                                   
 dmg:2006/06/16 07:39:59         | 2006-06-16  dmg  <dmgerman@...>
                                   
                                   * PTcommon.c (CreatePanorama): The process for creating PSD_mask
                                   and PSD_nomask was inverted.
                                   
 
                                   
                                   





 Bruno> -- 
 Bruno> Bruno


 Bruno> _______________________________________________
 Bruno> PanoTools-devel mailing list
 Bruno> PanoTools-devel@...
 Bruno> https://lists.sourceforge.net/lists/listinfo/panotools-devel

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

Daniel M. German wrote:
> What is worth discussing is what is necessary to maintain in pano12? I
> would say it only needs to have bug fixes, and nothing else. No new
> features. The time invested in doing so will be significantly less
> than the time invested making sure that improvements work with the old
> binaries.
>   
I have to agree.  If that means going back a bit, then that is what we 
will have to do.


-- 
Jim Watters

Yahoo ID: j1vvy ymsgr:sendIM?j1vvy
jwatters @ photocreations . ca
http://photocreations.ca

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:

I thought that binary compatibility had been maintained until the 
day before I released 2.8.4?

Either way, I propose creating a CVS branch for the 
backwards-compatible pano12 and changing the files in the trunk so 
the library is built as pano.dll, libpano.so etc...

Though I'd like to hear from people who use the library first as 
they need to make changes too, Max, Pablo, any comments?  (Pablo is 
away at the moment).

-- 
Bruno

> Either way, I propose creating a CVS branch for the 
> backwards-compatible pano12 and changing the files in the trunk so 
> the library is built as pano.dll, libpano.so etc...
> 
> Though I'd like to hear from people who use the library first as 
> they need to make changes too, Max, Pablo, any comments?  (Pablo is 
> away at the moment).

I have mixed feelings about this.  When I put on my Pano Tools developer hat, 
it feels like the right thing to do.  We don't want to be constrained in the 
development by maintaining compatibility with a bunch of binaries for which we 
don't have source code.

But, when I put on my PTAssembler hat, I'm not so excitied about the idea.  I'm 
envisioning distributing two versions of the DLL (one for PTStitcher users and 
one for PTMender, PTOptimizer), reworking PTAssembler and its associated 
documentation.  I fear a barrage of confused e-mails from users (most of whom 
don't have the technical sophistication of the folks on this list) when they 
find themselves in "DLL hell"!  As much as I'd like, I don't have control over 
end-users' machines, and they frequently end up with weird combinations of out-
dated versions of files, copies of a DLL in seventeen different folders and so 
on...I fear that this will add to the confusion.

But, as I indicated earlier, I'm happy to follow the majority decision.  it 
sounds like branching seems to be the popular vote so far, although it isn't 
clear to me if all the relevant stakeholders have commented.

Also how do we enforce that fixes made in one branch get made in the other 
branch as well?  In an ideal world, I know that all contributers would make 
changes in both branches when appropriate.  In practice, I fear that this may 
not happen.  Is there a "merge czar" or someone else who will make this happen? 


Max

Max Lyons twisted the bytes to say:


 Max> But, when I put on my PTAssembler hat, I'm not so excitied about the idea.  I'm 
 Max> envisioning distributing two versions of the DLL (one for PTStitcher users and 
 Max> one for PTMender, PTOptimizer), reworking PTAssembler and its associated 
 Max> documentation.  I fear a barrage of confused e-mails from users (most of whom 
 Max> don't have the technical sophistication of the folks on this list) when they 
 Max> find themselves in "DLL hell"!  As much as I'd like, I don't have control over 
 Max> end-users' machines, and they frequently end up with weird combinations of out-
 Max> dated versions of files, copies of a DLL in seventeen different folders and so 
 Max> on...I fear that this will add to the confusion.

hi Max,

Why don't you build statically PTmender? In the case of PTstitcher it
wasn't an option, but for PTmender there is actually no reason to
distribute DLLs.

dmg



--
Daniel M. German                  "No iron can stab the heart
                                   with such force as a full
    Isaac Babel ->                 stop put just at the right place."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

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?

yes, it is binary compatible, but buggy. It creates panoramas con big
black patches.


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

yes, I think it is a good idea to discuss it until we all agree on
what to do.


daniel
--
Daniel M. German                  "It is a kind of spiritual snobbery
   Albert Camus  ->                to think one can be happy without money."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Bruno Postle wrote:
> Daniel M. German wrote:
>
> I thought that binary compatibility had been maintained until the 
> day before I released 2.8.4?
> 
> Either way, I propose creating a CVS branch for the 
> backwards-compatible pano12 and changing the files in the trunk so 
> the library is built as pano.dll, libpano.so etc...
> 
> Though I'd like to hear from people who use the library first as 
> they need to make changes too, Max, Pablo, any comments?  (Pablo is 
> away at the moment).

I'm back now. :)

I think creating a new branch is the only way for a future sustainable
development. Actually from my point of view, not much is lost if the binary
compatible pano12 is moved to "bugfix only" mode, if the new library gets a
different name, so that PTStitcher etc. cannot link to it by accident.

Obviously, we want to avoid the situtation we have today, and the new
library will probably not be binary compatible between major versions. As
Daniel mentioned, Windows binaries can be statically linked (I'm doing this
with hugin and nona already (for its "private" libraries), to avoid problems
for the average Windows user).

ciao
  Pablo

Max Lyons twisted the bytes to say:

 Max> But, as I indicated earlier, I'm happy to follow the majority decision.  it 
 Max> sounds like branching seems to be the popular vote so far, although it isn't 
 Max> clear to me if all the relevant stakeholders have commented.

 Max> Also how do we enforce that fixes made in one branch get made in the other 
 Max> branch as well?  In an ideal world, I know that all contributers would make 
 Max> changes in both branches when appropriate.  In practice, I fear that this may 
 Max> not happen.  Is there a "merge czar" or someone else who will make this happen? 


I think, Max, you represent the largest proportion of stakeholders for
the old pano12. You are probably the person that knows best what needs
and can be fixed in the pano12. I would say you are the natural person
to decide how pano12 evolves from this point on. I think that its main
goal is to support PTstitcher as it is today. I think your opinions are
probably the most important on the future of pano12. So yes, you are
the "pano12" czar.

I think each library will develop on its own way, but there might be
somethings that might migrate from one library to the other.

What do you think?

--
dmg



 Max> _______________________________________________
 Max> PanoTools-devel mailing list
 Max> PanoTools-devel@...
 Max> https://lists.sourceforge.net/lists/listinfo/panotools-devel

--
Daniel M. German                  "If Microsoft ever does applications
   Linus Torvalds ->               for Linux it means I've won."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

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> PanoTools-devel@...
 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 .

> So yes, you are the "pano12" czar...What do you think?

I'm not quite sure that I signed up for that job, particularly since I wouldn't 
split the code if I was in charge of making the decisions!

I'm happy to contribute where I can, but I don't see myself as being the 
coordinator of the two different versions.  My eneriges will be devoted, in the 
short run at least, to (a) to adding features/fixes to the new code,  (b) 
reworking the PTAssembler code and documentation to accommodate the two 
different code bases, and (c) answering e-mails from confused users!

Also...if we are going to create a new module for the code then I would suggest 
using a name other than pano12.  If I understand correctly, the current 
proposal is to have "pano12" and "libpano12"? Or something similar?  My 
experience with the average end user is that these will be assumed to be the 
same thing.  I'd suggest "pano20" or something more obviously different.

Max


> 
> --
> dmg
> 
> 
> 
>  Max> _______________________________________________
>  Max> PanoTools-devel mailing list
>  Max> PanoTools-devel@...
>  Max> https://lists.sourceforge.net/lists/listinfo/panotools-devel
> 
> --
> Daniel M. German                  "If Microsoft ever does applications
>    Linus Torvalds ->               for Linux it means I've won."
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
> 
>

>> So yes, you are the "pano12" czar...What do you think?
 Max> I'm not quite sure that I signed up for that job, particularly since I wouldn't 
 Max> split the code if I was in charge of making the decisions!

Sorry Max, I didn't mean it in a bad way. I apologize if it sounded
that way.

I think that at the end we all want to have better software that we
can all use. Perhaps our motivations are different (and this is why we
have differences of opinion). 


--
Daniel M. German                  "Speak not about what you have read,
   Azerbaijani Proverb ->          but about what you have understood."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

On Tue 27-Jun-2006 at 00:03 -0400, Max Lyons wrote:
>
> Also...if we are going to create a new module for the code then I would suggest 
> using a name other than pano12.  If I understand correctly, the current 
> proposal is to have "pano12" and "libpano12"? Or something similar?  My 
> experience with the average end user is that these will be assumed to be the 
> same thing.  I'd suggest "pano20" or something more obviously different.

The binary compatible library has to be called 'pano12' (or 
'libpano12' on linux) as that is what PTStitcher is looking for.

Daniel is suggesting taking advantage of a mistake (I made) in the 
existing naming scheme - The current CVS module is called libpano, 
but it should have been called 'libpano12'.

So if a new CVS module, called 'libpano12', is created for the 
binary compatible code, this would build a library with the same 
name.

We can then keep the existing 'libpano' CVS module, and change the 
library name to match the CVS name.

So the CVS layout would look like this:

  libpano CVS: new library called PANO.DLL, for use with PTmender

  libpano12 CVS: old library called PANO12.DLL, for use with PTStitcher

Hope that makes sense, I think it does.

-- 
Bruno

On Tue, June 27, 2006 5:11 am, Bruno Postle said:
>
> libpano CVS: new library called PANO.DLL, for use with PTmender
>
> libpano12 CVS: old library called PANO12.DLL, for use with PTStitcher
>
> --
> Bruno

I think a name that indicates a newer version would work better and cause less
confusion.  Either pano13 or pano20 sound good to me.

Projects currently under development will likely stop using pano12 and move to the next
version.

Besides bug fixing I don’t see any more being added to pano12.  All new features should
be added to only the new library.  Pano12 will be kept for backwards compatibility only.



-- 
Jim Watters

Yahoo ID: j1vvy ymsgr:sendIM?j1vvy
jwatters @ photocreations . ca
http://photocreations.ca

Bruno Postle twisted the bytes to say:

 Bruno> On Tue 27-Jun-2006 at 00:03 -0400, Max Lyons wrote:
 >> 
 >> Also...if we are going to create a new module for the code then I would suggest 
 >> using a name other than pano12.  If I understand correctly, the current 
 >> proposal is to have "pano12" and "libpano12"? Or something similar?  My 
 >> experience with the average end user is that these will be assumed to be the 
 >> same thing.  I'd suggest "pano20" or something more obviously different.

 Bruno> The binary compatible library has to be called 'pano12' (or 
 Bruno> 'libpano12' on linux) as that is what PTStitcher is looking for.

 Bruno> Daniel is suggesting taking advantage of a mistake (I made) in the 
 Bruno> existing naming scheme - The current CVS module is called libpano, 
 Bruno> but it should have been called 'libpano12'.

 Bruno> So if a new CVS module, called 'libpano12', is created for the 
 Bruno> binary compatible code, this would build a library with the same 
 Bruno> name.

 Bruno> We can then keep the existing 'libpano' CVS module, and change the 
 Bruno> library name to match the CVS name.

Yes, that is the idea: one module for libpano12, and one for libpano
(even if the library is actually called pano20, panoNG, or
pano-thefuture :)

 Bruno> So the CVS layout would look like this:

  libpano CVS: new library called PANO.DLL, for use with PTmender

We might on a different name for the library, but the module will
stay that way.


  libpano12 CVS: old library called PANO12.DLL, for use with PTStitcher

Yeap.



--
Daniel M. German                  "Great algorithms are
   Francis Sullivan ->             the poetry of computation"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .