On 1 January 2011 20:32, Yuval Levy wrote:
> On January 1, 2011 11:05:34 am Felix Hagemann wrote:
>> Stitching a recent full sperical nighttime pano using 3 exposures (-2,0,+2)
>> the blended and fused pano was a lot sharper than the fused and blended
>> one.
>
> any camera movement between exposur
Hi Rick,
On January 1, 2011 11:23:52 am RueiKe wrote:
> The biggest advantage I see in blending first is just how much use you
> can get out of the blended exposure layers.
thank you for making a very convincing use case for the 'blend before fuse'
process. it is definitely worth supporting wit
On January 1, 2011 11:05:34 am Felix Hagemann wrote:
> Stitching a recent full sperical nighttime pano using 3 exposures (-2,0,+2)
> the blended and fused pano was a lot sharper than the fused and blended
> one.
any camera movement between exposures, such as a vibrating tripod or even hand
held s
Hi Yuv,
The biggest advantage I see in blending first is just how much use you
can get out of the blended exposure layers. Since I generate them for
each project, it makes things simpiler to use them in the enfusion.
Some examples:
1) Use layers in gimp to remove movement of faces by overlay face
On 1 January 2011 16:33, Yuval Levy wrote:
>
> What advantage do you see in first blending the exposure layers and then
> enfusing, rather than doing it the other way around (which is computationally
> lighter)?
While I'm not Rick who was initially adressed above, I'd like to share a recent
experi
On January 1, 2011 07:03:16 am RueiKe wrote:
> I just wanted to report back with my latest attempt with 2010.4.
Thanks for the report, Rick.
> I have gone through 2 cases making sure I did not optimize translation
> and everything worked fine!
Sometimes less is more, isn't it? That's where our
I just wanted to report back with my latest attempt with 2010.4. I
have gone through 2 cases making sure I did not optimize translation
and everything worked fine! Much faster than previous releases and
nicer interface! Only 2 items that are of some concern. For some
reason whenever nona runs,
On 29 Dez., 00:50, Rogier Wolff wrote:
> What I meant is that from a preliminary optimization, the overlapping
> areas of two images is aproximated. Next cpfind would be asked to find
> key/control points in JUST this overlapping area. The sieve1*
> parameters would ensure that we get a uniform
On Tue, Dec 28, 2010 at 12:10:13PM -0500, Yuval Levy wrote:
> On December 27, 2010 08:32:49 am Rogier Wolff wrote:
> > Control point finders are apparently quite likely to find a bunch of
> > control points in the foreground.
>
> no - there is no particular likelihood. they find CPs indiscrimina
On December 27, 2010 08:32:49 am Rogier Wolff wrote:
> Control point finders are apparently quite likely to find a bunch of
> control points in the foreground.
no - there is no particular likelihood. they find CPs indiscriminately on the
whole surface of the picture without any depth information
On December 27, 2010 06:07:55 am kfj wrote:
> On 27 Dez., 10:45, "Bruno Postle" wrote:
> > We should simply remove the 'everything' preset, it shouldn't exist.
>
> I think it shows yet again that doing panoramas and mosaics are quite
> different processes.
Hugin is a Swiss Army Knife tool that c
On Dec 27, 7:38 am, Yuval Levy wrote:
> @Matthew (or any of the Windows builders): can you please check if the
> removal of autopano-mockup in [0] affects the Windows installer?
The installer still works fine.
Matthew
--
You received this message because you are subscribed to the Google Group
On Mon, Dec 27, 2010 at 07:50:44AM -0500, Yuval Levy wrote:
> > For this project, the intital alignment looked fine. It was when I
> > removed the outlier control points and realigned when I ran into
> > problems.
>
> removing the outlier is a blind process as well. If you have, for example, a
Hi Yuv,
Yes, I am glad to be back to this forum after having to step away for
about 6 months. Had too much going on with a change in my job! I
have been working through about 3000 photos from a recent trip to
Dresden, so my computer has been non-stop with projects for a while
now. My photos can
Hi Rick,
On December 27, 2010 06:20:34 am RueiKe wrote:
> Thanks Yuv for your very detailed response!
happy to read that it helped.
> I can usually acheive about 0.3 pixel mean error for a 16k wide pano.
beware of this metrics. It is blind to the quality of the CPs and thus to the
real qual
On December 27, 2010 05:48:12 am kfj wrote:
> Yuval, seeing this, I suppose we nedd an undummify command as well (or
> call it a smartener ;-)
good catch.
> Doing a replace-all '_dummy.jpg' -> '' shouldn't be to hard... but
> maybe there's a good way to generally deal with pre/suffixes in the
> p
Hi Kay,
I typically add as many CP as I can and after the first alignment I
will delete those that are definitely bad. Usually, there will be
many points with errors of several thousand pixels. You can usually
see a distribution change between normal and outliers. After this, I
will set the Nad
n December 27, 2010 04:45:00 am Bruno Postle wrote:
> We should simply remove the 'everything' preset, it shouldn't exist.
done. will issue a release candidate later today.
@Matthew (or any of the Windows builders): can you please check if the
removal of autopano-mockup in [0] affects the Wind
On 27 Dez., 12:20, RueiKe wrote:
>
> The project did use a pano head, so all stacks will be aligned with
> the exception of the nadir, which may have some slight movement, so I
> add control points to align the Nadir and specify a different lens
> after the intial alignment. I am still using au
Thanks Yuv for your very detailed response!
The project did use a pano head, so all stacks will be aligned with
the exception of the nadir, which may have some slight movement, so I
add control points to align the Nadir and specify a different lens
after the intial alignment. I am still using aut
On 27 Dez., 10:45, "Bruno Postle" wrote:
> It seems that this is a common problem, users of older versions became
> accustomed to using the 'optimize everything' preset, but this is almost
> always the wrong thing to do now we have XYZ parameters.
>
> We should simply remove the 'everything' p
On 27 Dez., 05:39, Yuval Levy wrote:
> Attached is my (blind) result. Please confirm if it is garbage or not, and if
> you can improve on it by pruning CPs, etc.
> ...
> dummified_DR13_Rev1.pto
> 638KAnzeigenHerunterladen
Yuval, seeing this, I suppose we nedd an undummify command as well (or
It seems that this is a common problem, users of older versions became
accustomed to using the 'optimize everything' preset, but this is almost always
the wrong thing to do now we have XYZ parameters.
We should simply remove the 'everything' preset, it shouldn't exist.
--
Bruno
--
You receiv
Hi Yuv,
My attempt to use the latest build on a typical complex project
indicates significant issues. I understand that my use case of 217
images is not typical, but I think it has always been a critical
feature for hugin to be able to handle very large projects. I have
gone back to 2009.4 with
24 matches
Mail list logo
