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
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
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
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.
Bruno Postle wrote:
> >Alignment is automatic if I press "1. Load images". No need for an
> >additional button in a straight forward workflow.
>
> 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 H
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 accordin
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. I
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 tha
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 Expos
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.
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:
http://wiki.panotools.org/Hugin
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.
>
>
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
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 cha
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
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
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 pit
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
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. -DH
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 syst
20 matches
Mail list logo
