[hugin-ptx] Re: kqueue fail on stitch - mac
Hi Rhonda, looking your snowscape project file I see that the last image is in a different directory (folder Desktop backgrounds, try to omit spaces and special characters in file and folder names...) than the others. It's usually best to keep all image files plus the .pto in the same folder. The lens is now optimized to about a 13 mm rectilinear lens, that's pretty unlikely. I'll reset that to something more plausible like 35 mm (v54 for your images in landscape orientation). Also the values for your camera's sensor shift (d and e) seem to be off, I'll reset those to 0. I opened the .pto in hugin 0.7 svn2765 and your output settings in the stitcher tab are set to output remapped images and no blended panorama (but enfused, please). I deselect the exposure blending option and select to output a normal blended panorama, I guess that's what you want to get. Now in the Optimizer tab I switch to Optimize the custom parameters below, deselect everything but y (never for all images, leave one deselected as anchor image) and v. Some CPs look like they are way off now in the control point table. Now I also select 'p' for all images and optimize again. Still looks good with my dummy images. In the panorama preview window I click on the 'Center' button. Adding 'r' to the optimization makes everything go haywire. Did you shoot those images from a tripod or did you just aim at the horizon? Was the camera aimed at the horizon or slightly tilted up or downwards? The fourth images doesn't look like it has too much overlap with the third one. You don't use a wide angle converter, do you? I also reset all p and r values to 0 in the images tab, try different optimizing combinations, delete some of the control points that are far from one image's center. If I had the images I would probably try to find more control points but I guess that's not really easy in this case. My best guess for the moment (i.e. without seeing the original images) is snowscape2.pto in the files section. pano-4.JPG is now assumed to be in the same folder as the other images and the .pto file. That seems to work (stitch some output) in hugin 0.7 svn2765 on a G4 with 10.3.9. Oh no, I get an Error while executing process, I'll better switch to a different OS / hugin combination... Update: works in hugin 0.8.0 svn3888 20090529 from Harry on a G4 with 10.5.7 Carl Rhonda wrote: Sure. I can upload the actual photos as well if you like. They're not really the greatest for panorama-making, being taken by a cheap digital camera that I don't think is even capable of setting exposure to manual, so they all have different exposure levels. And are crooked. I took the photos 3 or 4 years ago and only just learned about hugin the other day; I had nearly despaired of ever being able to make a panorama with them :-) I'm uploading it into the files section, snowscape.pto whenever it makes it across the wires, which are currently being unreliable on my end. Thanks, -Rhonda On Jun 2, 8:13 am, Carl von Einem c...@einem.net wrote: Could you attach your .pto file so we can try that with dummy images on other systems? Carl Rhonda wrote: Yes, I ran through the assistant, created additional control points (it's a snowscape, not a lot of really distinct features for the auto control point program to latch onto) played in the various tabs, all trying to get the preview to look right. I stopped using the assistant when it would insist on flipping one of the photos upside down even with 8+ control points in the overlap area distributed both horizontally and vertically, and instead went back and forth with the control point editor, image tab, optimizer, and previewer until it looked close to what I wanted. Then I tried to create the single panorama image. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin-0.8.0_rc1 released
On 2 июн, 10:29, Lukáš Jirkovský l.jirkov...@gmail.com wrote: 2009/6/1 Harry van der Wolf hvdw...@gmail.com: I can see that it has been applied to the trunk, so it's most likely in all newer wxWidgets. Anyway if I get right it's only fixing the problem with showing the text in opened window. So there is no way we could have this bug fixed? Alexandre --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: OpenGL slow because of reloading
Yes, I am using Vista. I duplicated this issue in Traditional Chinese and English, just to be sure it was not a wide character issue. I loaded a project file from a project I previoulsy complete, 94 images enfused blended pano. Then press align button. After the Levelling panorama step, it starts Loading Images and crashes about 10 seconds into that after loading a few images. The Fast Preview window never opens. Let me know if you additional details. Rick On Jun 3, 9:40 pm, Bruno Postle br...@postle.net wrote: On Wed 03-Jun-2009 at 08:29 -0500, Gerry Patterson wrote: What platform are you using? So understand, the steps to reproduce this problem are: 1. load a project .pto file 2. press the align button on the assistant tab. Rick is using Windows, but possibly this only appears with a zh_TW locale. -- Bruno --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin-0.8.0_rc2 released
2009/6/3 Stuart Henderson s...@spacehopper.org On 2009-06-01, Bruno Postle br...@postle.net wrote: * hugin will use system lapack if available. Note that this is experimental, you may find that optimisation is slower than before and may even fail. On my system (OpenBSD) lapack is detected and used if it's installed, but we must also link with libm and libblas, otherwise there are unresolved symbols, causing linking of celeste_standalone to fail. Same on MacOSX (also in the earlier builds after 3880). I thought it had something to do with MacOSX being a little different than the linuxes and BSD's around. The cmake version finds lapack, but the build itself doesn't use it. why? (still MacOSX being a little different?) The XCode build just crashed due to the unresolved dependencies. As we are trying to release a stable 0.8, I disabled the lapack functionality for OSX as Hugin has functioned correctly very long without it. So, I decided to postpone it on OSX after the 0.8 release (and yes, I know, that was not a democratic decision). That's also why I decided not to ask Lukas about it as he is busy now with his gsoc project. Hoi, Harry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin-0.8.0_rc2 released
2009/6/3 Harry van der Wolf hvdw...@gmail.com: 2009/6/3 Stuart Henderson s...@spacehopper.org On 2009-06-01, Bruno Postle br...@postle.net wrote: * hugin will use system lapack if available. Note that this is experimental, you may find that optimisation is slower than before and may even fail. On my system (OpenBSD) lapack is detected and used if it's installed, but we must also link with libm and libblas, otherwise there are unresolved symbols, causing linking of celeste_standalone to fail. Same on MacOSX (also in the earlier builds after 3880). I thought it had something to do with MacOSX being a little different than the linuxes and BSD's around. The cmake version finds lapack, but the build itself doesn't use it. why? (still MacOSX being a little different?) The XCode build just crashed due to the unresolved dependencies. As we are trying to release a stable 0.8, I disabled the lapack functionality for OSX as Hugin has functioned correctly very long without it. So, I decided to postpone it on OSX after the 0.8 release (and yes, I know, that was not a democratic decision). That's also why I decided not to ask Lukas about it as he is busy now with his gsoc project. Hoi, Harry I'll fix that, but probably not until tomorow. Lukas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: hugin-0.8.0_rc2 released
2009/6/3 Lukáš Jirkovský l.jirkov...@gmail.com:
2009/6/3 Harry van der Wolf hvdw...@gmail.com:
2009/6/3 Stuart Henderson s...@spacehopper.org
On 2009-06-01, Bruno Postle br...@postle.net wrote:
* hugin will use system lapack if available. Note that this is
experimental, you may find that optimisation is slower than before
and may even fail.
On my system (OpenBSD) lapack is detected and used if it's installed,
but we must also link with libm and libblas, otherwise there are
unresolved symbols, causing linking of celeste_standalone to fail.
Same on MacOSX (also in the earlier builds after 3880). I thought it had
something to do with MacOSX being a little different than the linuxes and
BSD's around.
The cmake version finds lapack, but the build itself doesn't use it. why?
(still MacOSX being a little different?)
The XCode build just crashed due to the unresolved dependencies.
As we are trying to release a stable 0.8, I disabled the lapack
functionality for OSX as Hugin has functioned correctly very long without
it. So, I decided to postpone it on OSX after the 0.8 release (and yes, I
know, that was not a democratic decision). That's also why I decided not to
ask Lukas about it as he is busy now with his gsoc project.
Hoi,
Harry
I'll fix that, but probably not until tomorow.
Lukas
Anyway,
I'm not sure if it's necessary to use my module. In fact there's
module called FindLAPACK bundled with CMake, but I've found out that
this one looks also for the fortran compiler which is on all systems
I've tested (unfortunately only Linuxes) not necessary to build it. So
I've made simpler one which looks only for the lapack library.
But from your output it seems that your systems has LAPACK in form of
sources or maybe it's linked differently so it needs Fortran (or g2c
which is Fortran to C translator). Anyway blas really should be part
of dependencies.
Now I'm quite indecisive if I should change the FindLAPACK in hugin in
some way or if I should remove it in favor of the CMake one (but it
results in lapack not found on all systems without Fortran compiler
(and it doesn't find gfortran on my system). All in all when we decide
to keep the FindLAPACK in hugin blas should be added.
I'm not sure if it's possible to determine if the LAPACK library found
by cmake is usable without fortran compiler or not, but it would be
the best solution. For the 0.8 we could simply remove the FindLAPACK
module (it would still use the bundled module), but it would result
that on quite a big number of systems lapack would not be found (but
on the other hand it's better than not-compiable hugin).
Anyway, I've tried to solve it right now (I don't like that I've broke
something so I want to fix it ASAP). Could you please try attached
patch?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
hugin and other free panoramic software group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---
Index: CMakeModules/FindLAPACK.cmake
===
--- CMakeModules/FindLAPACK.cmake (revision 3913)
+++ CMakeModules/FindLAPACK.cmake (working copy)
@@ -7,7 +7,7 @@
# LAPACK_LIBRARIES, release link library list.
# LAPACK_FOUND, If != YES, do not try to use PANO13.
-FIND_LIBRARY(LAPACK_LIBRARIES
+FIND_LIBRARY(LAPACK_LAPACK_LIBRARY
NAMES lapack
PATHS /usr/lib
/usr/local/lib
@@ -15,7 +15,31 @@
${SOURCE_BASE_DIR}/lapack
)
-IF(LAPACK_LIBRARIES)
+FIND_LIBRARY(LAPACK_BLAS_LIBRARY
+ NAMES blas
+ PATHS /usr/lib
+/usr/local/lib
+${SOURCE_BASE_DIR}/
+${SOURCE_BASE_DIR}/lapack
+ )
+
+FIND_LIBRARY(LAPACK_G2C_LIBRARY
+ NAMES g2c
+ PATHS /usr/lib
+/usr/local/lib
+${SOURCE_BASE_DIR}/
+${SOURCE_BASE_DIR}/lapack
+ )
+
+IF(LAPACK_LAPACK_LIBRARY)
+ IF(LAPACK_BLAS_LIBRARY)
+SET(LAPACK_LIBRARIES ${LAPACK_BLAS_LIBRARY})
+ ENDIF(LAPACK_BLAS_LIBRARY)
+ IF(LAPACK_G2C_LIBRARY)
+SET(LAPACK_LIBRARIES ${LAPACK_G2C_LIBRARY})
+ ENDIF(LAPACK_G2C_LIBRARY)
+
SET( LAPACK_FOUND YES )
-ENDIF(LAPACK_LIBRARIES)
+ SET(LAPACK_LIBRARIES ${LAPACK_LAPACK_LIBRARY} ${LAPACK_LIBRARIES})
+ENDIF(LAPACK_LAPACK_LIBRARY)
