Fwd: Re: Re: possible memory leak in enblend & enfuse?
|
View:
New views
17 Messages
—
Rating Filter:
Alert me
|
 |
Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Rogier Wolff
::
Rate this Message:
On Thu, Oct 15, 2009 at 03:36:20PM +0200, Rogier Wolff wrote: > > On Thu, Oct 15, 2009 at 03:27:07PM +0200, Harry van der Wolf wrote: > > > As I will go on holiday this saturday I don't have time time to > > build a 64bit version to see how much memory enblend is trying to > > use. If the new patched 64bit version uses, for example, 5GB and > > than finishes fine, it means that we need to switch to 64bit builds > > for larger images and the user needs to be at least on Leopard. If > > it still runs "into infinity" (and make my system crash) than the > > issue is still not solved. > What do I need to do to reproduce? I'll track this one down as well. > (I still have george's images). The reason I ask is that the commandline I tried, it doesn't crash here. I ran: /home/wolff/enblend/enblend-enfuse-3.2-rew/src/enblend --compression NONE -v --fine-mask --fine-mask -w -f12000x6000 -o t3_exposure_00.tif t3_exposure_layers_00??.tif which ended with: Writing final output... 1295.048u 215.729s 42:15.26 59.5% 0+0k 17555472+138675632io 45452pf+0w assurancetourix:~/grow> So to prevent me from having to try everything: What did you run it on, what command line? Of course it could be that it only crashes on your system because of something (a library perhaps) on your system. However, so far it's been perfectly reproducable here. If neccesary I will give you FTP access to upload the offending images, or you could give me SSH access to your system to work there. (but you'll have to tell me what I need to do to recompile enblend, Chris, I'm not sure what the definition of a "seam" is, but Georges project does cause lots of them. Maybe that's the core of the problem. Someone suggested that a seam is supposed to be an area, so then a two-point seam doesn't make any sense. When I run the whole project (with the above commandline): Loading next image: t3_exposure_layers_0025.tif ... Optimizing 140 distinct seams. ... Optimizing 67 distinct seams. Roger. -- ** R.E.Wolff@... ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: possible memory leak in enblend & enfuse?
by Harry van der Wolf-3
::
Rate this Message:
2009/10/15 Rogier Wolff <rew-googlegroups@...>
I ran it on MacOSX 10.5.8 on an Intel MacBookPro with 4GB memory. The command line was the exact same command line you used: /Users/Shared/development/hugin_related/ExternalPrograms/repository/bin/enblend --compression NONE -v --fine-mask --fine-mask -w -f12000x6000 -o try.tif pipo_exposure_layers_00*.tif
That's also what I suspected, so I built all libraries again: jpeg, tiff, png, ilmbase and openexr. I do use boost but enblend is not linked against it as boost is not correctly recognised by either the autoconf nor the cmake build. It did function and I don't know why it doesn't function anymore.
The images are the same images you use: they are the "village hotel" images from George. Harry --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: possible memory leak in enblend & enfuse?
by Rogier Wolff
::
Rate this Message:
On Thu, Oct 15, 2009 at 08:52:42PM +0200, Harry van der Wolf wrote: > I ran it on MacOSX 10.5.8 on an Intel MacBookPro with 4GB memory. > The command line was the exact same command line you used: > /Users/Shared/development/hugin_related/ExternalPrograms/repository/bin/enblend > --compression NONE -v --fine-mask --fine-mask -w -f12000x6000 -o try.tif > pipo_exposure_layers_00*.tif ok. > > If neccesary I will give you FTP access to upload the offending > > images, or you could give me SSH access to your system to work there. > > (but you'll have to tell me what I need to do to recompile enblend, > The images are the same images you use: they are the "village hotel" images > from George. OK. So the question is: does it depend on the images (which we generated separately with nona), or on something external. I'm going to see if I get the same results with tiff files that blank out ALL image data, and retain only the alpha channel. I suspect they will compress really good, so that if I tell you how to do that, you can send your output images (ehhh, input images for enblend) to me, and the other way around. Roger. -- ** R.E.Wolff@... ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by cspiel
::
Rate this Message:
Hello Roger - On Oct 15, 5:29 pm, Rogier Wolff <rew-googlegro...@...> wrote: > Chris, I'm not sure what the definition of a "seam" is, but Georges > project does cause lots of them. Maybe that's the core of the problem. The relevant definitions for seams are in "mask.h". What we call a "seam" in out discussions here, is a ContourVector in Enblend. typedef std::pair<bool, vigra::Point2D> SegmentPoint; typedef std::slist<SegmentPoint> Segment; typedef std::vector<Segment*> Contour; typedef std::vector<Contour*> ContourVector; Definitions are aplenty, because we can have more than one Contour per overlap area. Contours themselves consist of one or more segments of straight lines. Each SegmentPoint can be movable (: bool), which is where the seam-line optimizer attacks. Both, std::vector and std::slist are container classes with a rather low memory overhead. Furthermore, I have never seen excessively large seams (which of course does not mean that they do not exist - I have not see Nessie, either). However, in an infinite loop no data structure would be compact enough. ;-) > Someone suggested that a seam is supposed to be an area, so then a > two-point seam doesn't make any sense. It was not just someone, it was Andrew himself. All hail to the King! In my mathematical sophistry, I would like to point out the two topologically different kinds of contours: (a) contractible and (b) non-contractible. Whereas (a) is degenerate if its enclosed area vanishes, we cannot simply assign an area to (b). Thus, we would have to determine first whether a contour is contractible, and then compute its area, and finally kick it out, if this area is zero. To cite someone called Linus Torvalds: "Nice idea. Show me the code." Let me mention a point that has kept me guessing since I first looked a the "interesting" image pair t3_exposure_layers_002[45].tif of George's now famous panorama. These to images show exactly the _same_ subject at different exposure values. In other words, for me they make perfect candidates for (en)fusing, _not_ for (en)blending. (1) Why would you want to blend two images that overlap 100%? You gain no "real estate" at all. (2) Why would you blend two images so different exposure values? It never would look well. I think this could be the reason, why Enblend goes crazy with hundreds of contours: the images really are meant for (en)fusing or am I missing an important aspect? Cheers, Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Rogier Wolff
::
Rate this Message:
On Thu, Oct 15, 2009 at 11:24:10PM -0700, cspiel wrote: > > Hello Roger - > > On Oct 15, 5:29 pm, Rogier Wolff <rew-googlegro...@...> > wrote: > > Chris, I'm not sure what the definition of a "seam" is, but Georges > > project does cause lots of them. Maybe that's the core of the problem. > > The relevant definitions for seams are > in "mask.h". What we call a "seam" in out > discussions here, is a ContourVector in Enblend. > > typedef std::pair<bool, vigra::Point2D> SegmentPoint; > typedef std::slist<SegmentPoint> Segment; > typedef std::vector<Segment*> Contour; > typedef std::vector<Contour*> ContourVector; > > Definitions are aplenty, because we can have > more than one Contour per overlap area. > Contours themselves consist of one or more > segments of straight lines. Each SegmentPoint > can be movable (: bool), which is where the > seam-line optimizer attacks. OK. That's the C++ definition part, but what does this correspond to in image-space. The simplest case has two images, that overlap: +---------+====+----------+ | | | | | | | | | | | | | | | | | | | | | | | | +---------+====+----------+ single seam, right. And the countour would describe the overlapping area? What would optimization do? +--------------+ | | | +----|----------+ | | | | | | | | | | | | | | | | +---------|----+ | | | +---------------+ Here too, we have single overlapping area but now I'd say the seam would have to start from bottom left and end top right of the overlap area. Those corners would be unmovable? > (1) Why would you want to blend two images > that overlap 100%? You gain no "real > estate" at all. > (2) Why would you blend two images so > different exposure values? It never would > look well. > I think this could be the reason, why Enblend goes crazy with > hundreds of contours: the images really are meant for (en)fusing or > am I missing an important aspect? You are very familiar with enblend and enfuse and know exactly what they do, and when you'd use them. Most people are not this familiar with the code, and simply fire up a GUI. The hugin-0.7.0 gui, I suspect simply blended all the images from an exposure stack. How anybody can think that this might have worked, I don't know. I see newer versions of Hugin doing "the right thing", so that side of the problem has been fixed. It is a funny situation that only crashes enblend in weird circumstances, but it is still a bug in enblend that is good to have fixed. So even though the original test-data is a bit nonsensical, it did allow us to find and fix a bug. I'm currently blending my own pano in three separate rows, and then blend those rows. I had a crash when I just let hugin provide the enblend commandline. For the hugin people: it might make sense to allow hugin users to induce these (in my case) three rows to blend before blending the rows. Roger. -- ** R.E.Wolff@... ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by grow
::
Rate this Message:
Roger, Chris, I am not sure exactly which two images Roger had focused in on as being the cause of the problem (partly because the files have different names). But I suspect that they were two very similar looking shots of the ground. This apparently "nonsensical" choice results from my habit of taking two "Down" shots trying to hand hold the camera where it had been on the tripod while standing in a different place each time and then masking my feet out of each shot. This usually results in a clean Equirectangular result without the need for me to paint out the feet in Photoshop. Typically they would look like these ... where the notch in each rectangle is the mask covering the feet. _______ | | | | | __| | |__ |_______| _______ |___ | ___| | | | | | |_______| If I succeed in being a perfect human tripod the images will be identical except for the masks. Something that has always puzzled me in the Hugin GUI is how images are selected to be part of a stack (that gets enfused) or part of a layer (that get enblended together) I pretty much follow the recipe given by Bruno in his tutorial. But when I tried to explain it to other people I realised that I was just trusting Hugin to somehow "know" which ones to combine which way. How does it decide? I have assumed that images that have the same Yaw are assumed to be part of the same stack ... but then what about a ground or sky shot that has the same Yaw as one of the horizontal shots ... so then it must be "Same Yaw, Pitch and Roll" ... but then what about a stack that is not perfectly aligned? Is there some way that I can better indicate to Hugin how to handle images that overlap except for masked areas? Or should I just give up and merge these images in a separate pass. all the best George On 16 Oct, 10:53, Rogier Wolff <rew-googlegro...@...> wrote: > On Thu, Oct 15, 2009 at 11:24:10PM -0700, cspiel wrote: > > > Hello Roger - > > > On Oct 15, 5:29 pm, Rogier Wolff <rew-googlegro...@...> > > wrote: > > > Chris, I'm not sure what the definition of a "seam" is, but Georges > > > project does cause lots of them. Maybe that's the core of the problem. > > > The relevant definitions for seams are > > in "mask.h". What we call a "seam" in out > > discussions here, is a ContourVector in Enblend. > > > typedef std::pair<bool, vigra::Point2D> SegmentPoint; > > typedef std::slist<SegmentPoint> Segment; > > typedef std::vector<Segment*> Contour; > > typedef std::vector<Contour*> ContourVector; > > > Definitions are aplenty, because we can have > > more than one Contour per overlap area. > > Contours themselves consist of one or more > > segments of straight lines. Each SegmentPoint > > can be movable (: bool), which is where the > > seam-line optimizer attacks. > > OK. That's the C++ definition part, but what does this correspond to > in image-space. > > The simplest case has two images, that overlap: > > +---------+====+----------+ > | | | | > | | | | > | | | | > | | | | > | | | | > | | | | > +---------+====+----------+ > > single seam, right. And the countour would describe the overlapping > area? What would optimization do? > > +--------------+ > | | > | +----|----------+ > | | | | > | | | | > | | | | > | | | | > +---------|----+ | > | | > +---------------+ > > Here too, we have single overlapping area but now I'd say the seam > would have to start from bottom left and end top right of the overlap > area. Those corners would be unmovable? > > > (1) Why would you want to blend two images > > that overlap 100%? You gain no "real > > estate" at all. > > (2) Why would you blend two images so > > different exposure values? It never would > > look well. > > I think this could be the reason, why Enblend goes crazy with > > hundreds of contours: the images really are meant for (en)fusing or > > am I missing an important aspect? > > You are very familiar with enblend and enfuse and know exactly what > they do, and when you'd use them. Most people are not this familiar > with the code, and simply fire up a GUI. The hugin-0.7.0 gui, I > suspect simply blended all the images from an exposure stack. How > anybody can think that this might have worked, I don't know. > > I see newer versions of Hugin doing "the right thing", so that side of > the problem has been fixed. > > It is a funny situation that only crashes enblend in weird > circumstances, but it is still a bug in enblend that is good to have > fixed. So even though the original test-data is a bit nonsensical, it > did allow us to find and fix a bug. > > I'm currently blending my own pano in three separate rows, and then > blend those rows. I had a crash when I just let hugin provide the > enblend commandline. > > For the hugin people: it might make sense to allow hugin users to > induce these (in my case) three rows to blend before blending the rows. > > Roger. > > -- > ** R.E.Wo...@... **http://www.BitWizard.nl/** +31-15-2600998 ** > ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** > *-- BitWizard writes Linux device drivers for any device you may have! --* > Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. > Does it sit on the couch all day? Is it unemployed? Please be specific! > Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Bruno Postle
::
Rate this Message:
On Fri 16-Oct-2009 at 10:15 -0700, grow wrote: > >Something that has always puzzled me in the Hugin GUI is how images >are selected to be part of a stack (that gets enfused) or part of a >layer (that get enblended together) >How does it decide? Hugin checks the yaw and pitch of all photos, and any where these angles vary less than 10% of the photo's angle of view are considered 'stacks' (with Fused and Blended output). This can obviously fail for nadir/zenith situations, really the absolute angular distance should be checked, but this has never been reported as a bug so probably the way we do it is 'good enough' (patches welcome though). Similarly any photos with less than 0.5EV exposure difference are considered 'exposure layers' (with Blended and Fused output)'. What is wrong is that although these decisions get written to the .pto.mk files, there is nothing in the GUI to tell the user which photos are being grouped like this - You have to run the stitch to find out. >Is there some way that I can better indicate to Hugin how to handle >images that overlap except for masked areas? Or should I just give up >and merge these images in a separate pass. I think enblend is still the right tool. This is how I shoot two shots to get rid of my own shadow, but I give them a different 'yaw' to force a vertical seam. i.e. this panorama doesn't have a retouched nadir, it is more-or-less how it came out of Hugin: http://www.flickr.com/photos/36383814@N00/2893620038 ..I should do a tutorial. -- Bruno --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by grow
::
Rate this Message:
Roger, Chris, Bruno, If I understand correctly the images that Roger has identified as the cause of the crash are: t3_exposure_layers_0024.tif t3_exposure_layers_0025.tif and these are the images that would come out of the Nona phase of my original project with the same numerical suffixes. The suffixes run from 0 to 26 for my 27x image, 9x stack project with 3x bracketed images in each stack. So these are the first and second image in the 9th stack! (I had misunderstood earlier and assumed that the problematic pair bridged the 8th and 9th stacks but if Roger's suffix-numbering matches the numbering in the original project they are both in the 9th stack. Bruno, My 8th and 9th stacks are applying exactly the method that you mentioned for removing the photographers shadow and feet. My misunderstanding of the numbering earlier had me thinking that that was a problem.) So if I correctly understand Bruno's explanation of how Hugin decides on which images to stack/blend and which to layer/fuse ... then the question for me is ... why was Hugin TRYING to apply Enblend these two images? I originally entered them with a Yaw of 0 ... but after Optimization they were each placed as follows: Yaw: -1.775 Pitch: -82.729 Roll: 39.543 Yaw: -1.836 Pitch: -82.735 Roll: 39.621 This is nothing like Bruno's 10% angle threshold ... So why would Hugin apply Enblend to them? all the best George On 16 Oct, 21:00, Bruno Postle <br...@...> wrote: > On Fri 16-Oct-2009 at 10:15 -0700, grow wrote: > > > > >Something that has always puzzled me in the Hugin GUI is how images > >are selected to be part of a stack (that gets enfused) or part of a > >layer (that get enblended together) > >How does it decide? > > Hugin checks the yaw and pitch of all photos, and any where these > angles vary less than 10% of the photo's angle of view are > considered 'stacks' (with Fused and Blended output). > > This can obviously fail for nadir/zenith situations, really the > absolute angular distance should be checked, but this has never been > reported as a bug so probably the way we do it is 'good enough' > (patches welcome though). > > Similarly any photos with less than 0.5EV exposure difference are > considered 'exposure layers' (with Blended and Fused output)'. > > What is wrong is that although these decisions get written to the > .pto.mk files, there is nothing in the GUI to tell the user which > photos are being grouped like this - You have to run the stitch to > find out. > > >Is there some way that I can better indicate to Hugin how to handle > >images that overlap except for masked areas? Or should I just give up > >and merge these images in a separate pass. > > I think enblend is still the right tool. This is how I shoot two > shots to get rid of my own shadow, but I give them a different 'yaw' > to force a vertical seam. i.e. this panorama doesn't have a > retouched nadir, it is more-or-less how it came out of Hugin: > > http://www.flickr.com/photos/36383814@N00/2893620038 > > ..I should do a tutorial. > > -- > Bruno You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Lukáš Jirkovský
::
Rate this Message:
2009/10/17 grow <georgerow@...>:
> > Roger, Chris, Bruno, > If I understand correctly the images that Roger has identified as the > cause of the crash are: > t3_exposure_layers_0024.tif > t3_exposure_layers_0025.tif > and these are the images that would come out of the Nona phase of my > original project with the same numerical suffixes. The suffixes run > from 0 to 26 for my 27x image, 9x stack project with 3x bracketed > images in each stack. So these are the first and second image in the > 9th stack! > > (I had misunderstood earlier and assumed that the problematic pair > bridged the 8th and 9th stacks but if Roger's suffix-numbering matches > the numbering in the original project they are both in the 9th > stack. > > Bruno, > My 8th and 9th stacks are applying exactly the method that you > mentioned for removing the photographers shadow and feet. My > misunderstanding of the numbering earlier had me thinking that that > was a problem.) > > So if I correctly understand Bruno's explanation of how Hugin decides > on which images to stack/blend and which to layer/fuse ... then the > question for me is ... why was Hugin TRYING to apply Enblend these two > images? > > I originally entered them with a Yaw of 0 ... but after Optimization > they were each placed as follows: > Yaw: -1.775 Pitch: -82.729 Roll: 39.543 > Yaw: -1.836 Pitch: -82.735 Roll: 39.621 > > This is nothing like Bruno's 10% angle threshold ... So why would > Hugin apply Enblend to them? > > all the best > > George > > On 16 Oct, 21:00, Bruno Postle <br...@...> wrote: >> On Fri 16-Oct-2009 at 10:15 -0700, grow wrote: >> >> >> >> >Something that has always puzzled me in the Hugin GUI is how images >> >are selected to be part of a stack (that gets enfused) or part of a >> >layer (that get enblended together) >> >How does it decide? >> >> Hugin checks the yaw and pitch of all photos, and any where these >> angles vary less than 10% of the photo's angle of view are >> considered 'stacks' (with Fused and Blended output). >> >> This can obviously fail for nadir/zenith situations, really the >> absolute angular distance should be checked, but this has never been >> reported as a bug so probably the way we do it is 'good enough' >> (patches welcome though). >> >> Similarly any photos with less than 0.5EV exposure difference are >> considered 'exposure layers' (with Blended and Fused output)'. >> >> What is wrong is that although these decisions get written to the >> .pto.mk files, there is nothing in the GUI to tell the user which >> photos are being grouped like this - You have to run the stitch to >> find out. >> >> >Is there some way that I can better indicate to Hugin how to handle >> >images that overlap except for masked areas? Or should I just give up >> >and merge these images in a separate pass. >> >> I think enblend is still the right tool. This is how I shoot two >> shots to get rid of my own shadow, but I give them a different 'yaw' >> to force a vertical seam. i.e. this panorama doesn't have a >> retouched nadir, it is more-or-less how it came out of Hugin: >> >> http://www.flickr.com/photos/36383814@N00/2893620038 >> >> ..I should do a tutorial. >> >> -- >> Bruno > > > after reading the entire thread it seems that there are more different causes for the crash. Rogier fixed one of them. The second one is problem with writing (and maybe reading) files which mmaps entire file. Let me guess. All of you use tiff files (as input and maybe also output). I've got similar problem with Gimp several times in past when it was not able to save tiff data when memory was full (with error insufficient memory I think). So let's take a look at libtiff first. After some searching I've found out that mmaping entire file is default behavior of libTiff and we are not the first ones for whom this causes huge memory allocations. So what to do? I read the man page of TIFFOpen and the fix seems quite easy. Patch is attached. It may be a bit slower but it should reduce memory usage. have a nice day, Lukas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- diff -r 1f34bd7a13f0 src/vigra_impex/tiff.cxx --- a/src/vigra_impex/tiff.cxx Thu Oct 15 08:10:46 2009 +0200 +++ b/src/vigra_impex/tiff.cxx Sat Oct 17 11:43:48 2009 +0200 @@ -255,7 +255,7 @@ { const FilenameLayerPair file_layer = split_filename(filename); - tiff = TIFFOpen( file_layer.first.c_str(), "r" ); + tiff = TIFFOpen( file_layer.first.c_str(), "rCm" ); if ( !tiff ) { std::ostringstream oss; oss << "Unable to open file '" << file_layer.first << "'."; @@ -725,7 +725,7 @@ TIFFEncoderImpl( const std::string & filename ) : tiffcomp(COMPRESSION_NONE), finalized(false) { - tiff = TIFFOpen( filename.c_str(), "w" ); + tiff = TIFFOpen( filename.c_str(), "wCm" ); if (!tiff) { std::string msg("Unable to open file '"); |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by cspiel
::
Rate this Message:
Roger - On Oct 16, 11:53 am, Rogier Wolff <rew-googlegro...@...> wrote: > Most people are not this familiar > with the code, and simply fire up a GUI. The hugin-0.7.0 gui, I > suspect simply blended all the images from an exposure stack. What do you suggest Enblend should do? Should it detect an almost complete overlap of a pair of images and report the problem to the user? This would be very helpful in the case we discuss here, but lead us to the problem of how to identify these pairs of images. Furthermore, how can we code this efficiently? > It is a funny situation that only crashes enblend in weird > circumstances, but it is still a bug in enblend that is good to have > fixed. So even though the original test-data is a bit nonsensical, it > did allow us to find and fix a bug. You are totally right. Enblend must behave even with nonsensical data. Right now the Distance Transform routine goes ballistic when two images almost completely overlap. I have some ideas, but I'm also curious of your suggestions. /Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Andrew Mihal-2
::
Rate this Message:
Hi, I suspect a problem in the vectorization of the seam lines. There is currently no checking that the MaskVectorizeDistance parameter is suitable for the number of actual pixels on the seam (the points visited by the CrackContourCirculator). Thus we can construct snakes that undersample the seam and have only one or two vertices. This is likely to happen when the distance transform result has many small, fragmented patches. For each seam we should compute an appropriate MaskVectorizeDistance heuristically. The condition that leads to the error message "mask is entirely black, but the white image was not identified as redundant" also needs to be examined. If the seam optimization is allowed to remove snakes entirely, either because the vectorization decides the contour is too small or because the annealer collapses the contour, then this condition should not be an error. The white image does have pixels to contribute (according to the distance transform), but the optimization decided that it was not worthwhile to blend them in. Currently the optimization does not consider the contour area as a constraint. I think this requires more thought. Should the optimization be allowed to collapse contours or is this a bug? Andrew On Sat, Oct 17, 2009 at 5:23 AM, cspiel <cspiel@...> wrote: > > Roger - > > On Oct 16, 11:53 am, Rogier Wolff <rew-googlegro...@...> > wrote: >> Most people are not this familiar >> with the code, and simply fire up a GUI. The hugin-0.7.0 gui, I >> suspect simply blended all the images from an exposure stack. > > What do you suggest Enblend should do? > Should it detect an almost complete overlap > of a pair of images and report the problem to > the user? This would be very helpful in the > case we discuss here, but lead us to the problem > of how to identify these pairs of images. > Furthermore, how can we code this efficiently? > > >> It is a funny situation that only crashes enblend in weird >> circumstances, but it is still a bug in enblend that is good to have >> fixed. So even though the original test-data is a bit nonsensical, it >> did allow us to find and fix a bug. > > You are totally right. Enblend must > behave even with nonsensical data. Right now > the Distance Transform routine goes ballistic > when two images almost completely overlap. I > have some ideas, but I'm also curious of your > suggestions. > > > /Chris > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Pablo d'Angelo
::
Rate this Message:
Hi Andrew, Andrew Mihal schrieb: > Hi, > I suspect a problem in the vectorization of the seam lines. Actually, the approach of using vectorized seam lines is a relatively complicated process. Additionally, snakes are not particularly well known to find good global solutions. I think a different approach to seam line finding would avoid these problems, and also leads to better seams. One possibility are the graph cut based segmentation algorithms. Here the masks are generated directly and there is no need for going from masks to vectors and back to masks. I'm also quite sure that the generated seams would be better than with the current snake algorithm. ciao Pablo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
|
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Andrew Mihal-2
::
Rate this Message:
Hi Pablo, Can you elaborate a little on your criticism of snakes? Is the problem: - That the polyline formulation cannot describe a good solution at all? - That the size of the state space in the current implementation is too restrictive? - That the current implementation's cost functions do not correlate with a good solution? - That the current implementation's GDA solver is insufficiently powerful to find a good answer to the optimization problem? - something else? It seems to me that the "best" seamline can be modeled as a polyline, and the search space can be defined in such a way as to include the "best" seam as a possibility. I admit that the current search space definition is a little rough, and that the GDA is buggy and needs parameter tuning. I think the hard part is defining what is "best" and turning that into equations. But surely the graph cut approach has this same requirement? Andrew On Sat, Oct 17, 2009 at 10:18 AM, Pablo d'Angelo <pablo.dangelo@...> wrote: > > Hi Andrew, > > Andrew Mihal schrieb: >> Hi, >> I suspect a problem in the vectorization of the seam lines. > > Actually, the approach of using vectorized seam lines is a relatively > complicated process. Additionally, snakes are not particularly well > known to find good global solutions. I think a different approach to > seam line finding would avoid these problems, and also leads to better > seams. One possibility are the graph cut based segmentation algorithms. > Here the masks are generated directly and there is no need for going > from masks to vectors and back to masks. I'm also quite sure that the > generated seams would be better than with the current snake algorithm. > > ciao > Pablo > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Pablo d'Angelo
::
Rate this Message:
Hi Andrew, Andrew Mihal schrieb: > Hi Pablo, > Can you elaborate a little on your criticism of snakes? > > Is the problem: > - That the polyline formulation cannot describe a good solution at all? A polyline can describe all possible solutions, if it is fine enough. > - That the size of the state space in the current implementation is > too restrictive? While I don't have a strict proof, I feel that the state space of the snake model is too restrictive and too powerful at the same time, as it allows self crossings of the seam line etc. Also, only a small part of the image content (on lines perpendicular to the initial seam) is used to determine the "major" location of the seam line. I believe that a state space that includes the whole overlap area and not only some profiles of it would lead to better results. The second step (dijkstra shortest path) does try to remove these limitations but it can't undo the decisions made by the polyline optimisation. A straightforward state space is an image that holds 0 for image pixels in the first image, and 1 for image pixels in the second image. This statespace has the advantage that it directly models the problem. Finding a solution can be done by modelling it as a graph and finding the minimum cut. In this approach, each pixel in the overlap region would be a node in the graph. The edges connect each pixel to the 4 nearest neighbours. The edge value is the sum of the absolute color difference between the nodes connected by the edge. The source node is connected to all pixels that are on the boundary of the overlap regions and are only valid in the first image. The sink node is connected to all pixels that are on the boundary of the overlap regions and are only valid in the second image. Finding the minimum cut in this graph will give the seam line that has the smallest color difference (note that this is the global minimum), and hence a good position for a seam line. This also means that only the cost function and not the parameterization of the optimization algorithm influence the result. This should be relatively efficient, and it should be able to handle all special cases with strange overlap situations with holes, small overlaps etc. naturally. There are some illustrations of the above in: http://www.cs.huji.ac.il/course/2006/impr/lectures2006/Tirgul9b_Panoramas_blendStitch.pdf slides 29ff Some more ideas on how to refine the cost function so that other constraints can also be added: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.129.8181 Implementations of Minimum cut algorithms are widely available, for example from the boost graph library or http://www.cs.ucl.ac.uk/staff/V.Kolmogorov/software.html (maxflow v2.2 is GPL licensed). I think an implementation in enblend wouldn't be too hard to do, and might be simpler than trying to fix all special cases with the current approach. Additionally, I believe that it would find better seams, so it is worth trying. Unfortunately, I currently don't have the time to do so... :-( > - That the current implementation's cost functions do not correlate > with a good solution? No, I think these are good enough. > - That the current implementation's GDA solver is insufficiently > powerful to find a good answer to the optimization problem? Yes, combined with the problems of the statespace indicated above. > - something else? The main source of bugs seems to be related to the bitmap -> vector -> bitmap approach required by the polyline optimisation. > It seems to me that the "best" seamline can be modeled as a polyline, > and the search space can be defined in such a way as to include the > "best" seam as a possibility. I admit that the current search space > definition is a little rough, and that the GDA is buggy and needs > parameter tuning. I think the hard part is defining what is "best" and > turning that into equations. But surely the graph cut approach has > this same requirement? The main reason why I advocate trying graph cut approach is: It should allow a different state space, which I think will sidestep most of the painful problems related to many special cases with the vector seams. This might be also possible to optimize the pixel labeling directly with the simulated annealing, however it would probably take forever to find a good solution due to the higher dimensionality of the state space. ciao Pablo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Rogier Wolff
::
Rate this Message:
On Wed, Oct 28, 2009 at 10:56:08PM +0100, Pablo d'Angelo wrote: > Implementations of Minimum cut algorithms are widely available, for > example from the boost graph library or > http://www.cs.ucl.ac.uk/staff/V.Kolmogorov/software.html (maxflow v2.2 > is GPL licensed). > > I think an implementation in enblend wouldn't be too hard to do, and > might be simpler than trying to fix all special cases with the current > approach. The current approach, I think, is very good at hiding some differences between adjacent images. Getting a good initial "cut-line" might help a bit. But just switching to a "good cut line" according to this algorithm you described is not good enough. I have been thinking about THIS algorithm for the past few weeks. Your "edge cost" function I think is too simple. I would add in the costs (i.e. absolute pixel differences) of a circle around the current edge. Suppose we have a person "half" on an image. The intention is to "cut" completely around this person. (cutting through the person should incur high costs because the pixels differ a lot.) Now suppose a small black line is in front of the person. Now both images have this line where the "absolute difference between pixels" is quite low (both black), but closeby pixels DO differ. Roger. -- ** R.E.Wolff@... ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Fwd: Re: Re: possible memory leak in enblend & enfuse?
by Pablo d'Angelo
::
Rate this Message:
Rogier Wolff schrieb: > On Wed, Oct 28, 2009 at 10:56:08PM +0100, Pablo d'Angelo wrote: >> Implementations of Minimum cut algorithms are widely available, for >> example from the boost graph library or >> http://www.cs.ucl.ac.uk/staff/V.Kolmogorov/software.html (maxflow v2.2 >> is GPL licensed). >> >> I think an implementation in enblend wouldn't be too hard to do, and >> might be simpler than trying to fix all special cases with the current >> approach. > > The current approach, I think, is very good at hiding some differences > between adjacent images. Getting a good initial "cut-line" might help > a bit. But just switching to a "good cut line" according to this > algorithm you described is not good enough. > > I have been thinking about THIS algorithm for the past few weeks. > > Your "edge cost" function I think is too simple. I would add in the > costs (i.e. absolute pixel differences) of a circle around the current > edge. Actually, I believe that enblend also uses a very similar cost function currently, ie absolute gray value differences, with a much more restrictive state space. Thus I am not convinced that the simple absolute differences cost function is "not good enough", when comparing to the current state. > Suppose we have a person "half" on an image. The intention is to "cut" > completely around this person. (cutting through the person should > incur high costs because the pixels differ a lot.) > > Now suppose a small black line is in front of the person. Now both > images have this line where the "absolute difference between pixels" > is quite low (both black), but closeby pixels DO differ. Of course it is possible to fool this simple cost function, as it is possible with the current enblend. The pragmatic approach would be to first implement the graph cut optimization and then see where the problems with the simple absolute differences cost. Then the cost function can be further tuned. I suspect that maybe adding a soft constraint that tries to keep the seam line closer to the center of the overlap region might also be helpful. ciao Pablo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@... To unsubscribe from this group, send email to hugin-ptx+unsubscribe@... For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~--- |
| Free embeddable forum powered by Nabble | Forum Help |
