On Feb 19, 1:09 pm, dkloi dkl...@googlemail.com wrote:
This gives the rule of
thumb FoV=1375/f for the long side of an APS-C sensor.
That would come to about 10.2 degrees for the 134.5 focal length that
the
lens reports. Exactly the same as what Hugin calculates.
Could it be that the lens'
On Nov 22, 5:09 pm, Yuval Levy goo...@levy.ch wrote:
A milestone has been completed and the new tracker is up on
Launchpad (LP) at [0].
I've found an annoying little problem.
In bug # 679162 https://bugs.launchpad.net/hugin/+bug/679162
bruno mentions two other bugs, but LP did recognize
On Nov 23, 11:50 pm, michael crane mick.cr...@gmail.com wrote:
... Yuv...
It is one of those mysteries. I do not know what your motivation is. for 5
years or so I have seen you pontificating as project self appointed leader
and I do not know what has been successful. Please do a feature
On Oct 7, 7:17 pm, Harry van der Wolf hvdw...@gmail.com wrote:
you can download the jpeg images and use ImageMagick's convert or
graphicsmagick gm to convert to 16 bit tiff.
George's dataset is quite large, but you need only about 3 images from
his
dataset to trigger the enblend bug.
Roger.
On Jun 28, 3:00 am, James Legg lankyle...@gmail.com wrote:
I doubt installing the closed source drivers (if they exist for your
system) will help. Don't install the closed source drivers if you don't
want to. I think the problem has already been diagnosed by Seb as Hugin
requiring GLX and
On Jun 27, 6:43 pm, Thomas Steiner finbref.2...@gmail.com wrote:
* sort the controlpoints table by distance by default
* Allow the user to set a preference for what metric to use for
sorting the control points table by default.
* add a matix of fitting quality of images: the image in column
I shot a lot of panos the last vacation. I usuall tilt my camera 90
degrees left, and then shoot the images portrait mode, with about 50%
overlap.
Those images are stored as landscape jpgs, but with the exif-tag that
they are roted 270 degrees. When I view them in gqview they load as
landscape,
My tests show no dependency on 32/64bit. I get very similar crashes
from 32-bit runs. The trace output shows the 32-bit version going
memory-crazy
and running out of memory after 3Gb, the 64bit version goes a bit
further, and
crashes after 12Gb.
Yes, large panos can only be stitched on 64-bit
Kornel Benko,
I have straced the program. All goes nicely for a while, untill all
of a sudden, it starts allocating 1Mb chunks. Then the kernel
says that this is no longer possible, and then it starts allocating
memory in a different way. This all goes nicely, until the total
amount of allocated
Harry,
Maybe I should reply in this thread. I have used strace to trace
what's going on.
My analysis is that enblend suddenly goes from normal to
crazy. In crazy mode, it does nothing but allocate memory
until exhausted. On 32bit OSes it fails after allocating around
3G of adressing space, on
Guys,
I ran strace on the problematic enblend step.
I looked at the output. At 98% through the strace, enblend
suddenly starts
allocating memory, and doing NOTHING else:
It starts with the line:brk(0xa322000)
from there on, it allocates memory until it runs out. Nothing else.
the
My compiler tells me you have a bug in QTVRDecoder.cpp
gCurrentTrackMedia = 'vide';
is not allowed. 'vide' is a single character constant, due to the
single
quotes. Then you have multiple characters... At best the character
constant will be 'v'. If gCurrentTrackMedia is a string, that
On May 4, 4:56 pm, Bruno Postle br...@postle.net wrote:
Thanks, can you report this in the freepv tracker? and note your
compiler as this may not get fixed for a while (gcc 3.4.6 doesn't
complain at all).
c = getchar ();
if (c = EOF) ...
will not generate a warning on older compilers.
Update from my side
After upgrading to ubuntu-jaunty-amd64, I can now run nona on bigger
images.
It used to crash with out of memory, now it runs merrily along using
3.6G
of RAM.
Under 32-bit Linux, I had tried stitching this before, and thought it
was coming
along nicely, but then it
On Apr 21, 1:31 pm, Bart.van.Andel bavanan...@gmail.com wrote:
Although I'm not really into this code, shouldn't a divide by zero
result in NAN instead of INF? Of course the limit of 1/n with n-0 is
INF, but only for n0.
Possibly, both numbers being divided are always positive, so that
+INF
I'm stitching a big pano. In difficult areas I've shot several images,
to be able to chose the one that gives best results (moving people,
and things like that).
However in the mountain of images (83) that I have, it's quite some
work to figure out. So I was thinking If I can set the
16 matches
Mail list logo
