From: dmg <dmg...@uv...> - 2006-06-19 22:51:34
|
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 . |
From: Max L. <max...@ve...> - 2006-06-19 23:40:21
|
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). |
From: Daniel M. G. <dmg...@uv...> - 2006-06-20 03:21:05
|
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 <dmg...@uv...> * 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 . |
From: Rik L. <rj....@co...> - 2006-06-20 15:30:28
|
Bruno Postle wrote: > What is remaining in PTmender? Morphing? z-line extended depth of field? I don't know for sure that these are *not* in PTmender. I just don't recall much discussion, and they have been problematic in the past. --Rik |
From: Daniel M. G. <dmg...@uv...> - 2006-06-20 16:40:06
|
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 . |
From: Jim W. <jwa...@ph...> - 2006-06-21 02:28:32
|
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 |
From: Bruno P. <br...@po...> - 2006-06-20 09:01:28
|
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 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. What is remaining in PTmender? * Other input formats (full-frame and circular fish-eye, equirectangular and cylindrical) - Some of these kind-of work already. * Feathering - Is this really necessary. -- Bruno |
From: Fulvio S. <fu...@fs...> - 2006-06-20 15:43:49
|
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 |
From: Jim W. <jwa...@ph...> - 2006-06-20 15:58:43
|
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 |
From: Daniel M. G. <dmg...@uv...> - 2006-06-20 16:29:35
|
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 . |
From: Bruno P. <br...@po...> - 2006-06-20 20:40:29
|
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 |
From: Daniel M. G. <dmg...@uv...> - 2006-06-20 23:24:20
|
>> 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * version.h: Updated version to 2.8.3 * PTcommon.c (SetBestAlphaChannel16bits): Implemented function. 2006-05-06 dmg <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * 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 <dmg...@uv...> * panoAutomateTest.pl: Added PSD_mask to the tests. dmg:2006/06/16 07:39:59 | 2006-06-16 dmg <dmg...@uv...> * PTcommon.c (CreatePanorama): The process for creating PSD_mask and PSD_nomask was inverted. Bruno> -- Bruno> Bruno Bruno> _______________________________________________ Bruno> PanoTools-devel mailing list Bruno> Pan...@li... 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 . |
From: Max L. <max...@ve...> - 2006-06-21 12:41:26
|
> 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 |
From: Daniel M. G. <dmg...@uv...> - 2006-06-21 23:44:08
|
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 . |
From: Daniel M. G. <dmg...@uv...> - 2006-06-26 21:10:46
|
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> Pan...@li... 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 . |
From: Max L. <max...@ve...> - 2006-06-27 04:04:10
|
> 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> Pan...@li... > 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 . > > |
From: Daniel M. G. <dmg...@uv...> - 2006-06-27 05:37:11
|
>> 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 . |
From: Bruno P. <br...@po...> - 2006-06-27 09:11:42
|
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 |
From: Jim W. <jwa...@ph...> - 2006-06-27 13:21:26
|
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 dont 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 |
From: Daniel M. G. <dmg...@uv...> - 2006-06-27 18:27:16
|
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 . |
From: Daniel M. G. <dmg...@uv...> - 2006-06-20 21:09:14
|
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 . |
From: Bruno P. <br...@po...> - 2006-06-20 22:16:51
|
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 |
From: Bruno P. <br...@po...> - 2006-06-21 08:24:29
|
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 |
From: Daniel M. G. <dmg...@uv...> - 2006-06-21 23:59:38
|
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 . |
From: Pablo d'A. <pab...@we...> - 2006-06-25 18:55:06
|
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 |