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
Hi Pablo,
On December 31, 2010 12:12:15 pm Pablo d'Angelo wrote:
> I will investigate and hopefully fix this in the first week in 2011.
Thanks for this.
> Not sure if this is a blocker or not.
I've declared final. There is anyway more code in the integration queue
waiting to be integrated,
On January 1, 2011 06:21:04 am davidefa wrote:
> I think hugin ( or the installer ) should at least add the cpfind
> settings ( usefull in case a previous version was installed ) or have
> the 'clean registry settings' checked by default
the 'clean registry settings' checked by default would remo
On January 1, 2011 06:58:52 am prokoudine wrote:
> On Jan 1, 2:40 am, Yuval Levy wrote:
> > On December 31, 2010 05:39:21 pm prokoudine wrote:
> > > For some reason I don't see cpfind in the list of available detectors.
> > > I'm using rc3.
> >
> > can you post a screenshot, please?
>
> I have n
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
On December 30, 2010 09:49:41 am Harry van der Wolf wrote:
> > > For OSX, in some circumstances, we have a weird bug.
> >
> > is there a ticket in Launchpad for this? what ticket number? if not,
> > can a
> > mac user file one?
>
> Not yet. I can file a ticket but it's kind of uncertain when it
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 Jan 1, 2:40 am, Yuval Levy wrote:
> On December 31, 2010 05:39:21 pm prokoudine wrote:
>
> > For some reason I don't see cpfind in the list of available detectors.
> > I'm using rc3.
>
> can you post a screenshot, please?
I have no foggiest idea how to attach files from google groups web UI.
I installed hugin-2010-4.0rc3 ( 32-bit installer from sourceforge ) on
win-xp ( on that computer was already installed hugin-2010-2.0 )
- the installer had the option 'clean registry settings' unchecked ( I
left unchecked )
- after installation I had the previous settings for cp detectors
( i.e. no
2010/12/31 prokoudine
> On Dec 30 2010, 3:33 am, Yuval Levy wrote:
> > Hi all,
> >
> > is there any reason not to declare 2010.4.0 final?
>
> For some reason I don't see cpfind in the list of available detectors.
> I'm using rc3.
>
> The actual cpfind binary is buiklt and installed. It just does
Hullo Yuv, Alexandre,
On Jan 1, 10:40 am, Yuval Levy wrote:
> On December 31, 2010 05:39:21 pm prokoudine wrote:
[snip]
> > The actual cpfind binary is buiklt and installed. It just doesn't show
> > up in the list. I even clicked Defaults button in Prefs.
>
> if that happened to more than a user,
On December 31, 2010 05:39:21 pm prokoudine wrote:
> For some reason I don't see cpfind in the list of available detectors.
> I'm using rc3.
can you post a screenshot, please?
> The actual cpfind binary is buiklt and installed. It just doesn't show
> up in the list. I even clicked Defaults butt
On Dec 30 2010, 3:33 am, Yuval Levy wrote:
> Hi all,
>
> is there any reason not to declare 2010.4.0 final?
For some reason I don't see cpfind in the list of available detectors.
I'm using rc3.
The actual cpfind binary is buiklt and installed. It just doesn't show
up in the list. I even clicked
Hullo Pablo, All,
On Jan 1, 4:12 am, Pablo d'Angelo wrote:
> Hi all,
>
> I have found that the integrated control point creator fails when images
> are rotated with respect to each other, which might be problematic with
> handheld and wide angle/fisheye images. I haven't tried many panos, so
> I'
Hi all,
I have found that the integrated control point creator fails when images
are rotated with respect to each other, which might be problematic with
handheld and wide angle/fisheye images. I haven't tried many panos, so
I'm not sure if I just was unlucky or if it only affects a few project
2010/12/30 Yuval Levy
> Thanks Harry,
>
> On December 30, 2010 07:41:29 am Harry van der Wolf wrote:
> > To start with: I think too we can go ahead with the final version.
> >
> > For OSX, in some circumstances, we have a weird bug.
>
> is there a ticket in Launchpad for this? what ticket number
Thanks Harry,
On December 30, 2010 07:41:29 am Harry van der Wolf wrote:
> To start with: I think too we can go ahead with the final version.
>
> For OSX, in some circumstances, we have a weird bug.
is there a ticket in Launchpad for this? what ticket number? if not, can a
mac user file one?
To start with: I think too we can go ahead with the final version.
For OSX, in some circumstances, we have a weird bug.
When using the same output name for an image that already exists, Hugin asks
nicely to overwrite the image. However, upon starting the stich it then
fails. When intermediate tif
Hullo Yuval,
On Dec 30, 11:33 am, Yuval Levy wrote:
> Hi all,
>
> is there any reason not to declare 2010.4.0 final?
None of the testing I have done has thrown up any Real significant
issues, apart from bug 692404 which may only cause a crash for me, so
I would think we can go ahead with a final
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
40 matches
Mail list logo
