On Mon, Oct 19, 2009 at 02:19:38AM -0700, cspiel wrote:
> We have one free parameter, the ratio of non-overlapping pixels over
> the total number of pixels in the overlap region. We could use it
> to tune this check.
I was thinking about the ratio of "new pixels" to "total pixels in
this new im
Roger -
On Oct 17, 11:40 pm, Rogier Wolff
wrote:
> The problem is more complex. The normal mode-of-operation of enblend
> is: that images are added incrementally. So such an "almost
> overlapping" image could very well be completely inside the "already
> assembled pixels", which enblend detects,
On Sat, Oct 17, 2009 at 05:23:40AM -0700, cspiel wrote:
>
> Roger -
>
> On Oct 16, 11:53 am, Rogier Wolff
> 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
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
Roger -
On Oct 16, 11:53 am, Rogier Wolff
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 comple
2009/10/17 grow :
>
> 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 t
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
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 a
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
On Thu, Oct 15, 2009 at 11:24:10PM -0700, cspiel wrote:
>
> Hello Roger -
>
> On Oct 15, 5:29 pm, Rogier Wolff
> 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 de
Hello Roger -
On Oct 15, 5:29 pm, Rogier Wolff
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
discussi
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 NON
2009/10/15 Yuval Levy
>
> Harry van der Wolf wrote:
> > I'll try to release the hugin2009.4.0-RC1 build tonight.
>
> Hi Harry. an RC2 is due this weekend. Maybe you want to wait for that? I
> can anticipate it for tonight. You are already working very hard and
> putting in so many hours into this
2009/10/15 Rogier Wolff
>
> 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 enblen
Harry van der Wolf wrote:
> I'll try to release the hugin2009.4.0-RC1 build tonight.
Hi Harry. an RC2 is due this weekend. Maybe you want to wait for that? I
can anticipate it for tonight. You are already working very hard and
putting in so many hours into this.
It would be nice if other OSX u
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 pa
Hi Roger
Rogier Wolff wrote:
>
> I don't think enblend needs much memory. On my system I use the
> default -m 1024, which tells enblend to limit memory usage to 1Gb of
> memory. In that case, it uses 1036 Mb of memory on my
> system. Apparently It limits "image data" to 1Gb, and uses a few
> me
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 mea
2009/10/10 Rogier Wolff
>
> However, if you skip loading and blending of EVERYTHING before
> *_0024.tif and try to blend only '24 and '25, the exact same crash
> happens.
>
> /this/ is the commandline I'm currently using to reproduce george's
> crash:
>
> enblend --compression NONE -v --fine-mas
Andrew -
On Oct 14, 5:49 pm, Andrew Mihal wrote:
> A two-point polygon has zero area, so it is unclear what region
> of the mask this is outlining.
This was the very reason, why I
hesitated to immediately apply the patch. I
pondered on a kind of snake cleanup, too.
However, it is conc
Hi,
A correct fix will require determining the cause of the two-point
snake. A two-point polygon has zero area, so it is unclear what region
of the mask this is outlining. Perhaps the mask has isolated
single-pixel spots of black and white? E.g. if the user set the input
alpha masks with spots
Hi Chris,
On Wed, Oct 14, 2009 at 12:55:23AM -0700, cspiel wrote:
> Oh, I just wanted to follow the DRY principle and to heed Roger's
> concerns about the runtime penalty of an if-clause inside the loop
> of all snake segments. Nothing fancy, really.
I wasn't concerned about the runtime impi
On Oct 13, 10:52 pm, Harry van der Wolf wrote:
> For the time being I will await Christoph Spiel's actions as he also
> modified the patch for the current enblend version that is being used
> but he did not yet add it to the Enblend trunk.
The change has just been committed.
See, e.g.,
2009/10/13 grow
>
> Roger,
> (I will now display my naivety about the development process.)
>
> This seemed like you have got to the underlying bug.
> Do we need to do something else to get this fix into the next Hugin
> release? Does it need to be formally entered in the bug tracker ... I
> vag
On Tue, Oct 13, 2009 at 01:53:51AM -0700, cspiel wrote:
>
> Roger -
>
> On Oct 13, 8:47 am, Rogier Wolff
> wrote:
> > On Mon, Oct 12, 2009 at 04:01:13PM -0700, grow wrote:
> > I have the impression that emblend is just another open source tool
> > that belongs in the hugin package. Or should I
Roger -
On Oct 13, 8:47 am, Rogier Wolff
wrote:
> On Mon, Oct 12, 2009 at 04:01:13PM -0700, grow wrote:
> I have the impression that emblend is just another open source tool
> that belongs in the hugin package. Or should I say just a tool that
> hugin depends on.
1. Enblend and Enfuse are Open
On Mon, Oct 12, 2009 at 04:01:13PM -0700, grow wrote:
>
> Roger,
> (I will now display my naivety about the development process.)
>
> This seemed like you have got to the underlying bug.
> Do we need to do something else to get this fix into the next Hugin
> release? Does it need to be formally
Roger,
(I will now display my naivety about the development process.)
This seemed like you have got to the underlying bug.
Do we need to do something else to get this fix into the next Hugin
release? Does it need to be formally entered in the bug tracker ... I
vaguely remember Harry - I think it
Roger,
WOW!
all the best
George
On 11 Oct, 12:10, Rogier Wolff wrote:
> On Sat, Oct 10, 2009 at 05:14:08PM -0700, grow wrote:
> > output file. The crashes tend to happen as the number of mask and/or
> > the complexity of their shape increases, especially if I request a
> > full-size output
On Sat, Oct 10, 2009 at 05:14:08PM -0700, grow wrote:
> output file. The crashes tend to happen as the number of mask and/or
> the complexity of their shape increases, especially if I request a
> full-size output file.
It seems you have so many (157) seams that some of them are quite
short (only
Let me mention that I'm good at C but I don't have much if any C++
experience. I just know the principles.
On Sat, Oct 10, 2009 at 05:14:08PM -0700, grow wrote:
> >
> > cout << "R11c";fflush (stdout);
> > if (snake->front().first) {
> > cout << "R16";fflush (stdout);
Roger,
Thank you ... I remember you starting on this line of analysis
earlier in the year ... it certainly looks like it is worth
pursuing ... it is consistent with the fact that the problem only
arises when I include images with an Alpha Channel Mask and there is
something (I am not sure what)
On Sat, Oct 10, 2009 at 09:46:37AM -0700, grow wrote:
> I set the stitch going at Hugin's recommended maximum size which was
> roughly 12,080x604. The extra RAM made a huge difference in
Ok, guys. I'm a bit further and it's bedtime for me. If anyone wants
to continue where I left off, feel free
On Sat, Oct 10, 2009 at 09:46:37AM -0700, grow wrote:
> So it is sort of, good-news/bad-news. ... adding extra RAM makes the
> problematic project crash faster!
On my system the "village hotel" project crashes in just over one
minute of wall clock time:
assurancetourix:~/grow> time enblend -
--==**I'm doing my best not to start shouting**==--
George is NOT having a swap space, or RAM limitation problems.
His project has some 24 images.
Hugin calls his enblend step with:
enblend --compression NONE -v --fine-mask --fine-mask -w \
-f12000x6000 -o t3_exposure_00.tif t3_exposure
Stefan,
Thanks for these comments ... I installed the extra RAM this
afternoon ... I'll investigate separately how MacOSX handles overall
virtual memory size ~ I THINK it is set at start-up rather than
installation ... but I have never tried to override the OS
defaults ... so I will investigate.
2009/10/10 Stefan Peter
> In this respect, I think it may be a good idea to check out your swap
> settings. From the fact that you will have to remove 2x256MB, I suppose
> you started wit 0.5 GB of main memory. If the size of the swap space was
> fixed upon installation, you would have a meager
Hi George
Thank you for the info. I' sure that adding 2 GB of RAM will help you
with your current pano. But it will only shift the pano size limit up a
notch, it will not solve the problem per se. I think that it should be
possible to enblend or enfuse images of any size with a given amount of
Date: Fri, 9 Oct 2009 17:33:53 -0700 (PDT)
From: grow
Stefan,
Thanks for your analysis of this.
You asked about memory and responsiveness.
My Mac has 5.5Gb of RAM ... when I have a large stitch to do I
sometime restart the machine and re-open the Hugin project with only
Stefan,
Thanks for your analysis of this.
You asked about memory and responsiveness.
My Mac has 5.5Gb of RAM ... when I have a large stitch to do I
sometime restart the machine and re-open the Hugin project with only
the Stitch tab open and no preview or anything else taking up
memory ... that w
Hi Lukáš
Lukáš Jirkovský schrieb:
> Hi Stefan,
>
>
> Here are my thoughts. Could anyone verify them?
> 1. the problem occurs when image cache is disabled or the limit
> exceeds (or almost fits almost exatly) memory size
> 2. the problem occurs when image cache is enabled but there is not
> enou
Hi Stefan,
2009/10/8 Stefan Peter :
>
> Hi List,
>
> Sorry if the following is "all known by the old hands". Please feel free
> to correct me at your leisure, otherwise I may die dumb ;)
>
> I have downloaded the project in question, and here are some results.
> I used Hugin 2009.2.0.4461 on linu
Hi List,
Sorry if the following is "all known by the old hands". Please feel free
to correct me at your leisure, otherwise I may die dumb ;)
I have downloaded the project in question, and here are some results.
I used Hugin 2009.2.0.4461 on linux X86_64 with 4GB Memory and 8 GB swap
for the fi
Am Thursday 08 October 2009 schrieb Lukáš Jirkovský:
>
> I've tried to reproduce the bug but without success.
>
> I've remapped images. Enblend usually takes about 2-3 GB of memory
> with this pano. I lowered RAM to 256MB and swap from 512MB to 195MB.
> (KDE takes about 200MB itself). I've run en
I've tried to reproduce the bug but without success.
I've remapped images. Enblend usually takes about 2-3 GB of memory
with this pano. I lowered RAM to 256MB and swap from 512MB to 195MB.
(KDE takes about 200MB itself). I've run enblend with: -m 200 -b 8196
to expose the bug even earlier. After
I downloaded the git from danmar_cppcheck
2009/10/8 Lukáš Jirkovský
>
> 2009/10/8 Harry van der Wolf :
> >
> >
> > 2009/10/8 Lukáš Jirkovský
> >>
> >> 2009/10/7 Harry van der Wolf :
> >> > I did another run from the Gui (took a few minutes to find how to
> >> > compile
> >> > that one). That g
2009/10/8 Harry van der Wolf :
>
>
> 2009/10/8 Lukáš Jirkovský
>>
>> 2009/10/7 Harry van der Wolf :
>> > I did another run from the Gui (took a few minutes to find how to
>> > compile
>> > that one). That gave more results:
>>
>> I didn't know that there is a GUI for it.
>>
>>
>
>
> cd into the g
2009/10/8 Lukáš Jirkovský
>
> 2009/10/7 Harry van der Wolf :
> > I did another run from the Gui (took a few minutes to find how to compile
> > that one). That gave more results:
>
> I didn't know that there is a GUI for it.
>
>
>
cd into the gui directory and run "qmake; make; make install".
Thi
2009/10/7 Stefan Peter :
>
> Hi Lukáš
>
> instead of changing the RAM on your PC, you could use a virtual machine
> like vmware or virtualbox. There, you can limit the resources at your will.
>
> Regards
>
> Stefan Peter
>
>
> >
>
Hi Stefan,
I know about this option but I thing changing RAM is fa
2009/10/7 Harry van der Wolf :
> I did another run from the Gui (took a few minutes to find how to compile
> that one). That gave more results:
I didn't know that there is a GUI for it.
>
> [assemble.h:308]: (possible style) Pre-Incrementing variable 'i' is
> preferred to Post-Incrementing
> [as
Hi Lukáš
instead of changing the RAM on your PC, you could use a virtual machine
like vmware or virtualbox. There, you can limit the resources at your will.
Regards
Stefan Peter
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
I did another run from the Gui (took a few minutes to find how to compile
that one). That gave more results:
[assemble.h:308]: (possible style) Pre-Incrementing variable 'i' is
preferred to Post-Incrementing
[assemble.h:308]: (possible style) Pre-Incrementing variable 'i' is
preferred to Post-Incr
Hi Harry,
2009/10/7 Harry van der Wolf :
>
> 2009/10/7 Lukáš Jirkovský
>>
>>
>>
>> I'm not Mac user (although I find it really cool but very expensive)
>> but I may found solution for out of memory problem. I had a discussion
>> about memory and I mentioned these fragmentation problems on OS. An
To answer my own mail. :-)
I just compiled cppcheck on OSX and did a standard run on the enblend trunk.
It displays the following
[./vigra_impex/jpeg.cxx:132]: (error) Class JPEGCodecImpl which is inherited
by class JPEGDecoderImplBase does not have a virtual destructor
[./vigra_impex/jpeg.cxx:132
Hi
I'd be interested in doing some tests, too. I remember having had memory
issues as well, but I was never able to reproduce them reliably here on
Linux / Linux_64 and Windows. Is there someplace one could get the
project in question?
Cheers
Stefan Peter
--~--~-~--~~---
55 matches
Mail list logo
