[hugin-ptx] Enblend encountered degenerate image/mask geometry
Dear mailing list, sorry for being a pest, but this issue is blocking more and more of my panoramas. (See also "enblend oddity" thread.) I keep running into the issue that enblend determines that my seam lines are defective, triggering the check in mask.h:969. What exactly is causing isolated points in images? I included a minimal example again, 2 images which can be found here: https://airesearch.de/files/staticimgs/enblendProb/example.zip enblending them gives the following output: $ enblend -o result.tif --compression=DEFLATE -f101957x17605+4588+1257 image0.tif image1.tif enblend: info: loading next image: image0.tif 1/1 enblend: info: loading next image: image1.tif 1/1 enblend: encountered degenerate image/mask geometry; too high risk of defective seam line Now, it could be my input images, as some other panoramas work fine. How can I set the black-alpha-mask-check-isolated-points-threshold parameter? I'd like to see the masks generated, which I obviously can't, as no output is created. Or, it could be a bug somewhere. If you reverse the order of the two images, everything works. Doesn't that indicate a bug? Help me, hugin mailing list, you're my only hope. Best, Benjamin -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/a212e820-e9f5-4a78-95c6-e1d8b9b80c1b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: Enblend oddity
Hrrmmm, I'm in a committed long-term relationship with enblend, but seeing that it can't fulfil my needs right now, I had a quick flirt with multiblend works! Most of the images have good overlap and no parallax/moving objects anyway, so hardly any blending was necessary. Interesting. Was just about to write that re-ordering didn't work, but wasn't sure if I tried all combinations. Yes, in a certain order, it blends without problems. Maybe that's worth filing a bug report for...? (Also, I should add a feature request for multiblend: support deflate compression ...) Thanks! You saved my pano. :) Best, Benjamin Monkey wrote: Are you wedded to enblend? multiblend would have no such issues, and actually does blend, not just assemble, disconnected images. Alternatively, have you tried reordering the images? Rename testing0002.tif to testing.tif and vice versa. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/1aac2933-c16c-dd8b-7b08-bd66c8cbe3d3%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Banding artifacts
Hi Terry, I had the same problems with the default-enblend from the Ubuntu repos. I built it myself to get a multithreaded/GPU accelerated version - but the problems persisted. (Plus the image cache version produced the good old horizontal black lines again.) I uploaded a testcase to http://airesearch.de/files/static/testcase_hugin.zip - low quality jpeg files, shows the same artifacts as in the previous message with my setup. My wild guess would be that the photometric optimization doesn't work (as desired) for my images... 2014-09-18 2:27 GMT+02:00 Terry Duell tdu...@iinet.net.au: Hello Benjamin, On Thu, 18 Sep 2014 09:23:38 +1000, Benjamin Schnieders benjamin.schnied...@gmail.com wrote: Dear Hugin community, after a two year absence, I returned to shooting panoramas. However, things have changed. I can't get Hugin/enblend to merge my pictures seamlessly. I attached two images, one being prior photometric optimization - sure, my lens has a bit vignetting, so vertical banding artifacts are to be expected. Then, after photometric optimization (tried it in different ways), at best a result like in the second image is achieved. I remember that Hugin / enblend used to deal with such minor brightness deviations easily - I also tried several enblend options (including the much discussed --no-ciecam) but with not much changes. Hugin version 2013.0.0.4692917e7a55 from official Ubuntu repos, enblend enblend 4.2-e4d6ae9dfe83 selfbuilt. Any ideas what I'm doing wrong and what I could try? All my current panoramas seem to suffer from photometric optimization difficulties... Same difficulties with all panos stitched with Hugin version 2013.0.0.4692917e7a55 and enblend 4.2-e4d6ae9dfe83, or have you had the same problem with other versions/builds of enblend? Is is possible to make a set of images and the .pto file available for one of your smaller projects so we can see if the problem can be reproduced? On Dropbox or similar. Cheers, -- Regards, Terry Duell -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ ---You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/hugin-ptx/op.xmcwwbj8rs0ygh%40localhost. For more options, visit https://groups.google.com/d/optout. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAFfh8fSaRU2nGuFinEdgWZqZDvabEhZOw5EHLAFJy_F6O2qgQQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Banding artifacts
Oh. Thanks Thomas. I don't know how I could miss that. Yes, apparently ufraw performs a lens correction now and introduces black borders to each image by default. Thanks for your time, and good light :) Benjamin T. Modes wrote: Hi Benjamin, The problem with your testsets are the black borders in your input images. I assume you have correct the lens distortion with another program, but the corrected images does not contain an alpha channel, which marks the pixels without information. So the images contains black borders which results in the effects you observed. There are 3 possible ways to fix this: 1.) Add a crop to all images to crop the black borders in Hugin (on the masks tab) 2.) Check the settings of your program for lens correction. Export the images to a format with supports alpha channels (or transparency). JPG does not support alpha channels. 3.) Input the uncorrected images to Hugin. Hugin can also do the lens correction in the same run as remapping the images for the pano. This will yield to a better result, because the pixels needs only one time to interpolated (instead of twice as in your current workflow: one time for lens correction and one times for pano remapping). Thomas -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups hugin and other free panoramic software group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/541B596A.4070800%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Re: hugin/panotools/align_image_stack for astronomical images
Hi John, It sounds like the first image is extremely different from the last image, so I'm thinking align_image_stack will not really work (Bruno or others can say for sure.) Are you trying to make an image of a particular star or group of stars? In either case, using all 1000 images, the area of interest (in common to all images) is presumably a small portion of any one image and this area of interest needs to appear in all 1000 images. I assume you might want to partially *add* the images rather than just average them? Or do you just want to enfuse them to remove noise and enhance saturation? Did you take any dark slides? (I'm probably a bit out of my depth on these last questions.) Yes, the whole idea is to reduce the sensor noise. We'll see if enfuse does a better job than a simple average... However, the overlap region of all images will be quite small, I'd like to keep the whole area, simply with enhanced SNR in the overlapping regions. I have taken a few darkframes, probably not enough for a decent result (it was a pretty quick action, and it was late at night) A way around the limitation (my assumption) of align_image_stack might be to break the images into sequential groups of say 25 or 50 (0-49, 50-99, etc) and use align_image_stack on each group (the program should be able to handle the much smaller stacking differences in each group.) Then you can process each group separately. Finally you can take the sharper clearer processed stacks and process them together. I think this would be just as fast (or faster) and just as easily automated You might need to do some manual cropping and/or process use cpfind rather than align_image_stack on the second set. Another possibility is to make interleaved stacks (0-49, 24-74, 50-99, etc. Yep, already thought of that. Using the complete imageset for testing simply takes too much time, so I tested everything with the first 50 frames. Unfortunately, even those 50 images are heavily blurred when averaged after aligning. Maybe the best thing would be to look at similar OSS that is specifically designed for this. It's probably already solved all these problems and has been optimized for the task. I don't remember the name of the software, but I know it exists. I'm sure Google will be helpful ;-) Yep, there's immix, for example, that was already proposed in the mailing list here. Then again, technically the panotools should be capable of exactly what I need :) And what does this have to do with pinhole photography ? ;-) Must have been the email I was reading when answering to the group :) I don't see those 2 linked anyhow, what's the effect? Best regards, Benjamin -- 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] hugin/panotools/align_image_stack for astronomical images
Hi all, I need your help aligning some images :) I have a sequence of 1000 night sky images taken with just a tripod, so alignment is needed before averaging them. The align_image_stack workflow does not seem to work properly for me - the resulting images are aligned, but not very accurately, so that averaging them results in a blurry mess. Checking what went wrong, it seemed that align_image_stack did not find 2 control points for each consecutive pair of images, but keeps on stacking photos. When adding proper points, the result is better, but far from acceptable. Another issue was the seemingly added-up error - I manually placed control points between the first and last image, which seemed to lower the blur by about 50%. Now, manual work is acceptable for smaller image sets, but I wished to fully automate the process for the full 1000 picture series. Thus, a couple of questions: - What would be appropriate settings for align_image_stack to detect more/better control points? I already use -s 0. - Can I tell align_image_stack to search for control points between all combinations of images? I know this will take a while - What settings would be needed that align_image_stack can detect control points that move about half of the image's width? Concerning the latter two points, I might rather use cpfind - unfortunately, I have not yet figured out a way to let cpfind find any control points on stars. - What would be appropriate settings for cpfind to detect control points on pictures of stars? I already tried to use --fullscale. - Can I easily use either cpfind or align_image_stack from a script to create control points in a pyramid-like manner (meaning, between 0-1-2-3-4..., 0-2-4-6..., 0-4-8-12..., 0-8-16-24,.) (to minimize added up error and to keep CP count comparatively low) - Can I force align_image_stack or cpfind to connect each image to the rest with at least 3-4 good control points, or die? So far for now, happy to hear any recommendations :) Thank you, Benjamin -- 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] Introducing Pannellum - an HTML5 Panorama Viewer
Hi Matthew, great work! :) Linux, Ubuntu 64 and SeaMonkey (some kind of Firefox) 2.9.1 - no problems. I wonder, however - how large may the panoramas become, before it gets laggy (or browsers crash)? For example, I don't know a browser displaying a half-a-gigapixel image directly, so that'd be at least one limitation... Benjamin Matthew Petroff wrote: After a year of on and off development, Pannellum, a free and open source panorama viewer for the web, is ready for release. Built using HTML5, CSS3, JavaScript, and WebGL, it is plug-in free. The lightweight viewer, just 18kB gzipped, can be deployed using a single file and displays full equirectangular panoramas. One can easily embed panoramas in web pages as an iframe, using code generated by the included configuration utility. For more information and an example, see: http://www.mpetroff.net/archives/2012/05/28/introducing-pannellum/ Or the project page: https://bitbucket.org/mpetroff/pannellum/ I've tested it across a range of browsers, but I'd appreciate any feedback or bug reports. -Matthew -- 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] nona-gpu and stereographic input projection
Bruno Postle wrote: Yes, nona-gpu implements the projection code independently of libpano13 and hasn't kept up with things like stereographic input. Good to know. For unknown output projections, nona-gpu issues a warning that the projection type is not supported, and falls back to plain nona. Shouldn't it behave the same ways for unknown input projections then? Benjamin -- 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] Panorama of a threedimensional object
gms76 wrote: Hello, I tried to make a panorama of some photos, which were taken inside a tube. To make the photos, the camera moved lateral. The problem is, that due to spatial distortion lines which are painted on the wall of the tube have a pincushion distortion and hugin cannot connect them. The reason for this extreme pincushion distortion is, that the wall of the tube is concave and I change the position of the camera in the longitudinal direction of the pipe. Is it possible to make a panorama of this pipe? Thank you for your help, Georg Hi Georg, I assume you want to take a panorama of the inside of a subway tube, or similar? You are right, the three-dimensionality of the motive renders hugin unable to correct the distortion here. Hugin has no idea of the underlying three dimensional objects, and, in mosaic mode, will try to fit the images on a plane. The only way I know to improve your image is by taking an huge amount of pictures, then only using a few center pixels from each image. The more detail in the third dimension, the more images you will need... Benjamin -- 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] How to prevent nona from opening windows with -g for GPU?
Another possibility might be to run it as a different user - but I'm not sure if the graphical context is created then. Maybe one can share the context from one program to nona - starting a graphical context server, which just opens the window once and allows nona to access it. GPU-enhanced enblend also opens another window, but that is way less annoying, as it is just created once. Or build in a batch-mode for nona - but that'd violate the one tool does exactly one thing rule under linux... Benjamin Jan Martin wrote: Just tried MetaCity window-matching utility http://burtonini.com/blog/computers/devilspie/ with gdevilspie http://code.google.com/p/gdevilspie/ graphical editor. Unfortunately while it moves the nona windows to another workspace, it only does so AFTER they pop up. Still a lot of annoying flickering. Just faster. Jan -- 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] How to prevent nona from opening windows with -g for GPU?
Jan Martin wrote: Hi all, when using nona -g for GPU support, nona opens an empty window per source image. Is there any way to stop this? It just flickers, and the focus changes to those windows and the PC becomes unusable. Thanks, Jan -- http://www.DIY-streetview.org Hi Jan, which OS are you using? On Ubuntu (should be the same for all Linux distributions using Gnome with Compiz), I added window rules in CompizConfig like No focus = title=^nona$ - makes the nona window unfocusable. Add some more and the window won't annoy you any more. Of course, this wont help for any other OS... Benjamin -- 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] Use of hugin for a sports shot combining 5 shots from a snowboarder jumping
How exactly are include area masks applied? From short tests, I assume that this region is simply masked/not used from all other pictures. (Which would then lead to empty/black spots on 2 overlapping include area masks) This is also a bad idea for exposure stacks, which I had some trouble with. Can someone put more light on this issue? Thx, Benjamin -- 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] segfault in enblend/vigra
Hi all, recently I discovered a segfault in enblend. It is a fairly big project, so i can not *simply* provide input images or the whole core dump, but here's a stacktrace: #0 0x004dc928 in void vigra::read_bandsvigra::Diff2D, vigra::MultiImageVectorMaskAccessor4vigra::BasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , vigra::BasicImageIteratorunsigned char, unsigned char**, vigra_ext::WriteFunctorAccessorvigra::Thresholdunsigned char, unsigned char, vigra::StandardValueAccessorunsigned char , unsigned char(vigra::Decoder*, vigra::Diff2D, vigra::MultiImageVectorMaskAccessor4vigra::BasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , vigra::BasicImageIteratorunsigned char, unsigned char**, vigra_ext::WriteFunctorAccessorvigra::Thresholdunsigned char, unsigned char, vigra::StandardValueAccessorunsigned char , unsigned char) () #1 0x00522de8 in void vigra::importVectorImagevigra::Diff2D, vigra::MultiImageVectorMaskAccessor4vigra::BasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , vigra::BasicImageIteratorunsigned char, unsigned char**, vigra_ext::WriteFunctorAccessorvigra::Thresholdunsigned char, unsigned char, vigra::StandardValueAccessorunsigned char (vigra::ImageImportInfo const, vigra::Diff2D, vigra::MultiImageVectorMaskAccessor4vigra::BasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , vigra::BasicImageIteratorunsigned char, unsigned char**, vigra_ext::WriteFunctorAccessorvigra::Thresholdunsigned char, unsigned char, vigra::StandardValueAccessorunsigned char ) () #2 0x00523663 in void vigra::importImageAlphavigra::BasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , vigra::BasicImageIteratorunsigned char, unsigned char**, vigra_ext::WriteFunctorAccessorvigra::Thresholdunsigned char, unsigned char, vigra::StandardValueAccessorunsigned char (vigra::ImageImportInfo const, std::pairvigra::BasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , std::pairvigra::BasicImageIteratorunsigned char, unsigned char**, vigra_ext::WriteFunctorAccessorvigra::Thresholdunsigned char, unsigned char, vigra::StandardValueAccessorunsigned char ) () #3 0x00523815 in void enblend::importvigra::BasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , vigra::BasicImageIteratorunsigned char, unsigned char**, vigra::StandardValueAccessorunsigned char (vigra::ImageImportInfo const, std::pairvigra::BasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u const, std::pairvigra::BasicImageIteratorunsigned char, unsigned char**, vigra::StandardValueAccessorunsigned char const) () #4 0x0055da47 in std::pairvigra::BasicImagevigra::RGBValueunsigned char, 0u, 1u, 2u, std::allocatorvigra::RGBValueunsigned char, 0u, 1u, 2u *, vigra::BasicImageunsigned char, std::allocatorunsigned char * enblend::assemblevigra::BasicImagevigra::RGBValueunsigned char, 0u, 1u, 2u, std::allocatorvigra::RGBValueunsigned char, 0u, 1u, 2u , vigra::BasicImageunsigned char, std::allocatorunsigned char (std::listvigra::ImageImportInfo*, std::allocatorvigra::ImageImportInfo* , vigra::Rect2D, vigra::Rect2D) () #5 0x005c1119 in void enblend::enblendMainvigra::RGBValueunsigned char, 0u, 1u, 2u (std::liststd::string, std::allocatorstd::string const, std::listvigra::ImageImportInfo*, std::allocatorvigra::ImageImportInfo* const, vigra::ImageExportInfo, vigra::Rect2D) () #6 0x00476396 in main () enblend version is $ enblend --version enblend 4.1-cd12da20db1a Recent version of the Ubuntu PPA. Solved the issue for myself by splitting the project up to 4 smaller images, then manually blending those in gimp. Is it just a memory issue? But then I'd prefer a bad_alloc over a segfault :) Can I provide further information to solve the bug? Thx, Benjamin -- 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
Re: [hugin-ptx] Re: Announce: Enblend/Enfuse version 4.0 - Final Release
on SeaMonkey 1.1.x, the whole top menu is shifted about a page width to the right - the background image is loaded, but not shown. (see http://img684.imageshack.us/img684/3000/screenshotbc.png ) [0] http://enblend.sourceforge.net -- 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/Enfuse 4.0 dev snapshots
Hi Chris, First of all CPU load is a silly measure.[...] For a user only wall-clock time matters. sure. I did not yet take times, but the new version is definitely faster than the old one. Of course 3 busy-waiting cpus and only one doing something useful will stress a 4-core cpu the same as 4 useful threads - the same in 'top', different wall clock time. Second, read about Amdahl's law http://en.wikipedia.org/wiki/Amdahl's_law It matters. I know Amdahl's law, (good old parallel programming lectures) but I thought enblends work was somewhat simpler to split up than it seems. The current implementation does _not_ scale well beyond two processors. The reasons for this are yet unknown. You are welcome to run Enblend with your favorite profiler, identify the bottleneck(s), and send me a bunch of patches that rectify the congestion. Can you propose a (free) multi-thread profiler for linux? (Looking out for one for some time now...) If so, I'll have a look at it, enough of exploiting hugin/panotools now, time to give something back ;) IMO, you did nothing wrong. My results are similar. Fine :) I will check later how much faster enblend has become. I'm missing the output which image is processed (or, is finished being processed) a little... Thanks for reply :) Benjamin --~--~-~--~~~---~--~~ 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/Enfuse 4.0 dev snapshots
Hi all, just trying a selfcompiled v4.0 - stitching a pretty big project now. Inspecting the enblend run with top I see that indeed enblend sometimes uses more than 100% cpu - but never more than like 200%, usually it is around 100% and from time to time there is a peak using somewhat more. As I have a quadcore and I see it is perfectly used up by nona I'm a little disappointed about enblend - was this a malconfiguration? enblend verbose version info tells me: enblend 4.0-b93c2aed500d Extra feature: dmalloc support: no Extra feature: image cache: no Extra feature: GPU acceleration: yes Extra feature: OpenMP: yes - version 2005-5 - support for nested parallelism - support for dynamic adjustment of the number of threads - using 4 processors and up to 3 threads Is this the up-to date version or id I compile something wrong? Thanks :) Benjamin --~--~-~--~~~---~--~~ 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] nona-gpu and multicore?
Hi all, just read that nona-gpu was integrated in the trunk, and already a question about it: Will the gpu-feature work with multiple threads? Or, what is the tradeoff between using multiple threads (in my case, 4) of nona vs. nona-gpu? Just thinking, it'd be stupid if nona-gpu is like 100% faster, but 3 threads are waiting for the fourth to complete... Or, in this case, can the gpu-feature be enabled for one thread only? Questions, questions, ... ;) Benjamin --~--~-~--~~~---~--~~ 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: blending artifacts, weird output crash
Bruno Postle wrote: The previous reports for this bug suggest that it happens when the width of the output is greater than 32768 pixels. It would be useful to prove or disprove this. ACK, unfortunately no - none of the 2 versions had the same errors as the large one. Some interesting tests would be to: Try again with the output at 47543x100. 100 was too small, I chose 1000 instead - perfect stitch, no problems. Try with the width at 32000 then at 33000. Done. Unfortunately, both don't have the old stitching errors, but instead an interesting new one... http://astrobenja.de/staticimgs/32and33.png (that wouldn't be a problem, Gimp can fix it, but still...) Roll the panorama 90° using the numeric transform in the preview and stitch a 8381x47543 panorama instead. Yet to be done. I assume, not in cylindrical projection? ;) make: *** [yotest.tif] Killed make: *** Datei »yotest.tif« wird gelöscht Seems that something external stopped the process, maybe an oom killer? AFAIK I don't have such a thing, 16gb ram + 10gb swap should be enough anyway... And if the hard disk is full usually enblend stops with can not write to file, and leaves a HD with 0 byte free memory ;) http://astrobenja.de/staticimgs/pos.png . This looks ok? Certainly looks different from the rest, as all the others are cropped around the actual image region, only this one and few others are not... That looked strange to me. More tests I can do? I'll try another with enblends default settings (without -l 29 and --fine-mask) but I'm not even entirely sure that enblend is the problem... Thanks so far, Benjamin --~--~-~--~~~---~--~~ 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: blending artifacts, weird output crash
Bart van Andel wrote: http://astrobenja.de/staticimgs/pos.png. This looks ok? Certainly looks different from the rest, as all the others are cropped around the actual image region, only this one and few others are not... That looked strange to me. This is perfectly valid for 360 degree panoramas. The images at the 360 degree 'seam' will break into two parts: one part to the far left of the temporary image, and one part to the far right. Thanks, good to know :) I solved it! First disabled both -l 29 and --fine mask, result looked good, so I tried another time, only removing --fine-mask. Needless to say, the stitch is much faster without, and (!) all artifacts are gone. Strange As there is this other little bug around that can only be fixed with enabling this option ;) So thanks again you two, Benjamin --~--~-~--~~~---~--~~ 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] where to find settings file for hugin?
hi all, just moved to a 64 bit machine, copied my old home folder over and compiled hugin, all went fine until i wanted to execute: a...@abdesktop64:~$ hugin Xlib: extension GLX missing on display :0.0. Xlib: extension GLX missing on display :0.0. MainFrame::RestoreLayoutOnNextResize() ERROR: 01:58:32.880283 (/home/ab/hugin_compile/hugin/src/hugin1/hugin/huginApp.cpp:304) OnInit(): Tempdir could not be created: /media/Linux/huginTemp ERROR: 01:58:32.880382 (/home/ab/hugin_compile/hugin/src/hugin1/hugin/huginApp.cpp:308) OnInit(): could not change to temp. dir: /media/Linux/huginTemp Segmentation fault a...@abdesktop64:~$ cd /media/ a...@abdesktop64:/media$ sudo mkdir Linux a...@abdesktop64:/media$ cd Linux/ a...@abdesktop64:/media/Linux$ sudo mkdir huginTemp a...@abdesktop64:/media/Linux$ hugin Xlib: extension GLX missing on display :0.0. Xlib: extension GLX missing on display :0.0. MainFrame::RestoreLayoutOnNextResize() Segmentation fault ... i think everything will be fine if i can just reset all settings ;) but where can i find that file? (almost crawled through my whole home folder now...) thx :) Benjamin --~--~-~--~~~---~--~~ 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] Fusing before or after
Bruno Postle wrote: On Tue 26-May-2009 at 22:54 +0200, Benjamin Schnieders wrote: but everything align_image_stack can give me is a complete .hdr, (which is, as far as i know, bad input to enfuse) a set of remapped images (which i don't need as i want to remap them later, aligned in total) or a pto file that holds information about the image offsets. seems that the latest is just what i need, but then, is there a method of merging these pto files together in a way that the images will stick together? Yes, you could use ptomerge (from Panotools::Script) to join all the projects created by align_image_stack with a project created by autopano-sift-c or panomatic. that worked fine, thanks :) as i saw, ptomerge did not recalculate the positions of the relatively oriented images, (just as i guessed) but instead added all the control points holding the stacks, that's fine as well. test worked out nicely, now my 84-image-pano of a nighly power plant will be next (looking forward to it :)) i wrote some scripts to ease the extraction of different levels of 8-bit pngs from 14-bit raws, then creating ptos for each stack, i think panotools-script could be enhanced with scripts like these (mine are definitely not for other eyes, because of the code quality ;)) This is exactly what the match-n-shift --stacks option does (also from Panotools::Script). i.e. something like this in the hugin preferences should do what you want: AutopanoExe=match-n-shift Args=-b -a -f %f -v %v -c -p %p -o %o % i will also give that a try, last time i built hugin was without match-n-shift, so next time my cpu is idle i will try it... thank again, Benjamin --~--~-~--~~~---~--~~ 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] Fusing before or after
hi all, actually i'm having a problem with exactly that question right now. i have a series of image stacks i'd like to stitch and fuse, so stack1_0 .. stack 1_6 until stack7_6. the thing is, the images are pretty dark, so automatic control point generation does a very bad job using all the images. align_image_stack however manages to align my stacks pretty well (they are shot with a bad tripod, so a little alignment is needed) but everything align_image_stack can give me is a complete .hdr, (which is, as far as i know, bad input to enfuse) a set of remapped images (which i don't need as i want to remap them later, aligned in total) or a pto file that holds information about the image offsets. seems that the latest is just what i need, but then, is there a method of merging these pto files together in a way that the images will stick together? to get proper results, atm i only see one solution: - take the brightest set of images, generate control points, align them - starting from the brightest image, use align_image_stack to align each whole stack to a .pto file - manually add up the translations calculated by align_image_stack to all further images and insert them into the big .pto from the beginning - run enfuse and enblend. definitely not the best way. are there scripts oder other tricks that will help? thanks, Benjamin --~--~-~--~~~---~--~~ 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] enfuse on n16bit vs n*2 8bit images
Hi all, i read about the basics of enfuse and how it works, from what is written on the website i expected the same result for, say, 3 16 bit images fused together as for 6 8 bit images. however, from my subjective point of view, the 6-picture approach gives better results. (how come? i thought using weights for all layers should be able to produce the same results..?) i'm shooting raw images with a canon 450d, then batch converting them all with ufraw to 16bit - to extract more 8-bit-exposures i'd have to use at least some scripts that find out in which order my bracketed shots are etc, so i'd prefer to use directly the 16 bit files. besides that, what exposures should i use for an 8-bit approach? my first idea was (from the series [-2, 0, +2]EV) to extract -2, -1.5 from the first shot, -0.5, 0, 0.5 from the middle and 1.5, 2.0 from the third - rather than using whole 1-EV increments, as then information from the middle image might struggle with the outer images ;) thx, Benjamin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
