Am Sonntag 08 November 2009 schrieb Yuval Levy:
Bruno Postle wrote:
The default image cache size is very small (75 MB I think), 17 five
megapixel photos will result in churn with images being reloaded.
Hmm the wiki says it is 200MB. Either value is too low for any
modern system, this
Hi,
I get the following:
[...]
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-DHasJPEG -DHasPNG -DHasTIFF -DHasZLIB -D__Ansi__=1 -g -O2 -MT
PTDialogs.lo -MD -MP -MF .deps/PTDialogs.Tpo -c -o PTDialogs.lo
PTDialogs.c
libtool: compile: gcc -DHAVE_CONFIG_H -I.
Bruno Postle wrote:
The default image cache size is very small (75 MB I think), 17 five
megapixel photos will result in churn with images being reloaded.
Wouldn't it be better to have a disk cache if memory cache is full?
Loading the original images can take very long if there are many and
Bruno Postle wrote:
The straighten function doesn't use control points, which is why the
vertical points were ignored - It should probably do something
different (or even nothing at all) when there are vertical or
horizontal control points.
In my opinion straighten should optimize pitch
Yuval Levy wrote:
Apparently autopano-sift found control points on
non-overlapping images: Lots of same looking lego blocks.
how do other tools available to you deal with the same set of images?
Panomatic runs about the same time as autopano-sift and finds about the
same amount of
Erik Krause wrote:
After that hugin optimizes an almost perfect panorama (very slightly
curved up compared to PTGui) - may be due to CPs clustered in the
middle of the overlap (possibly other autopano parameters might
change this).
This can be easily corrected with some vertical control
On Sat 07-Nov-2009 at 20:44 -0500, Yuval Levy wrote:
Bruno Postle wrote:
The default image cache size is very small (75 MB I think), 17 five
megapixel photos will result in churn with images being reloaded.
it seems that the default value is a fixed constant in a header file.
Easy to change,
On Sun 08-Nov-2009 at 12:24 +0100, Erik Krause wrote:
In my opinion straighten should optimize pitch such that the values are
more or less equal - at least for horizontal projections like
cylindrical or equirect. Don't know how to achieve this...
That what it does, it minimises the variation of
Bruno Postle wrote:
In my opinion straighten should optimize pitch such that the values are
more or less equal - at least for horizontal projections like
cylindrical or equirect. Don't know how to achieve this...
That what it does, it minimises the variation of roll and pitch.
Currently
Fixed in rev f312b1189a2d.
/cls
--~--~-~--~~~---~--~~
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:
Jean-Luc Coulon (f5ibh) wrote:
Hi,
I get the following:
[...]
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-DHasJPEG -DHasPNG -DHasTIFF -DHasZLIB -D__Ansi__=1 -g -O2 -MT
PTDialogs.lo -MD -MP -MF .deps/PTDialogs.Tpo -c -o PTDialogs.lo
PTDialogs.c
Bruno Postle wrote:
Hugin deals very good with the above mentioned exposure differences once
exposure is unlinked on Camera and Lens tab. Vignetting, slight white
balance differences and further exposure differences where optimized
very good.
This shouldn't happen, the EV Exposure values
On Sun 08-Nov-2009 at 15:01 +0100, Erik Krause wrote:
However, most panoramas are shot with camera in portrait orientation
anyway. So perhaps this could be the default.
This is a problem, although Hugin works ok with photos taken with
the camera rotated 90°, a lot of the workflow assumes that
Bruno Postle wrote:
In this case I'd consider it better if there was an intermediate manual
step where I could choose image orientation.
..or at least pull it from the EXIF info, as modern cameras have
orientation sensors.
Orientation sensors cause more confusion than they solve. In a
On Sun 08-Nov-2009 at 18:48 +0100, Erik Krause wrote:
Orientation sensors cause more confusion than they solve. In a spherical
the up and down shot have a random orientation. You get mixed
orientation then. And if you shoot RAW it's even worse. Some RAW
converters rotate the image according to
On Sun 08-Nov-2009 at 19:27 +0100, Erik Krause wrote:
Bruno Postle wrote:
There is an 'automatically align images after loading' option, but
this is disabled by default - It didn't seem like a good idea to
configure Hugin so the first user experience was waiting for Align
to finish.
But
Jim Watters wrote:
Jean-Luc Coulon (f5ibh) wrote:
Hi,
I get the following:
[...]
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-DHasJPEG -DHasPNG -DHasTIFF -DHasZLIB -D__Ansi__=1 -g -O2 -MT
PTDialogs.lo -MD -MP -MF .deps/PTDialogs.Tpo -c -o
This is all useful stuff, we could really do with a single place to
collect these issues, maybe the comment pages on the wiki?
On Sun 08-Nov-2009 at 13:31 +0100, Erik Krause wrote:
Setting CPs manually still sucks but this is the case since version 0.1
or whatever I tried first years ago. If I
Hello,everyone.
I tried to develope a image remaping module. So I need to modify the
existing remapping modules's code(like nona,PTmender) to get the
remapping matrix between the images calculated by the nona,and feed
the matrices to the remapping modules I developed.
So where is the code of the
19 matches
Mail list logo
