[hugin-ptx] Missing files in creatin doc's in enblend
Hi Christoph, the first one is maybe a typo versenblend.texi - varsenblend.texi the second is really missing: config-h.texi ... texi2dvi: Creating /usr/BUILD/BuildEnblend/doc/enblend.pdf from /usr/src/enblend/enblend/doc/enblend.texi [ 57%] cd /usr/BUILD/BuildEnblend/doc /usr/local/texlive/2008/bin/x86_64-linux/makeinfo --css-include=/usr/src/enblend/enblend/doc/default.css -I /usr/src/enblend/enblend/doc -o /usr/BUILD/BuildEnblend/doc/enblend.info /usr/src/enblend/enblend/doc/enblend.texi /usr/src/enblend/enblend/doc/enblend.texi:14: @include `varsenblend.texi': No such file or directory. /usr/src/enblend/enblend/doc/enblend.texi:14: @include `config-h.texi': No such file or directory. ... Kornel -- Kornel Benko kornel.be...@berlin.de signature.asc Description: This is a digitally signed message part.
[hugin-ptx] Re: Missing files in creatin doc's in enblend
Kornel - I sent you an email with the info concerning my latest changes. Breakage is expected. On Sep 21, 8:49 am, Kornel Benko kornel.be...@berlin.de wrote: the first one is maybe a typo versenblend.texi - varsenblend.texi SIC. See rev6b57666aa217. the second is really missing: config-h.texi See rev256fc64fe72b. texi2dvi: Creating /usr/BUILD/BuildEnblend/doc/enblend.pdf from /usr/src/enblend/enblend/doc/enblend.texi [ 57%] cd /usr/BUILD/BuildEnblend/doc /usr/local/texlive/2008/bin/x86_64-linux/makeinfo --css-include=/usr/src/enblend/enblend/doc/default.css -I /usr/src/enblend/enblend/doc -o /usr/BUILD/BuildEnblend/doc/enblend.info /usr/src/enblend/enblend/doc/enblend.texi /usr/src/enblend/enblend/doc/enblend.texi:14: @include `varsenblend.texi': No such file or directory. /usr/src/enblend/enblend/doc/enblend.texi:14: @include `config-h.texi': No such file or directory. You build with CMake, which must fail after the changes stated above. Autotool's configure(1) works ok. /Chris --~--~-~--~~~---~--~~ 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] Picasa button for Hugin on Mac
Hi, I tried to make a Picasa Hugin button for Mac by modifying Jacob's button for Windows: http://jacob.hoffman-andrews.com/hacks/hugin-picasa-button.html The button gets installed, properly starts Hugin, but Hugin crashes soon after starting. The most probable reason is that Hugin tries to load the first image as a project file rather than adding them to the current (or better new) project. The status line shows Opening project: ...jpg Is it possible to change this behaviour on Mac so it is possible to make a Picasa button? That would be a really great thing! Crash report attached below. Thanks, Rafal Process: Hugin [2024] Path:/Applications/Hugin.app/Contents/MacOS/Hugin Identifier: net.sourceforge.hugin.Hugin Version: 0.8.0 () Code Type: X86 (Native) Parent Process: launchd [94] Date/Time: 2009-09-20 16:13:51.223 -0700 OS Version: Mac OS X 10.6.1 (10B504) Report Version: 6 Interval Since Last Report: 284803 sec Crashes Since Last Report: 109 Per-App Interval Since Last Report: 8658 sec Per-App Crashes Since Last Report: 4 Anonymous UUID: E2D87819-E944-4D15- A1A6-04A42740890A Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x92d85912 __kill + 10 1 libSystem.B.dylib 0x92d85904 kill$UNIX2003 + 32 2 libSystem.B.dylib 0x92e18b99 raise + 26 3 libSystem.B.dylib 0x92e2ec50 abort + 93 4 net.sourceforge.hugin.base_wx 0x0139c77d 0xdf2000 + 5941117 5 net.sourceforge.hugin.base_wx 0x012c204e HuginBase::PanoramaMemento::loadPTScript(std::istream, int, std::string const) + 8974 6 net.sourceforge.hugin.Hugin 0x000f7837 PT::wxLoadPTProjectCmd::execute() + 151 7 net.sourceforge.hugin.Hugin 0x00029968 CommandHistory::addCommand(AppBase::Commandstd::string*, bool) + 472 8 net.sourceforge.hugin.Hugin 0x000aba23 MainFrame::LoadProjectFile(wxString const) + 1587 9 net.sourceforge.hugin.Hugin 0x00086b5f huginApp::OnInit() + 9535 10 net.sourceforge.hugin.Hugin 0x000891e1 wxAppConsole::CallOnInit () + 17 11 libwx_macu-2.8.0.5.0.dylib 0x004ee76a wxEntry(int, wchar_t**) + 58 12 net.sourceforge.hugin.Hugin 0x00082f58 main + 24 13 net.sourceforge.hugin.Hugin 0x2362 start + 258 14 net.sourceforge.hugin.Hugin 0x2289 start + 41 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x92d4b03a kevent + 10 1 libSystem.B.dylib 0x92d4b768 _dispatch_mgr_invoke + 215 2 libSystem.B.dylib 0x92d4abf9 _dispatch_queue_invoke + 183 3 libSystem.B.dylib 0x92d4a98a _dispatch_worker_thread2 + 234 4 libSystem.B.dylib 0x92d4a401 _pthread_wqthread + 390 5 libSystem.B.dylib 0x92d4a246 start_wqthread + 30 Thread 2: 0 libSystem.B.dylib 0x92d4a092 __workq_kernreturn + 10 1 libSystem.B.dylib 0x92d4a628 _pthread_wqthread + 941 2 libSystem.B.dylib 0x92d4a246 start_wqthread + 30 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x ebx: 0x92e2ebff ecx: 0xbfffdb1c edx: 0x92d85912 edi: 0x0009 esi: 0xa0492b10 ebp: 0xbfffdb38 esp: 0xbfffdb1c ss: 0x001f efl: 0x0282 eip: 0x92d85912 cs: 0x0007 ds: 0x001f es: 0x001f fs: 0x gs: 0x0037 cr2: 0xa0783000 Binary Images: 0x1000 - 0x2c3ffb +net.sourceforge.hugin.Hugin 0.8.0 () 93AD2905-5671-5A08-4D8E-7BA422FDF0D2 /Applications/Hugin.app/ Contents/MacOS/Hugin 0x3ab000 - 0x3abff7 libmx.A.dylib ??? (???) 01401BF8-3FC7-19CF- ACCE-0F292BFD2F25 /usr/lib/libmx.A.dylib 0x3ae000 - 0x406ff4 +libpano13.dylib ??? (???) 2C6830D4-F2AB- F8C0-2EF7-D0AA4E6C7208 /Applications/Hugin.app/Contents/Libraries/ libpano13.dylib 0x41 - 0x42fffb +libpng.3.1.2.38.dylib ??? (???) BFCB8C86- CF20-5576-3708-A74EF5D2B141 /Applications/Hugin.app/Contents/ Libraries/libpng.3.1.2.38.dylib 0x437000 - 0x483fef +libtiff.3.dylib ??? (???) A50CAEFF- ECFE-5B90-2643-686E496E59E3 /Applications/Hugin.app/Contents/ Libraries/libtiff.3.dylib 0x48b000 - 0x4a7ff3 +libjpeg.62.0.0.dylib ??? (???) /Applications/ Hugin.app/Contents/Libraries/libjpeg.62.0.0.dylib 0x4ac000 - 0x996ff7 +libwx_macu-2.8.0.5.0.dylib ??? (???) 4829F5C7-D09B-23EF-871C-46AAF032CFD4 /Applications/Hugin.app/ Contents/Libraries/libwx_macu-2.8.0.5.0.dylib 0xc2a000 - 0xc32ff3 +libIex.6.0.0.dylib ??? (???) /Applications/ Hugin.app/Contents/Libraries/libIex.6.0.0.dylib 0xc3d000 - 0xccffef +libIlmImf.6.0.0.dylib ??? (???)
[hugin-ptx] Re: Tilt transformation...
Dmg, If I am running an optimization using Autooptimize using the new Tilt parameters in the new panotools version, what is the parameter syntax in the pto-file? Cheers /O 2009/9/11 Oskar Sander oskar.san...@gmail.com 2009/9/10 dmg d...@uvic.ca to be honest, I am not sure how much they will help for a mosaic. The model for panos in libpano is still spherical. But it is a matter of trying. scale scales the tilt operations only. It actually scales the view point from which the photo was originally taken. --dmg Well, one major problem when fudging mosaics currently in Hugin without Dev's addition. Is that yaw, pitch and x,y are not independent of the lens distortion model and the panoramic node(what do you call it?). Which means that the mosaic quickly gets FU because: 1 Slightest camera tilt causes distortion that cannot be handled by yaw or pitch, as these are applied in the sphere center, not the translated camera position (x,y) and 2. any x, y translation will move the image from the center within the distortion model and may give horrific results as obviously distortion center in the case of the mosaic application is in the center of each camera viewpoint In my mind, your addition solves both of these issues, by optimizing your new parameters instead of y,p,x,y. Then the panosphere issue would be interesting to discuss. It could maybe overcome if you see each camera position as being closer to the sphere's surface and the final panoramic viewpoint further back... Cheers /O -- /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: Aerial Photography Stitching
Hi Matt 2009/9/21 Matt Williams li...@milliams.com: Hi guys, I've only recently discovered Hugin so I'm still getting used to it so bear in mind that there's probably still plenty I'm missing. I'm a mapper for OpenStreetMap (http://openstreetmap.org), a project to create a free map of the world. Recently someone sponsored a round of amateur aerial photography of the area around the town of Stratford- upon-Avon in the UK. We now have the full set of aerial imagery (around 900 photos) of the whole town from various directions and at various angles to the vertical. You can see a summary of the data at http://milliams.com/verticalitymetre/stats.php and http://milliams.com/verticalitymetre/map.html (where a low number score is more vertical). Now, we've got to the stage where we would like to be able to rectify this imagery to the map and stitch all this imagery together in a mostly seamless way. Perhaps Hugin/Panorama Tools isn't really what I should be using for this but it's so close to doing what we need, I'd be surprised if it couldn't be coerced into shape. The method I've been using so far (and I've only done a few small tests with it, nothing large scale) is based on http://www.dojoe.net/tutorials/linear-pano/ and is to select a few (that's only 2 or 3 so far) overlapping images which are very nearly vertical, add them to Hugin and deselect the 'Image Center Shift' link for the lens. I've autopano-sift'd them to add control points. Then, I've added a png of a map image (from openstreetmap) as the first image, set a different lens number for it (made up a DoV of about 10 degrees) and set it as the position anchor. Then I've manually added control points (by hand) between each of the images and the map in order to try to coerce Hugin to align the images to the map. I then enblend the remapped images together (excluding the map png) and upload it to http://warper.geothings.net/ which is our map warper for aligning it to the map. This allows me to slightly tweak the rectification to make it match the map more closely. This mostly works for small image clusters but I am ofter getting divergence from the map at the edge of the image. What I would like to ask is whether anyone has any experience with this sort of work and has some suggestions about the best way to do it or if Hugin/Panorama Tools really isn't suitable for the job. I've looked through a paper published on this topic at http://www.cc.gatech.edu/~pesti/pubs/mapstitcher.pdf and it seems to suggest the best results are achieved when doing the stitching and ortho-rectification (and map alignment) at the same time to avoid cumulative errors (as seen at http://warper.geothings.net/uploads/1315/original/test3.jpg, that main road should be almost straight). Thoughts/suggestions/revelations? Regards, Matt Williams http://milliams.com First, there are some new tilt options to the panorama tools (Tx, Ty, Tz and Ts) but doesn't use them yet. I'd try to load map into hugin and manually add control points to photos and corresponding parts of map. Then optimize with map set as anchor image. This would hopefully transform images to fit map directly in hugin. And for stitching I'de disable the map so it doesn't blend with photos by coincidence. Anyway, interesting project. regards, 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: HuginPT application examples: Underwater photo-mosaic
took some time to load, but here it was. What is the original resolution of the mosaic? in the PDF viewer I zoomed at 400%... I belive this one was taken with a Nikon D300, but there has also been experiments with framegrabbs from a HD video camera. The swim-by can be easier with a videocam at times instead of DSLR if not an insane resolution is required. Myself I use only a stillcam setup, video is not for true artist ;-) Digital really is the way to go UW, the instant feedback on your photography techique is what makes the whole difference and simplified post processing as a bonus. Visibility like this [1] from 4 weeks ago in Narvik is rare if not impossible in the Baltic unfortunately. Part from the mosaic-application, I find taking classic mini panoramas on freehand can be quite successful too when trying to capture a very wide view, like [2] which was just three shots fired off without any special thought on technique. I have only used Hugin GUI so far, but I'd like to play around with the new panotools implementation on tilt, so let's discuss how to test that (maybe separate thread) [1] http://www.dykarna.nu/fotoalbum/21774/259510.html [2] http://www.dykarna.nu/fotoalbum/19221/259511.html Cheers /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: GSoC2008_masking
Carl von Einem wrote: I always prefer (if possible) to save masks as paths me too. Original Message In any case, below is how I would integrate masking into my workflow. Please understand this is one case, and an example only. 1. capture images 2. convert raw to tiff (or some other lossless format) 3. load images into hugin 4. load stored lens data, (crop circle and distortion params) 5. create control points 6. pairwise optimize to get rough position 7. mask out problem/undesired areas. 8. cleanup/tweak control points (reoptimizing as necessary) 9. generate final output I rather have 7 before 5, although it is an iterative process (especially if you want to consider positive masking as well). Below is what I do now: 1. capture images 2. convert raw to tiff (or some other lossless format) 3. load images into gimp, mask out areas I don't want. (tripod, pano head) 4. load images into hugin 5. load stored lens data, (crop circle and distortion params) 6. create control points 7. pairwise optimize to get rough position 8. realize there are other places I want/need to mask out. 9. Determine which images I need to edit mask by using the preview window. 10. save and exit hugin 11. reload images into gimp and update the mask again 12. load the previously saved project in hugin 13. cleanup/tweak control points (reoptimizing as necessary) 14. generate final output sounds very similar to what I do, although I don't doo pairwise optimization - I lay the images out roughly based on the shooting pattern. Probably pairwise CP detection and optimization would increase the speed and accuracy of my process if scripted/automated but I have not taken the time to do so - results are sufficient when detecting and optimizing the whole thing. In this case, I thought adding the masking interface to the crop tab would be the best place, as one is attempting to acomplish basically the I'd prefer an interface for masking that can display two different images side by side, e.g. the CP editor tab. That way I can quickly decide which parts in one image are better that parts in another. indeed, I think this is the reason why Fahim implemented it in preview mode - makes it easier to decide which parts in one image are better than parts in another; enable to deal with distortions at zenith and nadir (change the perspective / view to something convenient, do the masking; change it back) and enables positive masking (apply the mask's shape to all underlying images - in positive and negative as necessary). Positive masking would be some what tricky since, as far as I know, the only way to guarantee an area of one image will definately appear is to apply a negative mask to all of the overlapping images of the area. Is that correct? You could also order the images in a different way (move up or down in images tab) which somehow makes a difference for enblend. I'd love to be able to control that behaviour better, e.g. by using positive masking. image ordering is not as effective as proper positive masking - for which I also see apply negative mask to all of the overlapping images of the area as the only way to guarantee it, as Gerry stated. Would a few people please give me some examples of how they would like to use masking within Hugin? Today I often enough have to edit masks of images that are already loaded in a hugin project. To see the difference I need to newly load the whole project. I'd prefer a button in the preview window that allows to just reload all images (or maybe also just one). keep them coming 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] Any free/open source tools to create QTVR/Cubic/Spherical Panorama
I stitched the panorama images by Hugin. But I need to convert it to QTVR/Cubic/Spherical Panorama format. Any free/open source tools to create QTVR/Cubic/Spherical Panorama to recommend? --~--~-~--~~~---~--~~ 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] [OSX] hugin-mac-2009.2-RC1 for download
Hi Mac users, I just published the new 32bit Hugin 2009.2-RC1 bundle. This is a release candidate and may be declared final in the coming days. See the Changelog: http://groups.google.com/group/hugin-ptx/browse_thread/thread/4f03311ffe435314 *Note: This build features the new Autopano generator options as built by Thomas Modes and now ported to MacOSX to provide greater flexibility in AutoCP generator options.* It will make things a little more complicated, but gives you great flexibility. You need to copy the Hugin.app the way you always do: no changes there. Download either or both the new Hugin 2009 ControlPoint Generators. They are just the old reliable panomatic and autopano-sift-c but not any longer as plugins but as naked binaries. The Controlpoint.dmg's contain an installer that copies the binary to the same directory where the plugins resided. When you start Hugin, go to preferences and to the Control Point Detectors pane. Here you can add panomatic and/or Autopano-SIFT-C. It is now possible to create different configurations based on the same generator. panomatic default parameters: -o %o %i autopano-sift-c default parameters: --maxmatches %p %o %i autopano-sift-c 120+ images: --maxmatches %p %o %s For autopano-sift-c you might want to experiment with ransac: for fisheye lenses don't use it. For normal lenses you might experiment by adding --ransac 1 to the parameters. Note: Don't forget to set a default generator otherwise your assist panel will no longer work. Please test and give some feedback. Information and binaries via my website http://panorama.dyndns.org/index.php?lang=ensubject=Hugintexttag=Hugin. (The binaries itself are, as always, served from hugin.panotools.org who kindly provide the disk space and bandwidth). 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: Aerial Photography Stitching
2009/9/21 Lukáš Jirkovský l.jirkov...@gmail.com: First, there are some new tilt options to the panorama tools (Tx, Ty, Tz and Ts) but doesn't use them yet. I've had a look through the archives and I see that the options you mention could indeed be very useful. What version of Hugin are these likely to turn up in? I don't mind building from source but I'd like to know which branch to get. Or should I just grab trunk? I'd try to load map into hugin and manually add control points to photos and corresponding parts of map. Then optimize with map set as anchor image. This would hopefully transform images to fit map directly in hugin. And for stitching I'de disable the map so it doesn't blend with photos by coincidence. Yes, that's what I've been doing so far but I'm unable to stitch together more than about 3 images before it significantly deviates (as in ~20 ground distance) from the map. The tilt options should help with this, even if they don't allow me to stitch any more together at once but only allow the images to be more accurate. Really for our purposes, accurately conforming to the ground truth is more important than seamless blending or colour balance (though they would help). -- Matt Williams http://milliams.com --~--~-~--~~~---~--~~ 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: Aerial Photography Stitching
Hi Matt, The general workflow for proper orthorectification (as used by the professionals) is: 1. Measure some ground control points (GCPs) in the images. These associate an image point with a 3D world position (lat, lon, height). If a full bundle adjustment is used, this is not needed for every images as tie points (called control points in hugin) can also be used. These are usually measured against maps, orthoimages, gps traces. The height is often derived from the SRTM dataset, or from high precision GPS measurements with post processing at specific corner (centre of roundabouts etc.). 2. With the GCPs and tie points, the position and orientation of each photo is estimated using bundle adjustment. This works a bit similar to what hugin/panotools does, but it solves for full 3D geometry. 3. Orthorectification is preformed using the estimated positions and orientations and a digital terrain model. If there is a lot of overlap in the photos, the terrain model can also be computed from the photos itself (This is actually what I currently do in my day job). All data that is required for this is freely available. You can use well traces streets in OSM for establishing the ground control points in step 1). The SRTM model required for orthorectification is available in the public domain (at least for areas south of 60° northern latitude). The main problem is that there is no complete open source software package for this job. All the components are available in various software packages, but they are not integrated: - Tie points can be created in hugin or with other matching software. With a bit of scripting, GCPs can be derived from tie points measured against OSM maps (its just coordinate transformation and lookup in the elevation model). - A complete package that takes care of most steps required for 1) and 2) is bundler, http://phototour.cs.washington.edu/bundler/ however, this is not designed to handle ground control points, so it won't give you absolute coordinates. It uses a customized version of SBA http://www.ics.forth.gr/~lourakis/sba/ for the bundle adjustment. SBA recently been extended so that it supports both tie points and ground control points. - Orthorectification can be done using open source remote sensing software packages such as http://www.ossim.org or http://www.orfeo-toolbox.org. However, these packages are mostly designed for handling commercial satellite and aerial imagery, and I'm not sure if the support a simple camera model. Then there is e-foto, which I have just downloaded as tried, but I didn't manage to do something useful with it. So the correct way to produce nice orthophotos as shown by the map providers is not that simple using open source software, and needs quite some gluing together of several packages. Hugin is currently not really suited for aligning all your images. However, the latest work in panotools (as mentioned in the reply by Lukas) might help if your area is reasonably flat. The new parameters Tx, Ty and Ts parameters in panotools should allow you to orthorectify your images to a plane. As these are are very new, they are not supported in hugin yet. This means that you need to use the panotools script interface from the command line directly. Maybe the following procedure might work (disclamer: I haven't tried anything of that myself!): 0. Get and compile the current trunk of libpano13 1. Load a few overlapping images captured from different viewpoints (maybe start with 3 or so) into hugin, and create a few good control points between them (make sure that they are good, to avoid confusion due to mismatched control points later on). Try to load a very well downwards looking image as first image. This image will define the plane to which the other images are warped later on. Do not optimize yet. Make sure that the field of view of the images is reasonably correct. (Computation from EXIF data is probably good for the first try). 2. Set the projection to rectilinear, and choose a wide HFOV and VFOV, such as 90 degrees or so. Press the compute optimum size button. 3. Export everything as panotools compatible project. The 100% bulletproof way is to go to the optimisation tab, tick the edit script before optimisation (or similar) checkbox, press Optimize and select the text of the checkbox and save it into a textfile named optimize.txt 4. Now you need to select which variables to optimize, using by adding them to the v line in optimize.txt. I would try optimizing roll, pitch, yaw and Tx, Ty, Ts for all but the first image. Run $ PToptimizer optimize.txt to perform the optimisation. Check the file to see some information about the errors. Here some trial and error with different parameter sets is probably needed. 5. Test remapping the images with PTmender: $ PTmendler optimize.txt 6. Combine the without any blending using PTroller $ PTroller -o output.tif remapped1.tif remapped2.tif
[hugin-ptx] Re: Hugin-2009.2.0_RC1 source code distribution released
Hullo Yuv, On Sep 21, 12:10 pm, Yuval Levy goo...@levy.ch wrote: Panorama stitching and more. A powerful software package for creation and processing of panoramic images. hugin-2009.2.0_RC1 (release candidate 1) tarball is available here: https://sourceforge.net/projects/hugin/files/hugin-2009.2_beta/hugin-... This is a release candidate and may be declared final in the coming days. I have successfully built RC1 and done some limited testing on Fedora 11 x86_64, and thus far all seems OK. Hugin 'about' reports svn 4461. I have also successfully built (using mock) a fedora 11 i586 version. I will pass these binary packages to Bruno so he can put them on his server for all to access. The packages are... hugin-2009.2.0-0.1.20090921svn.fc11.x86_64.rpm hugin-base-2009.2.0-0.1.20090921svn.fc11.x86_64.rpm hugin-2009.2.0-0.1.20090921svn.fc11.i586.rpm hugin-base-2009.2.0-0.1.20090921svn.fc11.i586.rpm Cheers, Terry --~--~-~--~~~---~--~~ 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_RC1 source code distribution released
Hi Terry, Tduell wrote: I have successfully built RC1 and done some limited testing on Fedora 11 x86_64, and thus far all seems OK. thanks for the good news! 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] Enblend: CMake (Windows) broken
The CMake error, at line 33 of src/CMakeLists.txt says: set_target_properties called with incorrect number of arguments this is unrelated to Christoph's recent changes (rev. 524+) - it happens already in rev. 523. 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: Aerial Photography Stitching
Pablo d'Angelo wrote: Hi Matt, The general workflow for proper orthorectification (as used by the professionals) is: 1. Measure some ground control points (GCPs) in the images. These associate an image point with a 3D world position (lat, lon, height). If a full bundle adjustment is used, this is not needed for every images as tie points (called control points in hugin) can also be used. These are usually measured against maps, orthoimages, gps traces. The height is often derived from the SRTM dataset, or from high precision GPS measurements with post processing at specific corner (centre of roundabouts etc.). Sorry, this was confusing. This is a better explanation: Tie point are measured between the images, Ground Control points are measured between the image and some reference data (maps, gps traces, digital elevation models, geodetic gps measurements etc.). 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] Re: Enblend: CMake (Windows) broken
Am Tuesday 22 September 2009 schrieb Yuval Levy:
The CMake error, at line 33 of src/CMakeLists.txt says:
set_target_properties called with incorrect number of arguments
I only see this line in enblend's cmake.
It looks like OpenMP_CXX_FLAGS were not defined. Could you please check
CMakeCache.txt for a similar variable (mybe only difference in case)
Anyway it sholud read like:
if(OpenMP_CXX_FLAGS)
set_target_properties(${_cmd} PROPERTIES LINK_FLAGS ${OpenMP_CXX_FLAGS})
message(STATUS Adding PROPERTIES LINK_FLAGS to ${_cmd})
endif(Boost_FOUND)
The output of running cmake should give you an indication of the value of
OpenMP_CXX_FLAGS
And it seems to be _my_ doing.
this is unrelated to Christoph's recent changes (rev. 524+) - it happens
already in rev. 523.
Yuv
Could you please try?
Kornel
--
Kornel Benko
kornel.be...@berlin.de
signature.asc
Description: This is a digitally signed message part.
