You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
(4) |
Jun
(8) |
Jul
|
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(9) |
Dec
|
2005 |
Jan
(13) |
Feb
(3) |
Mar
(5) |
Apr
(12) |
May
(22) |
Jun
|
Jul
(10) |
Aug
(7) |
Sep
(3) |
Oct
(7) |
Nov
(10) |
Dec
(13) |
2006 |
Jan
(22) |
Feb
(20) |
Mar
(5) |
Apr
(50) |
May
(103) |
Jun
(98) |
Jul
(63) |
Aug
(35) |
Sep
(32) |
Oct
(149) |
Nov
(77) |
Dec
(113) |
2007 |
Jan
(145) |
Feb
(97) |
Mar
(109) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(19) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
2008 |
Jan
(5) |
Feb
(10) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(16) |
Sep
(2) |
Oct
|
Nov
|
Dec
(3) |
2009 |
Jan
(2) |
Feb
(2) |
Mar
(6) |
Apr
(5) |
May
(19) |
Jun
|
Jul
(5) |
Aug
(27) |
Sep
(188) |
Oct
(31) |
Nov
(23) |
Dec
(17) |
2010 |
Jan
(48) |
Feb
(14) |
Mar
(11) |
Apr
(3) |
May
(12) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(10) |
Oct
(6) |
Nov
|
Dec
|
2011 |
Jan
(51) |
Feb
(77) |
Mar
(39) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2012 |
Jan
(1) |
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(7) |
Dec
|
2013 |
Jan
(3) |
Feb
|
Mar
|
Apr
(4) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(11) |
2014 |
Jan
(14) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kornel B. <Kor...@be...> - 2013-12-30 00:12:19
|
Am Sonntag, 29. Dezember 2013 um 23:36:03, schrieb Bruno Postle <br...@po...> > On Mon 23-Dec-2013 at 14:34 +0100, Kornel Benko wrote: > > ATM we compile conditionally PTAInterpolate depending on the value > > of HAVE_JAVA. > > > > I'd like to make this variable a cmake-option, to have it > > available also in the cmake-gui. > > Thanks Kornel I see you committed this. It would be nice to remove > the autotools option altogether, maybe for this release. > > I haven't done much checking but I compared the results of `make > install` with the old autotools build and the cmake build: > > cmake creates a static library in addition to the dynamic library: > > ${libdir}/libpano13.a This was tricky at that time, but, as I remember, intended. > This is an option (default=no) with the autotools build, which seems > like the right way to do it, we don't want to encourage static > linking. > > cmake installs lots of documentation files into /usr/include, these > should really go into /usr/share/doc (or not be installed at all): > > ${includedir}/pano13/AUTHORS > ${includedir}/pano13/COPYING > ${includedir}/pano13/README > ${includedir}/pano13/doc > ${includedir}/pano13/doc/Optimize.txt > ${includedir}/pano13/doc/PTblender.readme > ${includedir}/pano13/doc/PTmender.readme > ${includedir}/pano13/doc/stitch.txt What about /usr/share/pano13/doc? Or /usr/share/doc/pano13? > autotools builds with '-O2', whereas cmake builds with '-O3 > -DNDEBUG', I'm not sure which is best practice here? O3 is slower to compile, but should be faster at execute, so I'd prefer O3. Kornel |
From: Bruno P. <br...@po...> - 2013-12-29 23:36:12
|
On Mon 23-Dec-2013 at 14:34 +0100, Kornel Benko wrote: > ATM we compile conditionally PTAInterpolate depending on the value > of HAVE_JAVA. > > I'd like to make this variable a cmake-option, to have it > available also in the cmake-gui. Thanks Kornel I see you committed this. It would be nice to remove the autotools option altogether, maybe for this release. I haven't done much checking but I compared the results of `make install` with the old autotools build and the cmake build: cmake creates a static library in addition to the dynamic library: ${libdir}/libpano13.a This is an option (default=no) with the autotools build, which seems like the right way to do it, we don't want to encourage static linking. cmake installs lots of documentation files into /usr/include, these should really go into /usr/share/doc (or not be installed at all): ${includedir}/pano13/AUTHORS ${includedir}/pano13/COPYING ${includedir}/pano13/README ${includedir}/pano13/doc ${includedir}/pano13/doc/Optimize.txt ${includedir}/pano13/doc/PTblender.readme ${includedir}/pano13/doc/PTmender.readme ${includedir}/pano13/doc/stitch.txt autotools builds with '-O2', whereas cmake builds with '-O3 -DNDEBUG', I'm not sure which is best practice here? -- Bruno |
From: Kornel B. <Kor...@be...> - 2013-12-23 13:35:04
|
Hi, ATM we compile conditionally PTAInterpolate depending on the value of HAVE_JAVA. I'd like to make this variable a cmake-option, to have it available also in the cmake-gui. In order to use it, we have to know the correct include dirs. This patch (which results from a collaboration with Terry Duell) does that. There are some not-nice things though: 1.) I am not happy with the option-name HAVE_JAVA. Preferable would be 'ENABLE_JAVA' or such, but changing it means also to change tools/CMakelLists.txt and the comment about HAVE_JAVA. And it would break the compatibility to previous settings. 2.) The default (HAVE_JAVA == OFF) does not play nice (for rpm) with libpano13.spec:88, where PTAInterpolate is unconditionally installed. OTOH setting it to ON breaks builds for people without the needed files. 3.) I am also unsure if we should automatically determine the value of this variable, depending on results from find_package() (for Java and JNI) Kornel |
From: Andreas M. <ame...@be...> - 2013-12-21 16:00:15
|
Andreas Metzler <ame...@be...> wrote: > On 2013-12-17 Bruno Postle <br...@po...> wrote: >> libpano13 is the PanoTools library for panoramic imaging. >> A libpano13-2.9.19 beta1 tarball has been uploaded to sourceforge, this is >> for testing but is expected to be very similar to the final release: [...] > Thanks for jumpstarting the release process. FWIW I have uploaded to Debian/experimental to get some autobuild exposure on non-mainstream architectures. However it is going to take a couple of days until the packages are available for download since they will need some manual processing by ftpmasters due to the soname bump. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' |
From: Andreas M. <ame...@be...> - 2013-12-20 19:01:22
|
On 2013-12-17 Bruno Postle <br...@po...> wrote: > libpano13 is the PanoTools library for panoramic imaging. > A libpano13-2.9.19 beta1 tarball has been uploaded to sourceforge, this is > for testing but is expected to be very similar to the final release: [...] Hello, Thanking for jumpstarting the release process. Taking a quick look: 1. License headers seem to have been copied from libtool without change: * You should have received a copy of the GNU General Public License * along with GNU Libtool; see the file COPYING. If not, a copy * can be downloaded from http://www.gnu.org/licenses/gpl.html, or * obtained by writing to the Free Software Foundation, Inc., * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. s/GNU Libtool/this software/ 2. Some typos: --------------------------------- --- libpano13-2.9.19~beta1+dfsg.orig/PTcommon.c +++ libpano13-2.9.19~beta1+dfsg/PTcommon.c @@ -896,7 +896,7 @@ int panoCreatePanorama(fullPath ptrImage croppedTIFFIntermediate = 0; } } else { - PrintError("No support for this ouput image format (%s). Output will be TIFF_m", output_file_format); + PrintError("No support for this output image format (%s). Output will be TIFF_m", output_file_format); } // enable this to avoid cropped tiffs. usually for testing //croppedTIFFIntermediate = 0; --- libpano13-2.9.19~beta1+dfsg.orig/tools/panoinfo_unix.c +++ libpano13-2.9.19~beta1+dfsg/tools/panoinfo_unix.c @@ -106,7 +106,7 @@ int main(int argc,char *argv[]) int j; pano_projection_features features; if (!panoProjectionFeaturesQuery(i, &features) ) { - printf("Error trying to retreive features of projection index %d\n", i); + printf("Error trying to retrieve features of projection index %d\n", i); continue; } printf("Projection index: %d name: %s\n", features.projection, features.name); --------------------------------- 3. Could you please include the patch in <https://bugs.launchpad.net/panotools/+bug/734867>? cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' |
From: Bruno P. <br...@po...> - 2013-12-19 00:22:29
|
On Wed 18-Dec-2013 at 12:32 -0500, marthter wrote: > > I noticed on the Hugin wikipedia page that PanoramaTools' feature > matching was a subject of 2010 Google Summer of Code... > "implementing a patent-free image feature detector and control > point generator". > Can anyone update me on if that SoC project went ahead, or a wiki > page where more information is provided? The working feature detector was eventually created in Hugin rather than panotools, see the 'src/hugin_cpfind' folder in the Hugin sourcecode. -- Bruno |
From: marthter <mar...@ya...> - 2013-12-18 17:59:50
|
Dear list members, I noticed on the Hugin wikipedia page that PanoramaTools' feature matching was a subject of 2010 Google Summer of Code... "implementing a patent-free image feature detector and control point generator". However most other mentions I can find on the panotools.org site refer to "control points" and tools for selecting them, which seems to suggest this is still a somewhat manual process. Can anyone update me on if that SoC project went ahead, or a wiki page where more information is provided? I am exploring the possibility of using PanoramaTools not for image stitching but for feature matching for a Structure from Motion (SfM) pipeline. The SIFT algorithm seems popular in this role but is patented so I'm looking into other possibilities. Thanks and best regards. Martin |
From: Kornel B. <Kor...@be...> - 2013-12-17 21:09:45
|
Am Dienstag, 17. Dezember 2013 um 20:50:17, schrieb Kornel Benko <Kor...@be...> > Am Dienstag, 17. Dezember 2013 um 19:18:07, schrieb Bruno Postle <br...@po...> > > On Tue 17-Dec-2013 at 19:05 +0000, Bruno Postle wrote: > > >libpano13 is the PanoTools library for panoramic imaging. > > > > > >A libpano13-2.9.19 beta1 tarball has been uploaded to sourceforge, this is > > >for testing but is expected to be very similar to the final release: > > > > > >https://sourceforge.net/projects/panotools/files/libpano13/libpano13-2.9.19/ > > > > I should add that I'm still using the autotools chain for creating > > the distribution tarball and for building my own packages. So the > > cmake toolchain hasn't been tested by me, I haven't had the time, > > please test, we really ought to be switching completely to cmake. > > > > I get errors in creating dependences for package. > > #make package > ... > > dpkg-shlibdeps: error: couldn't find library libpano13.so.3 needed by > ./usr/local/bin/PTtiffdump (ELF format: 'elf64-x86-64'; RPATH: ''). > > dpkg-shlibdeps: warning: binaries to analyze should already be installed in > ... > > Searching for libpano13.so* yields to > #find . -name libpano13.so\* > ./libpano13.so.3.0.0 > ./libpano13.so > > so its created, but not yet installed. > > Once installed, everything works. > > We probably have to set CMAKE_INSTALL_RPATH, investigating now. > OK, I borrowed some code from hugin project. This patch works for me. Will commit, if nobody objects. Kornel |
From: Kornel B. <Kor...@be...> - 2013-12-17 20:06:23
|
Am Dienstag, 17. Dezember 2013 um 19:18:07, schrieb Bruno Postle <br...@po...> > On Tue 17-Dec-2013 at 19:05 +0000, Bruno Postle wrote: > >libpano13 is the PanoTools library for panoramic imaging. > > > >A libpano13-2.9.19 beta1 tarball has been uploaded to sourceforge, this is > >for testing but is expected to be very similar to the final release: > > > >https://sourceforge.net/projects/panotools/files/libpano13/libpano13-2.9.19/ > > I should add that I'm still using the autotools chain for creating > the distribution tarball and for building my own packages. So the > cmake toolchain hasn't been tested by me, I haven't had the time, > please test, we really ought to be switching completely to cmake. > I get errors in creating dependences for package. #make package ... dpkg-shlibdeps: error: couldn't find library libpano13.so.3 needed by ./usr/local/bin/PTtiffdump (ELF format: 'elf64-x86-64'; RPATH: ''). dpkg-shlibdeps: warning: binaries to analyze should already be installed in ... Searching for libpano13.so* yields to #find . -name libpano13.so\* ./libpano13.so.3.0.0 ./libpano13.so so its created, but not yet installed. Once installed, everything works. We probably have to set CMAKE_INSTALL_RPATH, investigating now. Kornel |
From: Bruno P. <br...@po...> - 2013-12-17 19:20:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 libpano13 is the PanoTools library for panoramic imaging. A libpano13-2.9.19 beta1 tarball has been uploaded to sourceforge, this is for testing but is expected to be very similar to the final release: https://sourceforge.net/projects/panotools/files/libpano13/libpano13-2.9.19/ Note that the soname has been incremented from 2.0.0 to 3.0.0 because this release is not binary compatible with previous versions - This means that Hugin will need to be rebuilt in order to use this libpano13. This release should work with the current Hugin 2013.0.0 stable release, however 2.9.19 is now a required dependency of Hugin development snapshots (and therefore the next Hugin release). There have been lots of cleanups, fixes of compiler warnings, bugfixes, and general refactoring since 2.9.18, plus we have some new features: * There are new Tpy and Tpr parameters, these allow the 'mosaic mode' projection plane to be rotated relative to the panorama view. * Added Hammer output projection, see: https://en.wikipedia.org/wiki/Hammer_projection * Updated PSD functions to write PSB (large file) format too, note that this functionality is part of the PTmender tool and not available to Hugin/nona directly. * Various bugs have been fixed in these projections: triplane output, architectural output, orthographic output and Thoby input. * Other bugfixes that may be noticed are: a check for invalid resolutions in TIFF files, formating sequence for x86_64, cropping images that go outside the image boundary, and PSD and PICT image format improvements. * There have been fixes for building on various platforms: OS X 10.6/10.8, automake 1.12, MinGW, and Visual Studio 2010 This release of libpano13 was brought to you by: Daniel M. German, Jim Watters, Kornel Benko, Matthieu Desile, Bruno Postle, dcb, Stefan Peter, Terry Duell, Timothee Groleau and Thomas Modes. It's an anniversary too! It is ten years since this library was put into Sourceforge CVS combining all known patch sets. Since this is also when PToptimizer.c was reconstructed, it marks exactly ten years of 100% Free Software panorama stitching! SHA1SUM: 695d6b26112ee18f3783b826e8c1c645f1b4ad2b libpano13-2.9.19_beta1.tar.gz This beta1 release is equivalent to HG 799:0dd1fabfc868 Here is the full ChangeLog since 2.9.18 for more details: 2013-12-16 22:35 +0000 Bruno Postle <br...@po...> (777f5eb48962 [tip]) * COPYING, ColourBrightness.c, ColourBrightness.h, PTDialogs.c, PTcommon.c, PTcommon.h, Triangulate.c, ZComb.c, ZComb.h, adjust.c, adjust.h, correct.c, dump.c, file.c, file.h, filter.c, filter.h, filter.r, fourier.c, javastub.c, math.c, metadata.c, metadata.h, multilayer.c, pan.c, panorama.h, parser.c, perspect.c, ppm.c, ptfeather.c, ptfeather.h, ptstitch.c, ptstitch.h, pttiff.h, remap.c, resample.c, sys_X11.c, sys_X11.h, sys_ansi.c, sys_ansi.h, sys_common.c, sys_compat.h, sys_compat_unix.c, sys_compat_win.c, sys_mac.c, sys_mac.h, sys_win.c, sys_win.h, tiff.c, tools/PTAInterpolate.c, tools/PTblender.c, tools/PTcrop.c, tools/PTinfo.c, tools/PTmasker.c, tools/PTmender.c, tools/PTmender.h, tools/PToptimizer.c, tools/PTroller.c, tools/PTtiff2psd.c, tools/PTtiffdump.c, tools/PTuncrop.c, tools/panoinfo.c, tools/panoinfo_unix.c, version.h: Fixed the FSF address to make an rpmlint error go away... 2013-12-16 21:03 +0000 Bruno Postle <br...@po...> (3c558c23fbc0) * CMakeLists.txt, Makefile.am: Increment the soname from 2.0.0 to 3.0.0 due to ABI change 2013-12-08 11:18 +0100 tmodes <tmodes> (5f73aa3334ae) * file.c, fourier.c: Fixes sign of some pointers 2013-12-08 11:17 +0100 tmodes <tmodes> (92a290290d3a) * parser.c: Add missing variables to format string 2013-12-08 11:17 +0100 tmodes <tmodes> (cba530fd3127) * pt_stdint.h: Fixes /* in comment 2013-12-08 11:16 +0100 tmodes <tmodes> (8fdc2b13c2c7) * correct.c: Don't include \0 in format string 2013-12-08 11:16 +0100 tmodes <tmodes> (839d2ea0602c) * ColourBrightness.c, PTcommon.c, file.c, math.c, parser.c, png.c, ptfeather.c, resample.c, rgbe.c, seamer_.c, tiff.c: Removed unused variables 2013-12-08 11:14 +0100 tmodes <tmodes> (84521eb90c05) * tools/compat_win32/getopt.c: [Mingw] Fix a compiler warning by implizit include of necessary header 2013-12-08 10:11 +0100 tmodes <tmodes> (30f4cb70d93c) * tiff.c: Correct check for invalid resolutions in TIF files (spotted by dcb [1256972]) 2013-10-12 09:08 +0200 thomas <thomas@Virtual> (36d7541b8384) * PTcommon.c, parser.c, ppm.c, resample.c: Fixes formating sequence for x86_64 [1184375] Patch by Stefan Peter 2013-10-12 09:07 +0200 thomas <thomas@Virtual> (0a44cbd60ac8) * tests/simpleTiff2psd/reference/simpleStitch_crop_1_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_crop_2_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_uncrop_1_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_uncrop_2_layer.psd, tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_1_layer.psd, tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_2_layer.psd: Update psd references for 2.9.19 2013-10-12 09:06 +0200 thomas <thomas@Virtual> (879f75a8eae7) * tests/CMakeLists.txt, tests/simpleTiff2psd/CMakeLists.txt: [CMake]: Copy necessary files for test 2013-05-14 19:44 +0100 Bruno Postle <br...@po...> (ce361a3cfb97) * sys_compat_unix.c: Fix to build on OS X 10.6/10.8 (Matthieu Desile) 2013-05-13 20:37 +0100 Bruno Postle <br...@po...> (d3703d445473) * README, README.linux, README.windows: Fix some really out-of-date README text 2013-04-12 18:56 +0200 tmodes <tmodes> (04c52cae988a) * math.c: Fixes wrong calculation in triplane_erect 2013-03-21 10:42 +1100 tduell <td...@ii...> (8ccb62eb329a) * Makefile.am: fix for removed .def files 2013-03-17 18:55 +0100 tmodes <tmodes> (3b87e44598ea) * libpano13.def, pano13vc.def: deleted file. * CMakeLists.txt, ColourBrightness.h, PTcommon.h, ZComb.h, file.h, filter.h, libpano13.def, pano13vc.def, panorama.h, ptfeather.h, ptstitch.h, pttiff.h, queryfeature.h, tools/PToptimizer.c: [Windows] Use __declspec(dllexport) instead of modul definition file Functions exported via modul definition file can't be compared with function points (needed by nona gpu). Function pointers works for functions exported with __declspec(dllexport). 2013-03-17 08:08 +0100 tmodes <tmodes> (4b93725a1f29) * PTcommon.c, adjust.c, correct.c, dump.c, filter.h, math.c, panorama.h, parser.c: Moved test parameter 0 and 1 to Tpy and Tpr 2013-03-17 08:06 +0100 tmodes <tmodes> (253c1bcde35e) * configure.ac, version.h: Bump version number 2013-03-17 08:06 +0100 tmodes <tmodes> (c2a40aad1b51) * bootstrap: Update bootstrap for automake 1.12 (Patch by Terry Duell) [11561269] 2013-03-16 08:38 +0100 tmodes <tmodes> (b1e1204fe014) * math.c: Fixes for architectural projection * correctly report success of transformation * check if values are in valid ranges 2013-03-16 08:19 +0100 tmodes <tmodes> (8bf958d04557) * math.c: Removed unused variables 2013-03-16 07:45 +0100 tmodes <tmodes> (531cd379005d) * adjust.c, filter.h, math.c, panorama.h, parser.c, queryfeature.c: Added Hammer projection 2013-03-03 08:32 +0100 tmodes <tmodes> (6e390e07eac5) * math.c: Prevent division by zero [791473] 2013-03-03 08:31 +0100 tmodes <tmodes> (1b78f71b2c32) * CMakeLists.txt: Fixes a typo in version string 2013-03-03 08:30 +0100 tmodes <tmodes> (c251644f9866) * CMakeLists.txt, ColourBrightness.c, sys_compat_win.c: Fixes compilation with MinGW compiler 2013-03-02 13:18 +0100 tmodes <tmodes> (489ef38b776c) * CMakeLists.txt: Use mercurial instead of subversion in CMake build 2013-03-02 13:14 +0100 tmodes <tmodes> (e4a5489e244d) * filter.h, panorama.h, parser.c: Fixes some typos 2013-01-31 18:14 +0100 tmodes <tmodes> (1299ba47658f) * panorama.h, tiff.c: Unified use of path length Check also length before copying [1057012] 2013-01-12 10:21 +0100 tmodes <tmodes> (b2f10b688fd6) * adjust.c: Modified scale calculation for orthographic images This takes into account the issue that the image could also contain a thin black border around the (circular) image. 2012-12-28 13:39 +0100 tmodes <tmodes> (376cc090f008) * math.c: Fixes bug in orthographic projection Orthographic projection is limited to fov of 180 degree Higher values were not correctly cropped, instead these coordinates were mirrored inside 2012-11-19 22:37 -0400 Jim Watters <jwa...@ph...> (e63acb0227b7) * adjust.c: Fix a bug when cropping images that go outside the image boundry. mp->horizontal & mp->vertical would otherwise get extrordinary large. 2012-09-18 19:51 +0200 tmodes <tmodes> (c9f63bc558e9) * PTcommon.c, panorama.h: Use unsigned int for PTRect Otherwise crop is not correctly calculated 2012-09-18 19:10 +0200 tmodes <tmodes> (bb55bfdfa33e) * sys_compat_unix.c, sys_compat_win.c: new file. * CMakeLists.txt, Makefile.am, pano13vc.def, pt_stdint.h, sys_ansi.c, sys_compat.h, sys_compat_unix.c, sys_compat_win.c, sys_win.c, sys_win.h, tools/CMakeLists.txt: Update build system to compile on Windows again Added option to CMake build to allow building static or shared version on Windows 2012-09-17 22:55 +0100 Bruno Postle <br...@po...> (17b9409b0fcc) * adjust.c: Fix "unsupported Panorama Format" error Bug #1049994 (Thomas Modes) 2012-09-17 22:55 +0100 Bruno Postle <br...@po...> (a1660991bf10) * math.c: Fix Inverse transformation from output projection to Thoby input image is wrong Bug #891912 reported by Timothee Groleau (Thomas Modes) 2012-03-02 23:19 +0000 Bruno Postle <br...@po...> (0c73d8794377) * LocalDefs.props, libpano.vcxproj, sys_compat.h, tests/panoAutomatePSDtest.pl, tests/simpleTiff2psd/CMakeLists.txt, tests/simpleTiff2psd/reference/simpleStitch_crop_1_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_crop_2_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_uncrop_1_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_uncrop_2_layer.psd, tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_1_layer.psd, tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_2_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_crop_1_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_crop_2_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_uncrop_1_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_uncrop_2_layer.psd, tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_1_layer.psd, tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_2_layer.psd, tests/tiff2psdTest.bat, tools/PTAInterpolate.vcxproj, tools/PTOptimizer.vcxproj, tools/PTblender.vcxproj, tools/PTcrop.vcxproj, tools/PTinfo.vcxproj, tools/PTmasker.vcxproj, tools/PTmender.vcxproj, tools/PTroller.vcxproj, tools/PTtiff2psd.vcxproj, tools/PTtiffdump.vcxproj, tools/PTuncrop.vcxproj: new file. * .hgignore, CMakeLists.txt, ChangeLog, png.c, pteditor.c, tests/CMakeLists.txt: merged PSD branch 2012-01-11 10:27 +1100 Terry Duell <td...@ii...> (20a9b820aba0) * dump.c, pteditor.c, ptpicker.c: Fix outstanding pt_int32 problems 2011-05-31 09:54 +0200 Kornel Benko <kor...@us...> (bd103552abef) * CMakeLists.txt: 1.) Make it compilable on ubuntu 11.4 using '-DHUGIN_BASE_DIR=path to hugin sources' Define SYSTEM_LIB_DIRS for use of hugins CMakeModules Define 'HUGIN_SHARED', because of it's use 2.) Add dependences creation on debian systems 2011-03-21 21:36 +0000 Bruno Postle <br...@po...> (da48158224d6) * ChangeLog.hg: Update changelog 2011-03-16 19:16 +0000 Bruno Postle <br...@po...> (34d8f7279b7d) Update ChangeLog.hg for default branch 2011-03-04 01:15 -0800 dmg <dm...@uv...> (95e1c5da422e) * .hgignore, ChangeLog: Sorted files to .hgignore 2011-03-04 01:15 -0800 dmg <dm...@uv...> (2ae987ad64a2) * .hgignore, ChangeLog: Added files to .hgignore 2011-03-03 21:53 -0800 dmg <dm...@uv...> (8c929483d775 <PhotoshopPSB>) * ChangeLog, tools/PTtiff2psd.c: added jim to credits of PTtiff2psd 2011-03-03 20:43 -0800 dmg <dm...@uv...> (6d05236f8495 <PhotoshopPSB>) * ChangeLog: Added test cases for PTtiff2psd 2011-03-03 20:43 -0800 dmg <dm...@uv...> (dd2b0f7313d0 <PhotoshopPSB>) * tests/panoAutomatePSDtest.pl, tests/simpleTiff2psd/CMakeLists.txt, tests/simpleTiff2psd/reference/simpleStitch_crop_1_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_crop_2_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_uncrop_1_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_uncrop_2_layer.psd, tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_1_layer.psd, tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_2_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_crop_1_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_crop_2_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_uncrop_1_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_uncrop_2_layer.psd, tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_1_layer.psd, tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_2_layer.psd: new file. * tests/tiff2psdSimple/reference/crop.psb, tests/tiff2psdSimple/reference/crop.psd, tests/tiff2psdSimple/reference/uncrop.psb, tests/tiff2psdSimple/reference/uncrop.psd: deleted file. * .hgignore, ChangeLog, file.c, tests/CMakeLists.txt, tests/panoAutomatePSDtest.pl, tests/simpleTiff2psd/CMakeLists.txt, tests/simpleTiff2psd/reference/simpleStitch_crop_1_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_crop_2_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_uncrop_1_layer.psd, tests/simpleTiff2psd/reference/simpleStitch_uncrop_2_layer.psd, tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_1_layer.psd, tests/simpleTiff2psd/reference/simpleTiff16-16-_uncrop_2_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_crop_1_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_crop_2_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_uncrop_1_layer.psd, tests/simpleTiff2psd/tests/simpleStitch_uncrop_2_layer.psd, tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_1_layer.psd, tests/simpleTiff2psd/tests/simpleTiff16-16-_uncrop_2_layer.psd, tests/tiff2psdSimple/reference/crop.psb, tests/tiff2psdSimple/reference/crop.psd, tests/tiff2psdSimple/reference/uncrop.psb, tests/tiff2psdSimple/reference/uncrop.psd: Added test cases for PTtiff2psd 2011-03-03 16:36 -0800 dmg <dm...@uv...> (d61239410f3d <PhotoshopPSB>) * sys_compat.h: new file. * sys_compat.h: I forgot to add sys_compat.h 2011-03-03 16:30 -0800 dmg <dm...@uv...> (0ed11c91c143 <PhotoshopPSB>) * CMakeLists.txt, ChangeLog, file.c, sys_ansi.c, sys_win.c: Refactored system dependent code 2011-03-03 14:54 -0400 Jim Watters <Jim Watters> (a2fdc9b8616d <PhotoshopPSB>) * file.c: Fix timezone in PSDPICTResource %z and %Z in strftime produces a alpha string need a numeric string. Fix some sign unsign warnings 2011-03-03 01:30 -0800 dmg <dm...@uv...> (61011fb1ba7b) * CMakeLists.txt, ChangeLog, Makefile.am: cherry picked 721 from PhotoshopPSB to default 2011-03-03 01:24 -0800 dmg <dm...@uv...> (e881eb9a4ba0 <PhotoshopPSB>) * CMakeLists.txt, ChangeLog, Makefile.am: Added TAGS file creation, undid removal of hugin-related paths. 2011-03-03 00:44 -0800 dmg <dm...@uv...> (5ce79b438819 <PhotoshopPSB>) * file.c: Ported code to write name of writing program 2011-03-03 00:21 -0800 dmg <dm...@uv...> (d284d6621bff <PhotoshopPSB>) * tests/tiff2psdSimple/reference/crop.psb, tests/tiff2psdSimple/reference/crop.psd, tests/tiff2psdSimple/reference/uncrop.psb, tests/tiff2psdSimple/reference/uncrop.psd: new file. * tests/tiff2psdSimple/crop.psb, tests/tiff2psdSimple/crop.psd, tests/tiff2psdSimple/uncrop.psb, tests/tiff2psdSimple/uncrop.psd: deleted file. * tests/tiff2psdSimple/crop.psb, tests/tiff2psdSimple/crop.psd, tests/tiff2psdSimple/reference/crop.psb, tests/tiff2psdSimple/reference/crop.psd, tests/tiff2psdSimple/reference/uncrop.psb, tests/tiff2psdSimple/reference/uncrop.psd, tests/tiff2psdSimple/uncrop.psb, tests/tiff2psdSimple/uncrop.psd: moved test files for PSD 2011-03-03 00:15 -0800 dmg <dm...@uv...> (8fbc76a7f4b9 <PhotoshopPSB>) * .hgignore, ChangeLog, PTcommon.c, PTcommon.h, ZComb.c, adjust.c, correct.c, file.c, filter.c, filter.h, png.c, resample.c, tiff.c: removed unnecessary and duplicated data types 2011-03-02 23:12 -0800 dmg <dm...@uv...> (0a87dbc64f24) * .hgignore: Added more files to ignore to .hgignore 2011-03-02 23:11 -0800 dmg <dm...@uv...> (02384dd66427) * .hgignore: Added more files to ignore to .hgignore 2011-03-02 23:05 -0800 dmg <dm...@uv...> (70b2afd42405) * .hgignore: Added some files to ignore to .hgignore 2011-03-02 22:59 -0800 dmg <dm...@uv...> (7d932f0d1221) * panorama.h: width and height should always be unsigned 2011-03-02 22:49 -0800 dmg <dm...@uv...> (0a526edf75cc) * ChangeLog, PTcommon.c, adjust.c, file.c, filter.c, filter.h, fourier.c, morpher.c, panorama.h, panotypes.h, parser.c, perspect.c, resample.c, rgbe.c, rgbe.h, tests/CMakeLists.txt, tiff.c: Removed the use of pt_int* data types, which are redundant and not consistently used 2011-03-02 22:03 -0800 dmg <dm...@uv...> (4000b5187221) * CMakeLists.txt, ChangeLog, PTcommon.c, filter.h, panorama.h, panotypes.h, pt_stdint.h, rgbe.c, rgbe.h, sys_ansi.c, sys_common.c: Fixed compiler warnings and cleanup some conditional compilation code 2011-03-02 18:59 -0400 Jim Watters <Jim Watters> (daf735d8ec66 <PhotoshopPSB>) * file.c: correct some Linux errors and warnings. 2011-03-02 15:22 -0400 Jim Watters <Jim Watters> (7dea16af1053 <PhotoshopPSB>) * file.c: Clean up, untabulate, and beautify code 2011-03-02 00:17 -0400 Jim Watters <Jim Watters> (755c1fbd4838 <PhotoshopPSB>) * PTcommon.h, file.c, tools/PTtiff2psd.c: Add panoCreateLayeredPSD Create a PSD file from a bunch of tiffs in one go without inserting each layer one at a time. 2011-02-25 22:38 -0400 Jim Watters <Jim Watters> (19c2bd9d5040 <PhotoshopPSB>) * file.c: Simplify the calculation of layer length 2011-02-25 21:56 -0400 Jim Watters <Jim Watters> (15df50fc3f7a <PhotoshopPSB>) * PTcommon.c: O(n2) 2011-02-24 16:34 -0400 Jim Watters <Jim Watters> (28033bba0b8f <PhotoshopPSB>) * PTcommon.c: By default PANO_TEST_INVERSE should be commented out 2011-02-24 16:25 -0400 Jim Watters <Jim Watters> (6545685cd438 <PhotoshopPSB>) * PTcommon.c: untablify and beautify code 2011-02-24 14:41 -0400 Jim Watters <Jim Watters> (1c9ce5934fb1 <PhotoshopPSB>) * tests/tiff2psdTest.bat: new file. * tests/tiff2psdSimple/crop.psb, tests/tiff2psdSimple/crop.psd, tests/tiff2psdSimple/uncrop.psb, tests/tiff2psdSimple/uncrop.psd, tests/tiff2psdTest.bat: Update test images with new PICT record for PTtiff2PSD 2011-02-23 22:45 -0400 Jim Watters <Jim Watters> (1a989de7c490 <PhotoshopPSB>) * file.c: Merge 2011-02-23 17:56 -0400 Jim Watters <Jim Watters> (00a141ab7ffb <PhotoshopPSB>) * file.c: Update PICT Resource Added more info to the PICT resource 2011-02-23 14:25 -0400 Jim Watters <Jim Watters> (3d46baa67f1e <PhotoshopPSB>) * file.c: Fix PICT Resource PICT now displays correctly with Photoshop and Exiftool 2011-02-19 23:41 -0400 Jim Watters <Jim Watters> (5d9db2abdb38 <PhotoshopPSB>) * file.c, filter.c, filter.h: Update panoWritexxx functions to return bool use change in location of write to get length of section. 2011-02-19 23:53 -0800 dmg <dm...@uv...> (61f66c836feb <PhotoshopPSB>) * ChangeLog, file.c: Fixed a small error that stopped compilation under Linux. 2011-02-19 16:05 -0400 Jim Watters <Jim Watters> (b1595e6c58fc <PhotoshopPSB>) * tests/tiff2psdSimple/crop.psb, tests/tiff2psdSimple/uncrop.psb: new file. * tests/tiff2psdSimple/crop.psb, tests/tiff2psdSimple/uncrop.psb: Add reference PSB files for testing PTtiff2PSD 2011-02-19 15:54 -0400 Jim Watters <Jim Watters> (bf73d5f0e9fa <PhotoshopPSB>) * tests/tiff2psdSimple/crop.psd, tests/tiff2psdSimple/uncrop.psd: new file. * tests/tiff2psdSimple/crop.psd, tests/tiff2psdSimple/uncrop.psd: Add reference PSD files for testing PTtiff2PSD 2011-02-19 15:40 -0400 Jim Watters <Jim Watters> (080786b030d4 <PhotoshopPSB>) * file.c: opps panoReadxxxx returns bool not length 2011-02-17 18:31 -0400 Jim Watters <Jim Watters> (6742691b9336 <PhotoshopPSB>) * file.c, filter.c, filter.h: switch from READ and WRITE macros to functions. switch from READ and WRITE macros to functions. Simplified code by adding functions panoReadINT32or64 and panoWriteINT32or64 for read and write 4 or 8 byte varibles for the use of PSD or PSB. 2011-02-14 23:22 -0400 Jim Watters <Jim Watters> (cb926d40214e <PhotoshopPSB>) * filter.c, filter.h: Add functions panoWriteINT32or64 and panoReadINT32or64 2011-02-14 23:04 -0400 Jim Watters <Jim Watters> (9e9d800230f9 <PhotoshopPSB>) * .hgignore: Add .ipch to ignor list 2011-02-14 23:02 -0400 Jim Watters <Jim Watters> (a7bcbe2d5c2d <PhotoshopPSB>) * filter.c, filter.h: update panowrite functions to return count 2011-02-14 22:06 -0400 Jim Watters <Jim Watters> (46f909a2a815 <PhotoshopPSB>) * file.c: remove cast 2011-02-14 21:06 -0400 Jim Watters <Jim Watters> (704614dd55ae <PhotoshopPSB>) * PTcommon.c, file.c, filter.c, filter.h, pano13vc.def, tools/PTtiff2psd.c: New versions of files that now should end with LF only 2011-02-14 20:43 -0400 Jim Watters <Jim Watters> (9c9ced6c091f <PhotoshopPSB>) * .hgeol: new file. * .hgeol: Windows users should use the EOL extension Windows users need EOL to control how End of Line characters are translated to and from repository. 2011-02-14 20:43 -0400 Jim Watters <Jim Watters> (2a01f904d1c3 <PhotoshopPSB>) * .hgignore: new file. * .hgignore: Add a list of files to ignor when doing commit 2011-02-13 01:32 -0400 Jim Watters <Jim Watters> (9b9b3887cddf <PhotoshopPSB>) * file.c: Use 8byte sizes all the time. 2011-02-13 01:31 -0400 Jim Watters <Jim Watters> (879cca2dae52 <PhotoshopPSB>) * tools/PTAInterpolate.vcxproj, tools/PTOptimizer.vcxproj, tools/PTblender.vcxproj, tools/PTcrop.vcxproj, tools/PTinfo.vcxproj, tools/PTmasker.vcxproj, tools/PTmender.vcxproj, tools/PTroller.vcxproj, tools/PTtiff2psd.vcxproj, tools/PTtiffdump.vcxproj, tools/PTuncrop.vcxproj: Update Location of 64bit libs 2011-02-12 21:41 -0400 Jim Watters <Jim Watters> (127413a4755c <PhotoshopPSB>) * tools/PTAInterpolate.vcxproj, tools/PTOptimizer.vcxproj, tools/PTblender.vcxproj, tools/PTcrop.vcxproj, tools/PTinfo.vcxproj, tools/PTmasker.vcxproj, tools/PTmender.vcxproj, tools/PTroller.vcxproj, tools/PTtiff2psd.vcxproj, tools/PTtiffdump.vcxproj, tools/PTuncrop.vcxproj: Add Local definitions LocalDefs to 64bit projects 2011-02-12 21:23 -0400 Jim Watters <Jim Watters> (d9bf0412f5f1 <PhotoshopPSB>) * PTcommon.c, file.c, file.h, filter.h, tiff.c: update PSD functins to write PSB format too 2011-02-12 21:22 -0400 Jim Watters <Jim Watters> (b22ddb573e0b <PhotoshopPSB>) * tools/PTAInterpolate.vcxproj, tools/PTOptimizer.vcxproj, tools/PTblender.vcxproj, tools/PTcrop.vcxproj, tools/PTinfo.vcxproj, tools/PTmasker.vcxproj, tools/PTmender.vcxproj, tools/PTroller.vcxproj, tools/PTtiff2psd.c, tools/PTtiff2psd.vcxproj, tools/PTtiffdump.vcxproj, tools/PTuncrop.vcxproj: Make projects multicore friendly by using differnt folders for temp files that may conflict. 2011-02-10 16:49 -0400 Jim Watters <Jim Watters> (52cf096d848b <PhotoshopPSB>) * LocalDefs.props: new file. * LocalDefs.props: Update to VS 2010 2011-02-10 16:49 -0400 Jim Watters <Jim Watters> (c2996d3c00aa <PhotoshopPSB>) * libpano.vcxproj, tools/PTAInterpolate.vcxproj, tools/PTOptimizer.vcxproj, tools/PTblender.vcxproj, tools/PTcrop.vcxproj, tools/PTinfo.vcxproj, tools/PTmasker.vcxproj, tools/PTmender.vcxproj, tools/PTroller.vcxproj, tools/PTtiff2psd.vcxproj, tools/PTtiffdump.vcxproj, tools/PTuncrop.vcxproj: new file. * libpano.sln, libpano.vcxproj, tools/PTAInterpolate.vcxproj, tools/PTOptimizer.vcxproj, tools/PTblender.vcxproj, tools/PTcrop.vcxproj, tools/PTinfo.vcxproj, tools/PTmasker.vcxproj, tools/PTmender.vcxproj, tools/PTroller.vcxproj, tools/PTtiff2psd.vcxproj, tools/PTtiffdump.vcxproj, tools/PTuncrop.vcxproj: Update to VS 2010 2011-02-10 16:46 -0400 Jim Watters <Jim Watters> (611e65b1791f <PhotoshopPSB>) * PTcommon.c, file.c, file.h, filter.c, filter.h, pano13vc.def, tools/PTtiff2psd.c: First sweep of the Photoshop PSD code at add PSB. Enable PSD functions to be also capable of PSB read and write. Builds with a couple resize warnings that need to be corrected. Completely untested. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFSsKCSFqOhwCjyCLoRAkyXAKDJ5ib6eIeGu+ekqBhhzhuWcYlZVgCbBKot OsypZFONNQageycotXWLLKg= =2S41 -----END PGP SIGNATURE----- |
From: Bruno P. <br...@po...> - 2013-12-17 19:18:27
|
On Tue 17-Dec-2013 at 19:05 +0000, Bruno Postle wrote: >libpano13 is the PanoTools library for panoramic imaging. > >A libpano13-2.9.19 beta1 tarball has been uploaded to sourceforge, this is >for testing but is expected to be very similar to the final release: > >https://sourceforge.net/projects/panotools/files/libpano13/libpano13-2.9.19/ I should add that I'm still using the autotools chain for creating the distribution tarball and for building my own packages. So the cmake toolchain hasn't been tested by me, I haven't had the time, please test, we really ought to be switching completely to cmake. -- Bruno |
From: Kornel B. <Kor...@be...> - 2013-11-01 09:30:35
|
Am Freitag, 1. November 2013 um 00:26:33, schrieb Bruno Postle <br...@po...> > On Thu 31-Oct-2013 at 16:48 +0100, Kornel Benko wrote: > >Bruno Postle added this the script 'ptomorh' which > >I would like to see working parallel. > >I have a version which may well work on unix, but I don't know if also on windows. > > > >For now, the number of available cores is hardcoded to 8 (see ptomorph:12), it should come as a > >parameter (like e.g. '-j 8' or '-j=8') > > It looks good to me. Though ptomorph probably already doesn't work > on Windows because it uses IPC::Open2 which is very platform specific. OK, that makes the decision easier. If nobody objects, I'd like to commit the attached. > Ultimately it would be nice to implement something like ptomorph > somewhere in the libpano13 stack, though I'm not quite sure where. Yes, that would be nice. I can't help much though. Kornel |
From: Bruno P. <br...@po...> - 2013-11-01 00:50:31
|
On Thu 31-Oct-2013 at 16:48 +0100, Kornel Benko wrote: >Bruno Postle added this the script 'ptomorh' which >I would like to see working parallel. >I have a version which may well work on unix, but I don't know if also on windows. > >For now, the number of available cores is hardcoded to 8 (see ptomorph:12), it should come as a >parameter (like e.g. '-j 8' or '-j=8') It looks good to me. Though ptomorph probably already doesn't work on Windows because it uses IPC::Open2 which is very platform specific. Ultimately it would be nice to implement something like ptomorph somewhere in the libpano13 stack, though I'm not quite sure where. -- Bruno |
From: Kornel B. <Kor...@be...> - 2013-10-31 16:06:38
|
Hi list, Bruno Postle added this the script 'ptomorh' which I would like to see working parallel. I have a version which may well work on unix, but I don't know if also on windows. For now, the number of available cores is hardcoded to 8 (see ptomorph:12), it should come as a parameter (like e.g. '-j 8' or '-j=8') Nonetheless, here a version for try. Kornel |
From: Bruno P. <br...@po...> - 2013-05-14 18:59:59
|
On Mon 13-May-2013 at 16:45 -0700, ___matthieu___ wrote: > >In the process of having a build of Hugin on MacOSX 10.8 that is compatible >with MacOSX 10.6, I found that libpano13 was using a symbol (___progname) >that was not present on OSX 10.6. > >I only found it in sys_compat_unix.c; I replaced the call from ___progname >to getprogname() (which is defined in stdlib.h). >This enables the library to be used on 10.6 and 10.8 without problem. > >Though, I do not know if my change produces the same output, it used (from >what I found) only in file.c:panoPSDResourcesBlockWrite() and I do not know >how to test it. Think this should only get called by PTtiff2psd, you could test it by trying to join some TIFF files (created by Hugin) into a multilayer PSD file: PTtiff2psd pano_0001.tif pano_0002.tif pano_0003.tif >Is there any way to test it ? Is this change acceptable and/or can it lead >to problems ? It seems harmless so I committed it, thanks for contributing. -- Bruno |
From: ___matthieu___ <mat...@gm...> - 2013-05-13 23:45:21
|
Hi Bruno, In the process of having a build of Hugin on MacOSX 10.8 that is compatible with MacOSX 10.6, I found that libpano13 was using a symbol (___progname) that was not present on OSX 10.6. I only found it in sys_compat_unix.c; I replaced the call from ___progname to getprogname() (which is defined in stdlib.h). This enables the library to be used on 10.6 and 10.8 without problem. Though, I do not know if my change produces the same output, it used (from what I found) only in file.c:panoPSDResourcesBlockWrite() and I do not know how to test it. Is there any way to test it ? Is this change acceptable and/or can it lead to problems ? I attach the diff to this post. Matthieu On Monday, May 13, 2013 11:01:37 PM UTC+2, Bruno Postle wrote: > > Hi all, Sourceforge have 'upgraded' the panotools project on > sourceforge: http://sourceforge.net/projects/panotools/ > > Mercurial repositories have moved, you can now find the libpano13 > code here: > > hg clone http://hg.code.sf.net/p/panotools/libpano13 > > So if you have an existing checkout you can either rebase it by > editing the .hg/hgrc file, or just fetch a fresh one. The old > Mercurial repository will continue to exist, but is now read-only. > > I took the opportunity to migrate the other panotools projects from > Subversion to Mercurial (hooray!), these are: > > Panotools::Script - perl module for manipulating Hugin .pto projects > > GIMP plugin - A GIMP panotools plugin, this needs to maintenance > > ptfilter - Photoshop filters for panotools > > MPRemap - Java moving panoramas remapping > > If there is anything I'm missing, please let me know. e.g. I > haven't migrated the old libpano12 binary-compatible library - Does > anyone want this? > > -- > Bruno > |
From: Bruno P. <br...@po...> - 2013-05-13 21:16:59
|
Hi all, Sourceforge have 'upgraded' the panotools project on sourceforge: http://sourceforge.net/projects/panotools/ Mercurial repositories have moved, you can now find the libpano13 code here: hg clone http://hg.code.sf.net/p/panotools/libpano13 So if you have an existing checkout you can either rebase it by editing the .hg/hgrc file, or just fetch a fresh one. The old Mercurial repository will continue to exist, but is now read-only. I took the opportunity to migrate the other panotools projects from Subversion to Mercurial (hooray!), these are: Panotools::Script - perl module for manipulating Hugin .pto projects GIMP plugin - A GIMP panotools plugin, this needs to maintenance ptfilter - Photoshop filters for panotools MPRemap - Java moving panoramas remapping If there is anything I'm missing, please let me know. e.g. I haven't migrated the old libpano12 binary-compatible library - Does anyone want this? -- Bruno |
From: Thomas S. <tks...@gm...> - 2013-04-15 20:46:52
|
Hi All I'm getting very serious about camera arrays and 3D stitching -- that is, combining images taken from multiple positions, with general parallax correction. And I'm trying to make a version of libpano13 to support some experiments. Given a reasonable array geometry and plenty of overlap between the cameras' fovs, it is perfectly feasible in theory to construct panoramic views on any single center, and to choose that center pretty freely. Of course the 900 pound gorilla is that in order to correct parallax you need a depth map of the scene. But assuming that is possible, there are several other matters that need attention. First, defining the positions and orientations of the cameras. With TrX, TrY, TrZ, PT has the means to specify the positions, and with y, p, r the orientations. The origin of these coordinates would no longer be the pano center -- we haven't chosen one yet -- so let's call it the array center. To fix the array coordinate system it is enough to designate one camera as having all these parameters zero, (except possibly TrZ) . Then array X, Y, Z are parallel to the reference camera's axes. Given the array geometry we can easily compute camera directions and distances with respect to any panocenter, and any rotation of the array as a whole. The relevant quantities for parallax correction are the direction of the optic axis and the direction and distance of the lens pupil. With those facts and a depth map we can compute parallax-corrected image coordinates from 'ideal' pano coordinates, and thus do a parallax corrected stitch. It has to be possible to determine these 6 parameters by optimization, because nobody can build a perfectly rigid array, and because we will surely want to support hand held "pseudo arrays". I'm assuming this can be done using control points found in the usual way, by assigning a depth to each control point and optimizing those along with y,p,r,TrX,TrY,TrZ. This optimization could use any hypothetical pano center, for instance the array center. It would be pointless to try to optimize lens parameters at the same time, as lens distortion is basically indistinguishable from parallax. So all this assumes excellent prior camera calibration. That's as far as I want to go now. Your thoughts, please, on how to insert a true 3D camera / control point model into libpano13's optimization scheme. -- Tom |
From: Carl v. E. <ei...@gm...> - 2013-04-08 07:41:37
|
You're on the developer list ("a list for developers of panotools and the pano12 library in particular"), I guess you will get more attention on one of these mailing lists mentioned on http://wiki.panotools.org/Discussion_lists - PanoTools NG the main discussion list for users for panorama tools and related GUI tools - hugin-ptx, discussion of Linux and Unix related panorama software and hugin in particular Another hint for you to get some helping response: Please don't simply press "Reply" in an unrelated message if you want to start a new thread (i.e. you want to get talk about a completely different topic than the original one). Also don't start an entirely NEW thread by just changing the subject line. In mailing lists this is extremely annoying for other list members. Here is some more information about this: http://wiki.panotools.org/User_Guidelines#Subject So: - try a different mailing list (one of the two mentioned above) - start a new thread (don't just reply to some other message) - choose a meaningful subject And last but not least: have a look at this list of tutorials, maybe this answers some of your questions: http://wiki.panotools.org/Tutorials Carl Alon Carmeli schrieb am 07.04.13 21:41: > hi all, > > i'm need to do multi-row panorama - 3 rows each with about 200 degrees each. is having more overlap between images on same row and between rows produces smother or worst panorama? > > Thx, > > -AC > > On Apr 7, 2013, at 2:56 AM, kfj wrote: > (...something completely different!) |
From: Alon C. <al...@gm...> - 2013-04-07 19:41:58
|
hi all, i'm need to do multi-row panorama - 3 rows each with about 200 degrees each. is having more overlap between images on same row and between rows produces smother or worst panorama? Thx, -AC On Apr 7, 2013, at 2:56 AM, "Kay F. Jahnke" <_k...@ya...> wrote: > Hi group! > > I'm currently wrapping the PT transforms (yet again...), and I've > stumbled upon strange behaviour: when I call erect_triplane on a set of > coordinates, and afterwards call triplane_erect on the transformed > values, the round-trip doesn't land at the initial values. (with the > other transforms I've tried, this is the case after applying the > transform and then the reverse transform - e.g. with biplane, which > seems very similar). > > Ignorant of the meaning of the actual parameters, I've made > reasonable-looking ones up: I feed mp->pn->formatParamCount as 0 (to get > the default of formatParam[0] = 45), width as 100.0, and b as 1.0 into > triplane_distance, and then use the MakeParams struct in the actual > transform, going over a set of a few coordinate pairs in the range of > +/- 1.0. The values after performing erect_triplane look 'reasonable', > but triplane_erect seems to go off somehow, producing quite large values > on the x coordinates. > > While this may be a false alert, maybe one of the panotools developers > could take a look and/or write a quick round-trip in C (or use a pano > tool to the same effect)? I'm using a very recent checkout of libpano > (11:00 today), so I doubt anything has changed since that. > > And, while I'm at it, is there any documentation on the parameters of > the various transforms? Some of them take quite elaborate collections of > values with rather unenlightening names (like, radial() takes double > coefficients[4], scale, correction_radius... and that's all the docu I > can find) > > With regards > Kay > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel |
From: Kay F. J. <_k...@ya...> - 2013-04-07 09:56:29
|
Hi group! I'm currently wrapping the PT transforms (yet again...), and I've stumbled upon strange behaviour: when I call erect_triplane on a set of coordinates, and afterwards call triplane_erect on the transformed values, the round-trip doesn't land at the initial values. (with the other transforms I've tried, this is the case after applying the transform and then the reverse transform - e.g. with biplane, which seems very similar). Ignorant of the meaning of the actual parameters, I've made reasonable-looking ones up: I feed mp->pn->formatParamCount as 0 (to get the default of formatParam[0] = 45), width as 100.0, and b as 1.0 into triplane_distance, and then use the MakeParams struct in the actual transform, going over a set of a few coordinate pairs in the range of +/- 1.0. The values after performing erect_triplane look 'reasonable', but triplane_erect seems to go off somehow, producing quite large values on the x coordinates. While this may be a false alert, maybe one of the panotools developers could take a look and/or write a quick round-trip in C (or use a pano tool to the same effect)? I'm using a very recent checkout of libpano (11:00 today), so I doubt anything has changed since that. And, while I'm at it, is there any documentation on the parameters of the various transforms? Some of them take quite elaborate collections of values with rather unenlightening names (like, radial() takes double coefficients[4], scale, correction_radius... and that's all the docu I can find) With regards Kay |
From: walter h. <wh...@bf...> - 2013-01-20 13:57:19
|
The best way is to get rid of the array and use getline(). The simple fix is to use snprintf( im->name,PANO_PATH_LEN,"%s",buf); Using LINE_LENGTH instead of PANO_PATH_LEN is a bit overheat just my 2 cents, re, wh Am 20.01.2013 12:17, schrieb Andreas Metzler: > Hello, > > this was reported on Ubuntu in > <https://bugs.launchpad.net/ubuntu/+source/libpano13/+bug/1057012>, I > am just forwarding, bug reported and diagnosed by Stephane Gourichon: > > Running cpfind in a directory with a long path ( > 256 characters for > filename with full path) results in a bugffer overflow: > > -------------- > [...] > --- Find pair-wise matches --- > *** buffer overflow detected ***: cpfind terminated > ======= Backtrace: ========= > /lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xf6b443c0] > /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe92fa)[0xf6b432fa] > /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe8a38)[0xf6b42a38] > /lib/i386-linux-gnu/i686/cmov/libc.so.6(_IO_default_xsputn+0x9e)[0xf6ac947e] > /lib/i386-linux-gnu/i686/cmov/libc.so.6(_IO_vfprintf+0x478a)[0xf6a9e1ea] > /lib/i386-linux-gnu/i686/cmov/libc.so.6(__vsprintf_chk+0xa7)[0xf6b42ae7] > /lib/i386-linux-gnu/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xf6b42a2d] > /usr/lib/i386-linux-gnu/libpano13.so.2(ParseScript+0x846)[0xf6d1e536] > [...] > -------------- > > -------------- > # Summary > > * found the actual bug location, in libpano13. > * bug class : unchecked write to fixed size buffer (buffers have hardcoded size) > * hard-coded limits are inconsistent between files (source buffer 65536, destination buffer 256) > * easy to fix ? There is at least the quick-and-easy by increasing lower limit. > > ## Additional information > > It's in libpano13, file panorama.h, line 413 : > > #define PANO_PATH_LEN 255 > > In a nutshell, ParseScript can parse lines up to 65535 characters long, but Image structure only accepts full paths up to 256 characters long. > > ## Investigation details > > crash log says : > /lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x2b29d619b22d] > /usr/lib/libpano13.so.2(ParseScript+0x7f6)[0x2b29d51fe536] > > ParseScript is therefore a function in libpano13. > apt-get source libpano13 > cd libpano13-2.9.18+dfsg/ > > ParseScript is defined in parser.c. > It calls sprintf on line 448 > > case 'n': // Set filename > nextWord( buf, &li ); > sprintf( im->name, "%s", buf ); > break; > case 'm': // Frame > > buf is defined on line 148: > > char *li, line[LINE_LENGTH], *ch ,*lineStart, buf[LINE_LENGTH]; > > buf is big enough to hold a long filename : > > //Increased so more params can be parsed/optimized (MRDL - March 2002) > #define LINE_LENGTH 65536 > > Now check im->name. > > In ParseScript, im is defined on line 142: > > Image *im; > > Image type is defined in panorama.h on line 430-355: > > struct Image > { > // Pixel data > pt_int32 width; > pt_int32 height; > pt_int32 bytesPerLine; > pt_int32 bitsPerPixel; // Must be 24 or 32 > size_t dataSize; > unsigned char **data; > pt_int32 dataformat; // rgb, Lab etc > pt_int32 format; // Projection: rectilinear etc > int formatParamCount; // Number of format parameters. > double formatParam[PANO_PROJECTION_MAX_PARMS]; // Parameters for format. > int precomputedCount; // number of values precomputed for a given pano > double precomputedValue[PANO_PROJECTION_PRECOMPUTED_VALUES]; // to speed up pano creation > double hfov; > double yaw; > double pitch; > double roll; > cPrefs cP; // How to correct the image > char name[PANO_PATH_LEN+1]; > PTRect selection; > CropInfo cropInformation; // TO BE DEPRECATED > > pano_ImageMetadata metadata; > }; > > typedef struct Image Image; > > field "name" is on line 455: > > char name[PANO_PATH_LEN+1]; > > PANO_PATH_LEN is defined on panorama.h, line 413: > > #define PANO_PATH_LEN 255 > > Crash is explained. > -------------- > > cu Andreas > |
From: Andreas M. <ame...@do...> - 2013-01-20 11:17:57
|
Hello, this was reported on Ubuntu in <https://bugs.launchpad.net/ubuntu/+source/libpano13/+bug/1057012>, I am just forwarding, bug reported and diagnosed by Stephane Gourichon: Running cpfind in a directory with a long path ( > 256 characters for filename with full path) results in a bugffer overflow: -------------- [...] --- Find pair-wise matches --- *** buffer overflow detected ***: cpfind terminated ======= Backtrace: ========= /lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xf6b443c0] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe92fa)[0xf6b432fa] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xe8a38)[0xf6b42a38] /lib/i386-linux-gnu/i686/cmov/libc.so.6(_IO_default_xsputn+0x9e)[0xf6ac947e] /lib/i386-linux-gnu/i686/cmov/libc.so.6(_IO_vfprintf+0x478a)[0xf6a9e1ea] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__vsprintf_chk+0xa7)[0xf6b42ae7] /lib/i386-linux-gnu/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xf6b42a2d] /usr/lib/i386-linux-gnu/libpano13.so.2(ParseScript+0x846)[0xf6d1e536] [...] -------------- -------------- # Summary * found the actual bug location, in libpano13. * bug class : unchecked write to fixed size buffer (buffers have hardcoded size) * hard-coded limits are inconsistent between files (source buffer 65536, destination buffer 256) * easy to fix ? There is at least the quick-and-easy by increasing lower limit. ## Additional information It's in libpano13, file panorama.h, line 413 : #define PANO_PATH_LEN 255 In a nutshell, ParseScript can parse lines up to 65535 characters long, but Image structure only accepts full paths up to 256 characters long. ## Investigation details crash log says : /lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x2b29d619b22d] /usr/lib/libpano13.so.2(ParseScript+0x7f6)[0x2b29d51fe536] ParseScript is therefore a function in libpano13. apt-get source libpano13 cd libpano13-2.9.18+dfsg/ ParseScript is defined in parser.c. It calls sprintf on line 448 case 'n': // Set filename nextWord( buf, &li ); sprintf( im->name, "%s", buf ); break; case 'm': // Frame buf is defined on line 148: char *li, line[LINE_LENGTH], *ch ,*lineStart, buf[LINE_LENGTH]; buf is big enough to hold a long filename : //Increased so more params can be parsed/optimized (MRDL - March 2002) #define LINE_LENGTH 65536 Now check im->name. In ParseScript, im is defined on line 142: Image *im; Image type is defined in panorama.h on line 430-355: struct Image { // Pixel data pt_int32 width; pt_int32 height; pt_int32 bytesPerLine; pt_int32 bitsPerPixel; // Must be 24 or 32 size_t dataSize; unsigned char **data; pt_int32 dataformat; // rgb, Lab etc pt_int32 format; // Projection: rectilinear etc int formatParamCount; // Number of format parameters. double formatParam[PANO_PROJECTION_MAX_PARMS]; // Parameters for format. int precomputedCount; // number of values precomputed for a given pano double precomputedValue[PANO_PROJECTION_PRECOMPUTED_VALUES]; // to speed up pano creation double hfov; double yaw; double pitch; double roll; cPrefs cP; // How to correct the image char name[PANO_PATH_LEN+1]; PTRect selection; CropInfo cropInformation; // TO BE DEPRECATED pano_ImageMetadata metadata; }; typedef struct Image Image; field "name" is on line 455: char name[PANO_PATH_LEN+1]; PANO_PATH_LEN is defined on panorama.h, line 413: #define PANO_PATH_LEN 255 Crash is explained. -------------- cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' |
From: info p. <in...@pe...> - 2013-01-17 09:02:42
|
After typing cmake ../hugin-2012.0.0 on my Terminal, I get : [...] -- WARNING: you are using the obsolete 'PKGCONFIG' macro, use FindPkgConfig [...] -- libpano13 version: 2.9.18 major 2 minor 9 patch 18 [...] -- ZThread library not found. falling back to included copy -- flann library not found. falling back to included copy -- Found Lensfun: /opt/local/include *** Will install application bundles in /usr/local/Applications, set INSTALL_OSX_BUNDLE_DIR to change the location -- Using shared internal libraries -- Python libs version: 2.7.2 -- Install Python libs into /Library/Python/2.7/site-packages -- Current source dir = /Users/[username]/hugin -- Configuring done -- Generating done -- Build files have been written to: /Users/[username]/hugin-2012.0.0 I don't know how to set INSTALL_OSX_BUNDLE_DIR, how to install flann-1.8.3 and how to install Python libs into /Library/Python/2.7/site-packages (what package with easy_install ?). When I compile ZThread-2.3.2, after make instruction, I get : […] make[3]: *** [AtomicCount.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 After the make instruction, in hugin-2012.0.0, I get an error concerning hugin-2012.0.0/src/foreign/zthread/include/zthread/Guard.h. I solved the problem by defining the function createScope as a static bool instead of a static void function. Nonetheless I still have errors after the make instruction and I actually get : […] make[2]: *** [src/tools/CMakeFiles/hugin_hdrmerge.dir/hugin_hdrmerge.cpp.o] Error 1 make[1]: *** [src/tools/CMakeFiles/hugin_hdrmerge.dir/all] Error 2 make: *** [all] Error 2 Thanks a lot for your help. |
From: Toprak <oez...@hs...> - 2012-11-27 09:44:36
|
Ahoi Boys and Girls, The link to Mr. Dersch's website is broken (on panotools.sourceforge.net). Here is the working one: http://webuser.hs-furtwangen.de/~dersch/ Kind regards, Toprak |