Roger -
On Oct 17, 11:40 pm, Rogier Wolff rew-googlegro...@bitwizard.nl
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,
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 image.
2009/10/17 grow george...@gmail.com:
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
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
On Sat, Oct 17, 2009 at 05:23:40AM -0700, cspiel wrote:
Roger -
On Oct 16, 11:53 am, Rogier Wolff rew-googlegro...@bitwizard.nl
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
Hello Roger -
On Oct 15, 5:29 pm, Rogier Wolff rew-googlegro...@bitwizard.nl
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
On Thu, Oct 15, 2009 at 11:24:10PM -0700, cspiel wrote:
Hello Roger -
On Oct 15, 5:29 pm, Rogier Wolff rew-googlegro...@bitwizard.nl
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.
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 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
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
Andrew -
On Oct 14, 5:49 pm, Andrew Mihal andrewcmi...@gmail.com 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.
2009/10/10 Rogier Wolff rew-googlegro...@bitwizard.nl
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
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
megabytes
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
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
2009/10/15 Rogier Wolff rew-googlegro...@bitwizard.nl
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
2009/10/15 Yuval Levy goo...@levy.ch
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
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
On Oct 13, 10:52 pm, Harry van der Wolf hvdw...@gmail.com 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
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
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
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 -
On Oct 13, 8:47 am, Rogier Wolff rew-googlegro...@bitwizard.nl
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.
On Tue, Oct 13, 2009 at 01:53:51AM -0700, cspiel wrote:
Roger -
On Oct 13, 8:47 am, Rogier Wolff rew-googlegro...@bitwizard.nl
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
2009/10/13 grow george...@gmail.com
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
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
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);
//
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
Roger,
WOW!
all the best
George
On 11 Oct, 12:10, Rogier Wolff rew-googlegro...@bitwizard.nl 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
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
2009/10/10 Stefan Peter s_pe...@swissonline.ch
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
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
--==**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
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
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,
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
Hi Stefan,
2009/10/8 Stefan Peter s_pe...@swissonline.ch:
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
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
Date: Fri, 9 Oct 2009 17:33:53 -0700 (PDT)
From: grow george...@gmail.com
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
2009/10/7 Harry van der Wolf hvdw...@gmail.com:
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
2009/10/7 Stefan Peter s_pe...@swissonline.ch:
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
2009/10/8 Lukáš Jirkovský l.jirkov...@gmail.com
2009/10/7 Harry van der Wolf hvdw...@gmail.com:
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
2009/10/8 Harry van der Wolf hvdw...@gmail.com:
2009/10/8 Lukáš Jirkovský l.jirkov...@gmail.com
2009/10/7 Harry van der Wolf hvdw...@gmail.com:
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
I downloaded the git from danmar_cppcheck
2009/10/8 Lukáš Jirkovský l.jirkov...@gmail.com
2009/10/8 Harry van der Wolf hvdw...@gmail.com:
2009/10/8 Lukáš Jirkovský l.jirkov...@gmail.com
2009/10/7 Harry van der Wolf hvdw...@gmail.com:
I did another run from the Gui (took a few
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
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 enblend
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
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
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
Hi Harry,
2009/10/7 Harry van der Wolf hvdw...@gmail.com:
2009/10/7 Lukáš Jirkovský l.jirkov...@gmail.com
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
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
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
52 matches
Mail list logo
