[hugin-ptx] Re: hugin plugin interface - developers please liaise
Hi Kay Your solution absolutely does the trick. I'm no good at cmake, and seeing what you did with it I'm duly impressed. I feel this is a nice and clean solution now; it worked on my Ubuntu system, just a tiny error in CMakeLists.txt - the directive for the gcc preprocessor is -E and not /E. And all automatic, as it should be! Well done :-) Nice to hear that it works also on unix. I fixed the minor error. Thomas -- 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] BEBUG_WARN, cerr and Python
Hi all! I have a problem with hugin outputting data to cerr when I use it from Python, but it may point to a general problem. Hugin uses a set of macros to produce warning and error output when in debug mode. Recently I've experienced two occasions when these macros weren't made dependent on the setting of the DEBUG define but just activated anyway; currently this is the case in src/hugin_base/hugin_utils/ utils.h., line 87-94.This wouldn't be a great problem, if the output to cerr didn't crash Python when it uses hugin or other programs linking to libhuginbase.so the very moment the first string is out. Assume the C++ code does something like cerr WARN: blah blah endl ; All I get to see in Python is WARN: Speicherzugriffsfehler (that is, memory error.) - so I get to see the first string 'WARN:' but then the crash happens, which looks like an error in cerr.operator(). The strange thing is that this only occurs with output to cerr, cout is unaffected. Does anyone have any ideas if maybe something is done to cerr which is incompatible - like some evil trickery to make it do things it's not supposed to? I've managed to reduce the problem to the linking in of libhugin.so - If I run an ordinary C++ program from Python as a subprocess, using cerr is just fine, even mixed with stdio routines, but as soon as I link in libhugin.so, the call to cerr shows the erroneous behaviour. For now, I'll modify utils.h back to only do output when DEBUG is set. I'd be grateful if, whoever unleashes the DEBUG_ macros outside DEBUG mode would only do these changes locally. Any ideas about the cerr problem would be welcome, though, because there definitely is a problem, and just avoiding it isn't a good strategy. Kay -- 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: BEBUG_WARN, cerr and Python
On 23 Jan., 11:09, Pablo d'Angelo pablo.dang...@web.de wrote: Hmm, not sure about that. Maybe some problems with static initialization and linking order? Does the problem also occur for a small dummy extension (thus running in the same process as python) using c++, or does it only occur from within hugin? It doesn't even have to be an extension. It's enough if the program uses libhuginbase.so and if it's started by python as a subprocess. If that helps, I can put a demo online. Kay -- 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: BEBUG_WARN, cerr and Python
On 23 Jan., 11:19, kfj _...@yahoo.com wrote: It doesn't even have to be an extension. It's enough if the program uses libhuginbase.so and if it's started by python as a subprocess. If that helps, I can put a demo online. hmmm... tricky. Currently I can't reproduce the bug with a subproces, but it occurs with a small dummy module. I'll post again if I can be more precise. Kay -- 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
Re: [hugin-ptx] Re: Test case for cpfind
Hi Pablo, On January 23, 2011 02:45:55 am Pablo d'Angelo wrote: http://www.sendspace.com/file/vnek81 I tried the set with the following steps: Thanks. With assistant: 1. load images, set 14 mm rectilinear 2. align 3. straighten by drag in preview http://www.flickr.com/photos/vonengel/5379754185/ Without assistant: 1. load images, set 14 mm rectilinear 2. run cpfind (without multirow) 3. optimize pairwise, rpyvde, rpyvbcde 4. straighten by drag in preview http://www.flickr.com/photos/vonengel/5380355446/ Both seem to work fine. What problems did you encounter? Note: done with the latest hg version, 2010.4 wont work. I also used the latest hg version, thank you for the amazing improvements to cpfind. What I did not do is set the 14mm rectilinear. I just entered from the command line `hugin *.JPG` and hit align in the assistant. Michel's test/challenge was for this to work out of the box and I did not have time to investigate further. I realize now when running Exiftool that it reports 0mm focal distance; and that Hugin sets the focal length to 50mm by default, even if the exif data reported 0mm. Maybe we should change that and instead of assuming a default, ask the user? Thanks for testing Yuv signature.asc Description: This is a digitally signed message part.
[hugin-ptx] Re: Test case for cpfind
Hi Yuv, Am 23.01.2011 15:10, schrieb Yuval Levy: Michel's test/challenge was for this to work out of the box and I did not have time to investigate further. I realize now when running Exiftool that it reports 0mm focal distance; and that Hugin sets the focal length to 50mm by default, even if the exif data reported 0mm. Maybe we should change that and instead of assuming a default, ask the user? Actually, the exif data in these images is inconstent, and reports 0 and 50 mm, so hugin believes it is 50 mm... $ exiv2 IMG_0114.JPG ... Focal length: 50.0 mm ... $ exiftool IMG_0114.JPG ... Field Of View : 40.5 deg Focal Length: 50.0 mm (35 mm equivalent: 48.8 mm) Lens: 0.0 mm (35 mm equivalent: 0.0 mm) ... I fear that we can't really fix that. Long live EXIF. 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] [OSX] New hugin-mac-2010.5.0-4886:a1cb4a2efa65 incl. cpfind with new ransac and bugfixes
Hi mac users, Another Hugin build. It's going fast last 2 weeks. This one contains the enhanced cpfind with the new ransac mode for cpfind to improve CP detection for fisheye lenses. See Pablo's mail[0]. Note: I did not change the cpfind preferences. If you want to experiment you need to add the parameters yourself. From cpfind: --ransacmode string Ransac : mode (auto, hom, rpy, rpyv, rpyvb (default : auto) Note that I can't add much as this is completely new to me as well. Next to that I don't have a fisheye lens. Again: Read Pablo's mail for hints. And this build also contains, like mentioned in my previous mails (but things move so fast lately): - The Thoby projection (like the previous build) - The gsoc 2010 panorama overview - The new flann enhanced cpfind. This should make cpfind even better. Default cpfind settings remain the same AFAIK and tested. - bugfix for cpfind for fisheye lenses. If you find a bug, please register it in the hugin bugtracker [1]. Anything else: please report it to this mailing group. This is again a triple architecture (i386/x86_64/ppc) univeral build As always: Information and binaries via my website http://panorama.dyndns.org/index.php?lang=ensubject=Hugintexttag=Hugin. (The binaries themselves are served from hugin.panotools.org who kindly provide the disk space and bandwidth). Hoi, Harry [0]: http://groups.google.com/group/hugin-ptx/browse_thread/thread/1f2f441d35598cbe?pli=1 [1]: https://bugs.launchpad.net/hugin -- 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
Re: [hugin-ptx] Re: clustered hugin
On Sun 23-Jan-2011 at 07:29 +0100, Pablo d'Angelo wrote: A good option for clustering would be to split the panorama in many smaller parts (tiles, using the crop feature of hugin), and distribute these. gigatile is an experimental tool for doing this, it splits the Hugin .pto project into 4096x4096 regions for separate rendering and manages the remapping and blending with a Makefile. This only uses a small amount of memory whatever the panorama size and should work well with distributed processing: http://search.cpan.org/dist/Panotools-Script/bin/gigatile There might be some artefacts near the boundaries, so rendering overlapping tiles is probably better. gigatile doesn't do this overlapping, I didn't have a need for it, so you do get these artefacts at the tile boundaries which may or may not be a problem depending on your subject. -- 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
Re: [hugin-ptx] Re: cpfind ransac mode
On Sat 22-Jan-2011 at 23:57 -0800, kfj wrote: In theory this is a fine idea. But keep in mind one point that noone ever adresses in this whole discussion: The treatment of FOV in hugin is, if I am interpreting the mechanism right, fundamentally flawed. The only thing that is asked for and processed seems to be the HORIZONTAL field of view. Now if I make images with an APSC sensor and, in landscape mode, have a HFOV of 60 degrees, then do some shots in portrait, suddenly the HFOV is 40 degrees. It doesn't really work like this. Hugin looks exclusively at the image dimensions, so both the landscape and portrait shots will have the same lens number and field of view. If you have actually rotated the pixels of one photo in an image editor then Hugin will see two different lens numbers and field of views, but the field of view will be 'correct' and doesn't need to be changed to get a good stitch. -- 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
