[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
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] 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 : > 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] 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 , 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] Re: proto feature request : Motion Blur Correction
Terry Duell wrote: I went through those processes, and as I said it was not possible to align the two images such that a sensible psf could be found. I came to the conclusion that one needed pixel for pixel alignment (ie exact) to be able to derive a correct psf, and that is where I set off to look at the simple example. Maybe some more experimentation will show that reasonable improvement can be made using a psf derived from mal-aligned images. It might be necessary to execute the process iteratively, that is, find a "smooth" PSF for non-exactly aligned pictures, apply it, then reiterate and reposition the control points/the image with respect to the new level of detail added from the first iteration. Especially in this case, moving objects or parallax will lead to horrible outcomes. I think someone wrote before that it will be hard to find a correct PSF for the whole image, because of lens errors and so on. Maybe the algorithm can (for example) work on a wavelet decomposition of the image: The lowest frequency layer is processed first, the result is applied, the wavelet decomposition repeated, and the next level is processed. One can then reduce the size of the samples to be corrected, so that lens errors, misplaced control points, moving objects etc will just have a local influence. You can take regions with most control points, or best-fitting control points, calculate the PSF for these, and interpolate PSFs for regions with few control points. Just an idea. :) 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::MultiImageVectorMaskAccessor4char, 0u, 1u, 2u>, vigra::RGBValue**>, vigra::RGBAccessor >, vigra::BasicImageIterator, vigra_ext::WriteFunctorAccessorchar>, vigra::StandardValueAccessor > >, unsigned char>(vigra::Decoder*, vigra::Diff2D, vigra::MultiImageVectorMaskAccessor4char, 0u, 1u, 2u>, vigra::RGBValue**>, vigra::RGBAccessor >, vigra::BasicImageIterator, vigra_ext::WriteFunctorAccessorchar>, vigra::StandardValueAccessor > >, unsigned char) () #1 0x00522de8 in void vigra::importVectorImagevigra::MultiImageVectorMaskAccessor4char, 0u, 1u, 2u>, vigra::RGBValue**>, vigra::RGBAccessor >, vigra::BasicImageIterator, vigra_ext::WriteFunctorAccessorchar>, vigra::StandardValueAccessor > > >(vigra::ImageImportInfo const&, vigra::Diff2D, vigra::MultiImageVectorMaskAccessor4char, 0u, 1u, 2u>, vigra::RGBValue**>, vigra::RGBAccessor >, vigra::BasicImageIterator, vigra_ext::WriteFunctorAccessorchar>, vigra::StandardValueAccessor > >) () #2 0x00523663 in void vigra::importImageAlphachar, 0u, 1u, 2u>, vigra::RGBValue**>, vigra::RGBAccessor >, vigra::BasicImageIterator, vigra_ext::WriteFunctorAccessorchar>, vigra::StandardValueAccessor > >(vigra::ImageImportInfo const&, std::pair1u, 2u>, vigra::RGBValue**>, vigra::RGBAccessor > >, std::pair, vigra_ext::WriteFunctorAccessorchar>, vigra::StandardValueAccessor > >) () #3 0x00523815 in void enblend::import0u, 1u, 2u>, vigra::RGBValue**>, vigra::RGBAccessor >, vigra::BasicImageIterator, vigra::StandardValueAccessor >(vigra::ImageImportInfo const&, std::pairchar, 0u, 1u, 2u>, vigra::RGBValue**>, vigra::RGBAccessor > > const&, std::pairchar**>, vigra::StandardValueAccessor > const&) () #4 0x0055da47 in std::pair, std::allocator > >*, vigra::BasicImage >*> enblend::assemble1u, 2u>, std::allocator > >, vigra::BasicImage > >(std::liststd::allocator >&, vigra::Rect2D&, vigra::Rect2D&) () #5 0x005c1119 in void enblend::enblendMain >(std::list > const&, std::liststd::allocator > 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 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: Announce: Enblend/Enfuse version 4.0 - Final Release
Yuv wrote:
> The screen looks like JavaScript was interrupted in the middle of
> constructing the layout. Do you have access to a JavaScript console?
> is there any error message?
>
with the new version (which, btw, looks like
http://img686.imageshack.us/img686/5541/screenshotyl.png )
ewww just a moment, the _second_ time i load the page it looks like
http://img97.imageshack.us/img97/8720/screenshot2cc.png
back to the error messages, first try:
Warning: Unknown property '_overflow'. Declaration dropped. Source
File: http://enblend.sourceforge.net/enblend.css Line: 113
Error: document.getElementById("bkgnd") has no properties Source File:
http://enblend.sourceforge.net/layout.js Line: 100
which probably explains why the script stopped working.
the second time there was just the warning, no error message. could be
it's a problem with accessing an object before it is existent, so
(wildly guessing) maybe moving that piece of code into a function that
is called onLoad() might help.
> Also: which background image is loaded - the SVG, or a bunch of PNGs?
>
the SVG is loaded, i guess it also did yesterday.
> I check for SVG support with
> document.implementation (see source code) and would hate to do a
> browser detection based on its user agent string for browsers that
> fall in between legacy and modern just because they have a buggy SVG
> implementation (which may be a possibility). Do you know what is the
> equivalent version of Firefox to SeaMonkey 1.1 (AFAIK they use the
> same rendering engines)? Is SeaMonkey 1.1 recent? or when was it
> released?
>
the newest version is 2.0, but 1.1.17 still is the current version
included in the Ubuntu repositories.
SVG support should be all right, i think Mozilla could handle this even
long before there was Firefox :)
hope that helps,
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] 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
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] 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: where to find settings file for hugin?
awww, i was looking for a _folder_ ;) found it, deleted it, everything works. thanks :) Benjamin Seb Perez-D wrote: > On Wed, Jul 8, 2009 at 02:09, Benjamin > Schnieders wrote: > >> ... 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...) >> > > .hugin in your home folder (at least it is in my computer) > > Cheers, > > Seb --~--~-~--~~~---~--~~ 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] OpenGL slow because of reloading
I first couldn't decide here, but after an evening of waiting-for-preview-to-close, saving panorama and reloading it, just to be able to quickly identify some freak images in between the others and deleting them I vote for fixing this bug as soon as possible, and if needed waiting with the 0.8 release until it is fixed, as it is - in my opinion - pretty simple to reproduce this bug (I can't imagine this won't happen to anyone) by just removing an image while using the preview or re-optimizing while the preview is closed. If there might be a fix for this I'll try a recent trunk version by tomorrow... :) 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] Re: Horizontal black lines in my panoramas
Hi all, i can confirm this problem also (kind of) happened on linux, (various custom builds on Ubuntu 8.04) although it's not only black lines but also "lighter versions of previous rows" (see http://astrobenja.de/staticimgs/example.jpg) I only had these problems with pretty high resolutions (example is about 24000x24000 pixel) which take about 2 days on my pc to reproduce (i.e. stitch and blend) - but i think the error on this image was reproducible, when not changing the resolution. usually choosing a lower output size "fixed" the problem. Hoping that helps, Benjamin grow wrote: > Hugh, > > I found a problem with a single pixel horizontal lines in version 0.7 > [1] and in recent versions [2] > > I generally found that if I changed the resolution to a small amount > smaller the problem would go away. Instead of using 12,000 x 6,000 I > would find that it would work OK at 11,000x5,500. > > I was running Hugin on a Mac OS X system. As Bruno said other people > have not been able to re-create the error on other platforms ... so it > would be interesting to know what platform you are using. > > all the best > > George > > [1] > http://groups.google.com/group/hugin-ptx/browse_thread/thread/13beecaf62fc45bd/8b14adb6d5546e8a?hl=en-GB&lnk=gst&q=Horizontal+line+1+pixel+#8b14adb6d5546e8a > [2] > http://groups.google.com/group/hugin-ptx/browse_thread/thread/b63b4b3f99b991f5/3518fe2aa86e5b83?hl=en-GBe424563afc46f9d&lnk=gst#3518fe2aa86e5b83 > --~--~-~--~~~---~--~~ 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: enfuse on n16bit vs n*2 8bit images
right, i was unclear on that. i was talking about 8-bit images extracted from the same raw images. and totally ACK that the raw image does not cover the whole dynamic range of a 16 bit image as well. maybe the error even comes from postprocessing the images - using 8bit input images i get an 8bit tiff output. using 16 bit input i get a 16 bit output file as well, which i then have to either "tonemap" back to 8 bits - although the total dynamical range doesn't use more than 8 bits - or just open the file in GIMP and hope that the builtin 16-bit-importer does a good job and extracts all information (instead of just cropping at some point). usually i just open the generated files in GIMP (qtpfgui tends to crash), maybe that's even the explanation. does anyone know a good (fast?) tool for linux handling 16bit images? allard wrote: > I'm no expert on enfuse, but 16 bit images do not contain the same > amount of information as two 8-bit images. There's at most about 10 > bits (stops) of real information in that 16 bit file, see also > http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/index.html. If you > are talking about 6 8-bit images created out of the same 3 16-bit > images that does sound unexpected (again, knowing very little about > enfuse), but if this is 6 exposures vs 3 I'm not surprised --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: new panini projection
Hi all, just created my first panorama using the panini projection - compared to equirectangular - which would have been my first choice - it somehow added more depth to the scene. (a small cemetery with winterly trees in the background) anyway, since there are so many projections now, maybe we should think about ordering them? something like "keeps straight lines", "keeps angles", "keeps areas equal" or "mixed", as the architectural projection. or are the projections too different to be classified like that? thx to all developers :) can't imagine working without hugin/panotools anymore 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: how do I crop the preview
which version of hugin do you use? i still know a version where cropping was only possible by setting the field of view. (what you adjust with the sliders) in current versions, you align your panorama as you like it (horizon on or near the horizon line, in a way that the horizon of the image is not curved), leave the sliders as they are (even when you have huge black borders, for example on the lower half) and then go to the Stitcher tab and fill in values at the Crop-Section - go back to the preview window, hit refresh and notice the while lines showing you where the image will be cut off. Benjamin panoplayer wrote: > I've been able to use the preview window to straighten and center my > pano, but I can't seem to get rid of the huge black area. > http://synature.smugmug.com/gallery/6301958_DwLHk#397395920_Hyknr > Shows the sequence I went through, though the first one is not there. > The first one had a huge black area going off to one side. > > I center it, then I move the slider on the right to reduce the huge > areas of black above and below, then I click on straigten and I end up > with the pano at the top and a huge black area underneath. If I click > on center again, it ends up with a curve again, if instead I try to > move the slider on the right, it chops off the top. > > Any suggestions on how to get this to come out right? > > Thanks, > Brandon > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
[hugin-ptx] Re: Bad behaviour with 2 images cropped from the same image
As a workaround, you might open the file in any image editing program and erase (make transparent) the areas you don't want to have in your final result - this way the fov/image dimensions are not altered. I also assume that hugin does not have knowledge about which orientation the image is - at least my exif data does not contain such information - so when you crop a horizontal image to have vertical dimensions, hugin might choose the higher dimension as parameter for the hfov. But this is just a guess ;) 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~--~~~~--~~--~--~---
