On Sat 22-Jan-2011 at 23:57 -0800, kfj wrote:
In theory this is a fine idea. But keep in mind one point that noone
ever adresses in this whole discussion: The treatment of FOV in hugin
is, if I am interpreting the mechanism right, fundamentally flawed.
The only thing that is asked for and proces
On Sun 23-Jan-2011 at 07:29 +0100, Pablo d'Angelo wrote:
A good option for clustering would be to split the panorama in
many smaller parts (tiles, using the crop feature of hugin), and
distribute these.
gigatile is an experimental tool for doing this, it splits the Hugin
.pto project into 4
Hi mac users,
Another Hugin build. It's going fast last 2 weeks.
This one contains the enhanced cpfind with the new ransac mode for cpfind to
improve CP detection for fisheye lenses.
See Pablo's mail[0].
Note: I did not change the cpfind preferences. If you want to experiment you
need to add the
Hi Yuv,
Am 23.01.2011 15:10, schrieb Yuval Levy:
Michel's test/challenge was for this to work "out of the box" and I did not
have time to investigate further. I realize now when running Exiftool that it
reports 0mm focal distance; and that Hugin sets the focal length to 50mm by
default, even i
Hi Pablo,
On January 23, 2011 02:45:55 am Pablo d'Angelo wrote:
> > http://www.sendspace.com/file/vnek81
>
> I tried the set with the following steps:
Thanks.
> With assistant:
> 1. load images, set 14 mm rectilinear
> 2. align
> 3. straighten by drag in preview
>
> http://www.flickr.com/ph
On 23 Jan., 11:19, kfj <_...@yahoo.com> wrote:
> It doesn't even have to be an extension. It's enough if the program
> uses libhuginbase.so and if it's started by python as a subprocess. If
> that helps, I can put a demo online.
hmmm... tricky. Currently I can't reproduce the bug with a subproc
On 23 Jan., 11:09, Pablo d'Angelo wrote:
> Hmm, not sure about that. Maybe some problems with static initialization
> and linking order? Does the problem also occur for a small dummy
> extension (thus running in the same process as python) using c++, or
> does it only occur from within hugin?
Hi Kay,
Am 23.01.2011 09:32, schrieb kfj:
cerr<< "WARN:"<< "blah blah"<< endl ;
All I get to see in Python is
WARN: Speicherzugriffsfehler
(that is, memory error.) - so I get to see the first string 'WARN:'
but then the crash happens, which looks like an error in
cerr.operator<<(). The st
On 23 Jan., 09:16, "T. Modes" wrote:
> Nice to hear that it works also on unix. I fixed the minor error.
Hi Thomas!
Do you know if anyone has tried the thing out on MacOS? Now that the
compile is running quite smoothly it would be nice to be confident it
will run on all three platforms.
Kay
Hi all!
I have a problem with hugin outputting data to cerr when I use it from
Python, but it may point to a general problem. Hugin uses a set of
macros to produce warning and error output when in debug mode.
Recently I've experienced two occasions when these macros weren't made
dependent on the s
Hi Kay
> Your solution absolutely does the trick. I'm no good at cmake, and
> seeing what you did with it I'm duly impressed. I feel this is a nice
> and clean solution now; it worked on my Ubuntu system, just a tiny
> error in CMakeLists.txt - the directive for the gcc preprocessor is -E
> and no
11 matches
Mail list logo
