[hugin-ptx] Re: Integration Queue - how do we add features to trunk and to release
On Thu, Sep 17, 2009 at 09:24:42PM -0400, Yuval Levy wrote: We could accelerate the sequence. Trunk and release 2009.2 are nearly in sync - lens calibration is the only difference. Once we release 2009.2.0 trunk is very near to release status. We could branch out immediately 2009.4.0_beta1 and within 1-2 weeks declare it 2009.4.0_RC1 and probably also final. We could have a release every few weeks. But it would be exhausting for the developers and confusing for the general public. Yuv, my vote from the sideline is to prefer release often. I hope that we don't get a lot of build problems again, once we've learned how to fix them. I hope we can keep them fixed. So releasing 2009.02 + lens calibration should be easy and not put a large load on everybody. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ --~--~-~--~~~---~--~~ 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] HuginPT application examples: Underwater photo-mosaic
*The UW- photomosaic* Someone here recently asked for more usage reports, so I thought I post a bit more what I try to use(misuse) Hugin for. I'm an active scuba diver and amateur marine archeologist. The conditions for these activities here in the Baltic sea are quite good for these activities, as there have been human activity here since the iceage, and the cold, dark brackish water preserves wrecks and wood very well. However, the dark low visibility waters makes photography challenging. And it is quite hard work documenting a site, or even get a rough overview at all. Therefore, tape measure and pencil-drawing still rules underwater archeology in many ways. A way to get an artificial overview is to make a photo mosaic, i.e. taking many overlapping photos close to the subject to while moving to cover the subject and then stitch these together. Scuba diving, it is possible to fly over a subject This has been done or many year using film. Where tilt, scale and exposure errors has been corrected in the process using adjustable enlarger and finally gluing photos together with torn edges (enblend). With programs like Photoshop Photomerge (of which I have no experience) It is possible to do this digitally (but still manual). As you may realize by now this is a special case of the linear panorama like this http://www.dojoe.net/tutorials/linear-pano/ However, the challenges here are many, for example: Close range wide angle shots Easily introduced tilt errors Subject topology big in relationship to subject distance, lots of perspective distortion. Weak light, and low contrast images often almost monochrome. When natural light cannot be used (=deeper than 10-20 m depending on location) uneven lighting effects. (However often systemically regular) One nice example of a partial mosaic of a recently found Dondald-Duck-wreck* see page 10 of of the document on this link. This one is made with Photomerge, which I personally think Enblend would easily outshine. http://www.foi.se/upload/projekt/mut07/Dokumentation/Patrik%20H%C3%B6glund.pdf *Hugin* And then 3 year ago a friend found hugin0.7 and we've been playing with hugin trying to generate mosaics of the excavation of a 17th century wreck in the Finnish archipelago. We had mixed results then and managed to get some decent results for small area well-behaved subjects with good camera technique. Basically, I believe the big problem using Hugin up until now has been to parametrize and optimize on the camera position for each shot, not using a panoramic center as with the classical panoramas. Therefore i find the result of GSOC2009 very interesting. What is going to be very interesting is to see if the optimization on individual camera positions will converge given the control point information. Lets get a bit more technical, there is research done in big-budget deep water archeology that could be interesting for the Hugin community. For example this document describes some of the challenges and algorithms used when using unmanned submarines to map up a photomosaic. There they use mission data to lay out camera positions, but I do think they must estimate a correction on these as well. See figure 8 and 9 for mosaic examples. These guys has also since looked closer into 3D mapping the subject. ftp://ftp.whoi.edu/pub/users/hanu/web_pdf/singh2004joe.pdf Cheers /O (* A Donald Duck wreck is a upright standing, intact wreck with masts, cannons, and half open gold ducate filled treasury chests, just like in the comics ;-) --~--~-~--~~~---~--~~ 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-2009.2.0_beta4 released
On 14 сен, 09:21, Yuval Levy goo...@levy.ch wrote: Panorama stitching and more. A powerful software package for creation and processing of panoramic images. A hugin-2009.2.0_beta4 (beta release 4) tarball is available here: Sorry if it was reported before, but two messages from Stitching tab in Preferences dialog seem to be not translatable: Default Interpolator (i) and Create cropped images by default 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: Hugin-2009.2.0_beta4 released
On 18 сен, 16:41, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: Sorry if it was reported before, but two messages from Stitching tab in Preferences dialog seem to be not translatable: Default Interpolator (i) and Create cropped images by default No, false alarm. Gtranslator is playing silly buggers. Please ignore :) 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: 20090916 Nightly Build for Ubuntu - segfault
Gerry Patterson wrote: I have the latest version of both hugin 4437 and libpano 1055 and I can't reproduce the segfault. I am running GNU/Linux (k)ubuntu 9.04. i386. Is there a walk through that one can give me? 1. I create the jpgs with ptodummy and loaded the project. error was with TIFFs. I tested again. Jim Watters fixed it in SVN 1056. Thank you, Jim! Yuv --~--~-~--~~~---~--~~ 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: HuginPT application examples: Underwater photo-mosaic
I realized now that the link in my mail is rather large, it is 7,7MB, and their FTP site rather slow. Keep trying downloading it though. The the same mosaic examples you can find in this conference article, although they don't discuss the algorithm in the same detail. (slightly more than 1 MB) http://web.mit.edu/mindell/www/Publications/ENALIA_2002a_3325.pdf 2009/9/18 Oskar Sander oskar.san...@gmail.com *The UW- photomosaic* ftp://ftp.whoi.edu/pub/users/hanu/web_pdf/singh2004joe.pdf -- /O --~--~-~--~~~---~--~~ 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: Integration Queue - how do we add features to trunk and to release
Yuval Levy schrieb: Hi all, particularly develoeprs, - vigra-1.6 (Lukáš' patch from before 0.8.0) I think this is best done by adding the hugin changes to the main vigra lib. Most changes are related to the vigra impex functinality, and it shouldn't be hard to get them integrated (Maybe except for one place were I have changed the behaviour when saving floating point images into an integer format.) After that we can simply wait until vigra 1.7.0 is released with our patches in and then remove vigra from our tree. - control-point cleaning (Thomas patch) - auto-crop (Gary's patch) - gsoc_2008_masking (Fahim's project) - gsoc_2008_feature_atching (Onur's project) The longer we wait, the more trunk will diverge and the more difficult integration will become. Moreover, there is a risk that newer changes will be implemented against the current trunk and will not be compatible once what is in the queue enters trunk. I'd like to go systematically and efficiently through the integration of the above features. There are three steps: 1. Maturity 2. Trunk Integration 3. Release and then there is a 4. Shortcut 1. MATURITY Only mature codelines/patches will be considered for integration in trunk can we verify the maturity of the PROJECTS? Build and test them! Actually, I did start a little work on the feature matching, however this is half finished and does not even compile, so I haven't commited that yet. I think the two remaining gsoc2008 are the ones that need most work, and therefore aren't in a position to be included before some work has been done on them. 2. TRUNK INTEGRATION IMO there is currently one feature that needs this sort of special attention: it is gsoc2009_layout. It introduces a very important, significant and welcome change in the underlying panorama model. It affects almost every part of the code. The longer we wait, the more difficult it will be to integrate. The question (to James, and his mentor Bruno) is: is it mature? if yes, when do you have time to take care of the integration? Planning around James' project: what should we send to integration before and what after? I haven't yet looked at: - control-point cleaning (Thomas patch) - auto-crop (Gary's patch) but I suspect that they are not too dependent on the layout work. So they could go in either before or after James. I think gsoc2009_layout should be integrated as soon as possible after 2009.4, if the marturity allows it. 4. SHORTCUT Specifically: lens calibration does not affect Hugin's main functionality at all. Should we send one extra chunk of code with it, and if yes which one? I couldn't find the control point cleaning patch in the patches tracker of hugin, can somebody point me to it? It might a good candidate for merging into trunk before 2009.4 ciao Pablo --~--~-~--~~~---~--~~ 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] cmake not working
I have a problem with the cmake configuration for libpano. -- d...@phosphorus:~/hacking/libpano$ cmake CMakeLists.txt CMake Error at CMakeLists.txt:38 (include): include could not find load file: HuginMacros CMake Error at /usr/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57 (MESSAGE): Could NOT find wxWidgets (missing: wxWidgets_FOUND) Call Stack (most recent call first): /usr/share/cmake-2.6/Modules/FindwxWidgets.cmake:765 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:54 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! d...@phosphorus:~/hacking/libpano$ -- Libpano is defined as dependent of hugin and wxWidgets. In my laptop I don't have neither one, so it fails. Libpano should not depend on hugin and wxwidgets. As far as I know, there is nothing on libpano that depends on hugin. Is this really necessary? libpano should depend only on zlib, java, libpng, libjpg, and libtiff. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . --~--~-~--~~~---~--~~ 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: cmake not working
On Fri 18-Sep-2009 at 13:22 -0700, Daniel M. German wrote: Libpano is defined as dependent of hugin and wxWidgets. In my laptop I don't have neither one, so it fails. Libpano should not depend on hugin and wxwidgets. As far as I know, there is nothing on libpano that depends on hugin. The cmake build system in libpano13 is primarily to make things easier for building on Windows - wxwidgets contains local copies of libtiff, libpng and libjpeg so these are used in the Windows build. -- 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: cmake not working
Bruno Postle wrote: On Fri 18-Sep-2009 at 13:22 -0700, Daniel M. German wrote: Libpano is defined as dependent of hugin and wxWidgets. In my laptop I don't have neither one, so it fails. Libpano should not depend on hugin and wxwidgets. As far as I know, there is nothing on libpano that depends on hugin. The cmake build system in libpano13 is primarily to make things easier for building on Windows - wxwidgets contains local copies of libtiff, libpng and libjpeg so these are used in the Windows build. right - then on the other side what is a CMake build worth if it adds dependencies when none are needed? we had this discussion when setting up the CMake build for enblend, and I think the same solution can and should be adopted for Libpano. Then it will behave how Daniel expects it. The initial draft of CMake build for Libpano by Tom Sharpless used Hugin's CMakeModules. The initial draft of CMake build for Enblend did the same. It was vetoed from the repository until it was made independent. This meant in the short term a duplication of Hugin's CMakeModules folder. That folder should anyway disappear with time - better use CMake's default FindXXX modules when they are available and work; and contribute improvements upstream. Yuv --~--~-~--~~~---~--~~ 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: cmake not working
Am Freitag 18 September 2009 schrieb D M German:
I have a problem with the cmake configuration for libpano.
--
d...@phosphorus:~/hacking/libpano$ cmake CMakeLists.txt
CMake Error at CMakeLists.txt:38 (include):
include could not find load file:
HuginMacros
CMake Error at
/usr/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmake:57
(MESSAGE): Could NOT find wxWidgets (missing: wxWidgets_FOUND)
Call Stack (most recent call first):
/usr/share/cmake-2.6/Modules/FindwxWidgets.cmake:765
(FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:54 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
d...@phosphorus:~/hacking/libpano$
--
Libpano is defined as dependent of hugin and wxWidgets. In my laptop I
don't have neither one, so it fails.
Libpano should not depend on hugin and wxwidgets. As far as I know,
there is nothing on libpano that depends on hugin.
Is this really necessary?
libpano should depend only on zlib, java, libpng, libjpg, and libtiff.
--dmg
We could make it dependent on WIN32.
In fact, here it compiles.
===
--- CMakeLists.txt (revision 1057)
+++ CMakeLists.txt (working copy)
@@ -34,8 +34,10 @@
set(CMAKE_MODULE_PATH ${SOURCE_BASE_DIR}/hugin/CMakeModules )
ENDIF ( HUGIN_BASE_DIR )
-## load the Hugin cmake modules
-include(HuginMacros)
+if(WIN32)
+ ## load the Hugin cmake modules
+ include(HuginMacros)
+endif()
include(CheckIncludeFiles)
## global setup
Kornel
--
Kornel Benko
kornel.be...@berlin.de
signature.asc
Description: This is a digitally signed message part.
[hugin-ptx] Re: 20090916 Nightly Build for Ubuntu - segfault
Dale, Can you confirm as well that if you upgrade to libpano SVN 1056, that your problem is fixed? - Gerry On Fri, Sep 18, 2009 at 8:11 AM, Yuval Levy goo...@levy.ch wrote: Gerry Patterson wrote: I have the latest version of both hugin 4437 and libpano 1055 and I can't reproduce the segfault. I am running GNU/Linux (k)ubuntu 9.04. i386. Is there a walk through that one can give me? 1. I create the jpgs with ptodummy and loaded the project. error was with TIFFs. I tested again. Jim Watters fixed it in SVN 1056. Thank you, Jim! Yuv --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
