Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Felix Hagemann]

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 exposures, such as a vibrating tripod or even hand
> held shot?

No, carefully shot with a NN3 on a sturdy tripod. Also I seem to
remember that the sharpness differences occured in a few places, so
one accidental kick to the tripod should not have been the cause. I'll
try to investigate further next week.

Felix

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Yuval Levy]

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 with a more explicit options on 
the stitcher tab (or whatever will be derived out of it in the next GUI 
iteration).

can you please file this as a report in the tracker so that it won't get 
forgotten?

thanks
Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Yuval Levy]

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 shot?

the fuse before blend process works best only if the stack to be fused is 
perfectly aligned.

Yuv


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[RueiKe]

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 faces
from nominal exposure layers like in this example:
http://www.flickr.com/photos/rueike/5306085871/
2) Using the exposure layers for hdr layers to overlay with the
enfusion for better contrast
3) Using various exposure layers overlayed and masked in gimp for
improved dynamic range.  This examples uses both 2 & 3:
http://www.flickr.com/photos/rueike/5046727075/
4) Running enfuse offline, experimenting with exclusion of layers and
adjusting weightings for better results.

I also convinced myself that blended then fused gives better results
than fused then blended in this example: 
http://www.flickr.com/photos/rueike/4321371747/

Regards,
Rick

On Jan 1, 11:33 pm, Yuval Levy  wrote:
> 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 interface still sucks at
> guiding users who are between being an occasional user and a power user.
>
> While we muse about how to fix it, the golden rule for wannabe-power-users:  
> more is not always better...
>
> > nicer interface!  Only 2 items that are of some concern.  For some
> > reason whenever nona runs, it pops a command window which becomes the
> > active window, which makes it difficult to work on other items.
>
> Must be a windows build issue.  tifflib if I am not mistaken. �...@matthew?
>
> > I have been using the previously available option for a blended then
> > fused pano and keeping the blended exposure layers.  It doesn't seem
> > to be an option in this release, but it is easy to just enfuse the
> > blended expsosures layers afterward in the command line.
>
> The Stitcher tab was incredibly confusing.  James has cleared some of that
> confusion, and part of it was to remove inefficient options.
>
> 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)?
>
> > I feel bad that I have gotten behind on the Traditional Chinese
> > translation.  I will try to have updated for the next release...
>
> Don't worry.  The project accepts translations on an ongoing basis.  Feel free
> to contribute whenever you have time.
>
> Yuv
>
>  signature.asc
> < 1KViewDownload

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Felix Hagemann]

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
experience:
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.
I haven't had the time to check with different panos yet. Currently
I'm travelling
and have no access to the pto and the images but I think I should be able to
dig them out next week, if anybody should be interested.

Happy New Year and congratulations for the release,
Felix

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[Yuval Levy]

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, so 2011.0.0 should follow pretty soon.

The plan now is to merge the gsoc2010_panorama_overview branch.  It will take 
some time, and hopefully will give you enough time to investigate and fix what 
you found.

Next steps:
1- update gsoc2010_panorama_overview with the changes from default
2- check that gsoc2010_panorama_overview builds and works on all platform
3- merge gsoc2010_panorama_overview into default
4- branch out 2010.0 from default


> I quickly skimmed the hugin list, but
> haven't found much on the cpfind performance, except that it didn't work
> for Jan Martin.

whoever has issues should register them in the tracker [0] to make sure they 
don't get overlooked.  

Yuv

[0] 


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[Yuval Levy]

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 remove more than just 
the settings.  better not.

I don't know the current installer technology, but adding a cpfind settings 
would mean reading a registry key to check if it exists, and if it does not, 
write it.  patches welcome.

Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[Yuval Levy]

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 no foggiest idea how to attach files from google groups web UI.

oh, you're using the web UI?  you're in for a nasty surprise when [0] will 
become default.  Less functionality for more consumer-hostile JavaScript and 
other waste of CPU cycles.  I strongly advise anybody to use the mailing list 
interface.

 
> > what happens if you change locale?
> 
> Nothing. But completely removing ~/.hugin helps.

can you still check what permission you had on ~/.hugin ?

I'm happy that you solved your immediate problem, but I would have preferred 
to understand why it happened in the first place so that we can better help 
the next user with similar experience.

Yuv


[0] https://groups.google.com/forum/?pli=1#!forum/hugin-ptx


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Yuval Levy]

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 interface still sucks at 
guiding users who are between being an occasional user and a power user.

While we muse about how to fix it, the golden rule for wannabe-power-users:  
more is not always better...


> nicer interface!  Only 2 items that are of some concern.  For some
> reason whenever nona runs, it pops a command window which becomes the
> active window, which makes it difficult to work on other items.

Must be a windows build issue.  tifflib if I am not mistaken.  @Matthew?


> I have been using the previously available option for a blended then
> fused pano and keeping the blended exposure layers.  It doesn't seem
> to be an option in this release, but it is easy to just enfuse the
> blended expsosures layers afterward in the command line.

The Stitcher tab was incredibly confusing.  James has cleared some of that 
confusion, and part of it was to remove inefficient options.

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)?

 
> I feel bad that I have gotten behind on the Traditional Chinese
> translation.  I will try to have updated for the next release...

Don't worry.  The project accepts translations on an ongoing basis.  Feel free 
to contribute whenever you have time.

Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[Yuval Levy]

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 happens and
> why it happens. But your right: it's better to file a ticket and narrow the
> options while analyzing.
> I will file a ticket, either tonight or tomorrow.

it would be nice of some of the OSX users that rely on your building work 
would do this.

Yuv


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[RueiKe]

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, it pops a command window which becomes the
active window, which makes it difficult to work on other items.  Also,
I have been using the previously available option for a blended then
fused pano and keeping the blended exposure layers.  It doesn't seem
to be an option in this release, but it is easy to just enfuse the
blended expsosures layers afterward in the command line.

I feel bad that I have gotten behind on the Traditional Chinese
translation.  I will try to have updated for the next release...

Thanks!
Rick

On Dec 27 2010, 8:50 pm, Yuval Levy  wrote:
> 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 quality of the panorama, and I think that if we want to make Hugin more
> user friendy, we should remove the number all together and replace them with
> "likely to be very good / well / poorly / badly aligned" instead.
>
> I've had a long discussion about this metrics with somebody else on this list
> a few months back.
>
> > 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
> lot of features in the foreground that "captures" the majority of the CPs, the
> background CPs will be declared outliers, even if it is known that the further
> away from the camera a CP is located, the less sensitive it is to parallax and
> other negative factors.  And if those front features are in movement, the
> statistics are toast.
>
> > Seems like my choice for optimization parameters may have
> > caused the problems.
>
> probably the immediate one, yes.  It seems to me that you have the potential
> to bring your process to the next level and if you want you will find helpful
> feedback here on the list.
>
> > Let me try it again when I finish my current
> > project.  Should be able to report back in a few days.  If I continue
> > to have problems, I will open a bug report.
>
> OK.  Looking forward for your report - preferably a link to your flickr
> gallery ;-)
>
> Yuv
>
>  signature.asc
> < 1KViewDownload

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final

[prokoudine]

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.

> what happens if you change locale?

Nothing. But completely removing ~/.hugin helps.

Alexandre

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final

[davidefa]

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 cpfind )
- after loading default preferences I have 3 cpfind settings ( cpfind,
cpfind + celeste, cpfind multirow )

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

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[Harry van der Wolf]

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 doesn't show
> up in the list. I even clicked Defaults button in Prefs.
>
> Alexandre
>
>
Did you try to remove the .hugin preferences file completely?
On OSX we have experienced throughout the several hugin versions that it
sometimes helps to completely the file after a new version was released.

Harry

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final

[Tduell]

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, it would be a show stopper. can anybody
> confirm?

I have checked my build of RC3, removing my .hugin and loading default
Control Point Detectors.
"Hugins CPFind" and "Hugins CPFind + Celeste (slower but more
accurate, no cps on clouds)" are available.
So the RC3 source is correct here.
Might help narrow it down.

Cheers,
Terry

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[Yuval Levy]

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 button in Prefs.

if that happened to more than a user, it would be a show stopper. can anybody 
confirm?

what happens if you change locale?

Yuv


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Declaring 2010.4.0 final

[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 doesn't show
up in the list. I even clicked Defaults button in Prefs.

Alexandre

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final

[Tduell]

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'm not sure if I just was unlucky or if it only affects a few projects.

I have tested cpfind on a few (half dozen or thereabouts) handheld
projects and not had any trouble.
I haven't checked the relative angles between images, but would guess
that they are probably average.

Cheers,
Terry

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final

[Pablo d'Angelo]

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 projects.


I will investigate and hopefully fix this in the first week in 2011. Not 
sure if this is a blocker or not. I quickly skimmed the hugin list, but 
haven't found much on the cpfind performance, except that it didn't work 
for Jan Martin.


ciao
 Pablo

Am 30.12.2010 01:33, schrieb Yuval Levy:

Hi all,

is there any reason not to declare 2010.4.0 final?

I see a Windows distribution (thank you Matthew), an OSX distribution (thank
you Harry), a Fedora distribution (thank you Terry).

I see a Debian experimental distribution [0] and must have missed Andreas
announcement.  Will get Ubuntu going in the coming hours.

My intention is to declare 2010.4.0 final December 31 before popping the
Champagne.

Yuv


[0]


--
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[Harry van der Wolf]

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?  if not, can
> a
> mac user file one?
>
>
>
Not yet. I can file a ticket but it's kind of uncertain when it happens and
why it happens. But your right: it's better to file a ticket and narrow the
options while analyzing.
I will file a ticket, either tonight or tomorrow.

Harry

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[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?  if not, can a 
mac user file one?


> No show stopper, just annoying.

OK

Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Declaring 2010.4.0 final

[Harry van der Wolf]

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 tiff files are still in place, the error also
occurs for these intermediate tiffs.
PTBatcherGui does this OK.
Now this error has been aways AFAIK, and has now returned.

The reason(s) for this failure is still unknown (to me, that is). It was
also there before the makefile implementation, and was "solved" or just went
away. Now, with the makefile stitching it is suddenly back, so I think it
has nothing to do with the makefile.
Either it is an error in:
- the pto: not closed/opened properly?
- a wrong file handle for the image file?

It is not a serious error and not reproducably occuring although if it
happens with one file(name) it happens reproducably with that file(name),
but it's annoying. Also the fact that it's now back puzzles me. I did not
have it yet myself, but I heard it via a pm from another user.

No show stopper, just annoying.


Harry

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final

[Tduell]

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 release.

Cheers,
Terry

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[kfj]

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 blanket of control
> points over the overlapping area of these two images.

Rogier, are you aware of the feature to 'remove control points in
masks'? It is in the menu, but there's no button on any of the tabs,
so I consistently overlooked it until I was pointed to it by another
post. This allows you to quickly mask a part of your image just for
the purpose, throw out the CPs in that mask and then remove the mask
again.

Kay

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Rogier Wolff]

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 indiscriminately on 
> the 
> whole surface of the picture without any depth information.

You're right. But with "apparently quite likely" I meant: "it happens
in practice". I often get lots of them in the foreground.  Apparently
the grass has higher contrasts or something resulting in a preference
for those control points.

> > So after one run of finding control points and aligning the pano,
> > would it be possible to run a CP finder on just the overlapping image
> > parts?
> 
> I see no benefit in this.  There is no guarantee that in the part of the 
> image 
> that is overlapping depth is distributed any better than in the rest of the 
> image; and parallax would have to be really massive to keep the identified 
> foreground features out of the overlap area.

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 blanket of control
points over the overlapping area of these two images.

Roger. 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Yuval Levy]

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.

CP finding could be improved if we could add depth information to the process 
and either mask out the near from the far; or, better, qualify its CPs with 
its depth.


> Which especially with hand-shot panos are quite worthless.

true.

 
> So after one run of finding control points and aligning the pano,
> would it be possible to run a CP finder on just the overlapping image
> parts?

I see no benefit in this.  There is no guarantee that in the part of the image 
that is overlapping depth is distributed any better than in the rest of the 
image; and parallax would have to be really massive to keep the identified 
foreground features out of the overlap area.

Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Yuval Levy]

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 catered to quite different processes 
even before.  E.g. HDR.  The question is where to draw the limit: in the tool 
(by restricting it to only do sensible things), or at the user (by expecting 
him to understand the tool and only do sensible things with it)?  I prefer the 
second approach. 


> Anyway, removing the 'everything' preset is possibly a good idea for
> now. How about making the presets customizable, like the presets for
> the CPGs?

not enough.  like CP generation, optimization requires top level strategies 
too because proper optimization is not achieved in a single run.  Also, the 
outcome of the optimization is influenced by the status from which it is 
started, much more than CP generation where starting from the bare sequence of 
images is enough in most cases.

Yuv


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Matthew Petroff]

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 Groups 
"Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Rogier Wolff]

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 
> lot of features in the foreground that "captures" the majority of the CPs, 
> the 
> background CPs will be declared outliers, even if it is known that the 
> further 
> away from the camera a CP is located, the less sensitive it is to parallax 
> and 
> other negative factors.  And if those front features are in movement, the 
> statistics are toast. 

Which brings me to an idea I've had for a while 

Control point finders are apparently quite likely to find a bunch of
control points in the foreground. Which especially with hand-shot
panos are quite worthless.

So after one run of finding control points and aligning the pano,
would it be possible to run a CP finder on just the overlapping image
parts?

The thing is we KNOW they are quite likely to overlap, so we can work
with less "outstanding" control points because the points we take only
have to be unique against the same image area on the other image, not
against all other parts of all other images!

And matching control points is also quick because we have only a small
set to match against.

This would really clean up the control points. One of the things we
could do to get an even distribution of control points is to put a 3x3
window on the overlapping area and try to find control points in each
of the nine areas.

Could this be a GSOC project?

Rogier. 




-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[RueiKe]

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 be found along with some description of the
process here: http://www.flickr.com/photos/rueike/

Regards,
Rick

On Dec 27, 8:50 pm, Yuval Levy  wrote:
> 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 quality of the panorama, and I think that if we want to make Hugin more
> user friendy, we should remove the number all together and replace them with
> "likely to be very good / well / poorly / badly aligned" instead.
>
> I've had a long discussion about this metrics with somebody else on this list
> a few months back.
>
> > 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
> lot of features in the foreground that "captures" the majority of the CPs, the
> background CPs will be declared outliers, even if it is known that the further
> away from the camera a CP is located, the less sensitive it is to parallax and
> other negative factors.  And if those front features are in movement, the
> statistics are toast.
>
> > Seems like my choice for optimization parameters may have
> > caused the problems.
>
> probably the immediate one, yes.  It seems to me that you have the potential
> to bring your process to the next level and if you want you will find helpful
> feedback here on the list.
>
> > Let me try it again when I finish my current
> > project.  Should be able to report back in a few days.  If I continue
> > to have problems, I will open a bug report.
>
> OK.  Looking forward for your report - preferably a link to your flickr
> gallery ;-)
>
> Yuv
>
>  signature.asc
> < 1KViewDownload

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Yuval Levy]

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 quality of the panorama, and I think that if we want to make Hugin more 
user friendy, we should remove the number all together and replace them with
"likely to be very good / well / poorly / badly aligned" instead.

I've had a long discussion about this metrics with somebody else on this list 
a few months back.


> 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 
lot of features in the foreground that "captures" the majority of the CPs, the 
background CPs will be declared outliers, even if it is known that the further 
away from the camera a CP is located, the less sensitive it is to parallax and 
other negative factors.  And if those front features are in movement, the 
statistics are toast. 


> Seems like my choice for optimization parameters may have
> caused the problems.

probably the immediate one, yes.  It seems to me that you have the potential 
to bring your process to the next level and if you want you will find helpful 
feedback here on the list.


> Let me try it again when I finish my current
> project.  Should be able to report back in a few days.  If I continue
> to have problems, I will open a bug report. 

OK.  Looking forward for your report - preferably a link to your flickr 
gallery ;-)

Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Yuval Levy]

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
> ptoimggen.py script, I'll give it  some thought.

I appreciate if you can, Kay.  The only thing on my Hugin radar screen at the 
moment is getting the next RC out, and the day has just started here, but it 
is shaping to be an interesting day as my son's cousins finally joined us 
after being grounded with antibiotics for the last four days.

Yuv


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[RueiKe]

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 Nadir to a unique lens number and iteratively opimize
everything and remove outliers.  I will inspect a sample of the
outliers to make sure they are really bad each time.  In some
situations, cloud movement will cause good points to have higher
errors, so I am careful not to delete too many good points.  I can
usually get a defect free stitch with a 21mm lens using this
technique, but I agree there are probably simpiler methods.

Regards,
Rick

On Dec 27, 7:48 pm, kfj <_...@yahoo.com> wrote:
> 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 autopano-sift-c.  Yes, I
> > use a lot of control points then delete many during the processes of
> > successive optimizations.  I can usually acheive about 0.3 pixel mean
> > error for a 16k wide pano.
>
> You may loose more than you gain by throwing out a great number of
> CPs. Often the 'best' CPs are clustered in unproblematic areas,
> particularly if you are using a fisheye and/or the lens isn't
> perfectly calibrated. If you just throw out everything above a
> threshold, you may end up with insufficient area coverage. Don't be
> too keen on minimizing the mean error, it's not a measure for the
> quality of your final panorama, just an indicator about the CPs. In my
> experience it is useful to throw out only CPs which are obviously way
> off or wrong (like, the worst 10%, or everything above 10). The
> optimizer is a very clever thing and can well cope with outliers.
>
> Kay

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Yuval Levy]

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 Windows installer?

that said:  I think it would not have prevented Rick's case.  From dissecting 
the pto file he posted it looks as if he used the tick-all boxes in the custom 
optimization.  unless we have a bug in loading the project file.

Yuv

[0] http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/rev/b8615c66d28b



signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[kfj]

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 autopano-sift-c.  Yes, I
> use a lot of control points then delete many during the processes of
> successive optimizations.  I can usually acheive about 0.3 pixel mean
> error for a 16k wide pano.

You may loose more than you gain by throwing out a great number of
CPs. Often the 'best' CPs are clustered in unproblematic areas,
particularly if you are using a fisheye and/or the lens isn't
perfectly calibrated. If you just throw out everything above a
threshold, you may end up with insufficient area coverage. Don't be
too keen on minimizing the mean error, it's not a measure for the
quality of your final panorama, just an indicator about the CPs. In my
experience it is useful to throw out only CPs which are obviously way
off or wrong (like, the worst 10%, or everything above 10). The
optimizer is a very clever thing and can well cope with outliers.

Kay

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[RueiKe]

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 autopano-sift-c.  Yes, I
use a lot of control points then delete many during the processes of
successive optimizations.  I can usually acheive about 0.3 pixel mean
error for a 16k wide pano.

For this project, the intital alignment looked fine.  It was when I
removed the outlier control points and realigned when I ran into
problems.  Seems like my choice for optimization parameters may have
caused the problems.  Let me try it again when I finish my current
project.  Should be able to report back in a few days.  If I continue
to have problems, I will open a bug report.  Thanks again for your
very detailed response!

Regards,
Rick

On Dec 27, 12:39 pm, Yuval Levy  wrote:
> Hi Rick,
>
> On December 26, 2010 09:33:28 pm RueiKe wrote:
>
> > My attempt to use the latest build on a typical complex project
> > indicates significant issues.
>
> I downloaded your PTO file but did not have time to look at it right away and
> now I don't have the "significant issues" you mentioned present.  However I
> played with it and found no "significant issue".
>
> The project loaded well (with placeholder images, that is).  The application
> is responsive.
>
> I see 31 stacks defined.  I see a lot of CPs.  I don't recall how you
> generated them; nor can I visually judge their quality.  I find the quantity
> excessive - personally I would do such a project with less than 200 CPs, while
> you have more than 9000.  Even if this was about stitching 217 individual
> frames (single exposures; or misaligned stacks), 1000-1500 CPs would be more
> than enough.
>
> I assume that the stacks are perfectly aligned (shot on a tripod or so), and
> that you want to tonemap a resulting HDR.  Have you considered merging each of
> the stacks first into an HDR image first using pfstools or LuminanceHDR?  This
> would cut computational work by as much as 80%.
>
> It would be helpful if you could detail the issues in ticket(s) on the bug
> tracker so that when trying to figure them out, developers don't have to
> scramble around for information.
>
> I am working on this in my spare time.  I keep folders on my HDD - one folder
> per issue - and the name of the folder is usually the number of the tracker
> ticket (but in this case it was your pseudonym because there was no tracker
> ticket).  It takes only a few seconds to be back on the right page that way.  
> It takes much longer if there is no ticket.
>
> > I understand that my use case of 217 images is not typical
>
> It may not be typical in the sense that it is not the average project;  and
> that probably there is a more efficient way to deal with the project; but it
> is not unique in terms of size.  There are other users processing that amount
> of images and more.
>
> > , but I think it has always been a critical feature for hugin to be able to
> > handle very large projects.
>
> "critical feature" is a bit of an inflated qualification.  There has never
> been any kind of warranty, implied or explicit, that Hugin is fit for any
> purpose.  It is true that Hugin has been handling successfully projects of
> this size and larger in the past; that we take seriously reports such as yours
> and try to help you get the most out of Hugin.  But a single report from a
> single user is never critical until confirmed.
>
> If the report was in the bug tracker, other users experiencing the same issue
> could confirm; add their own experiences and observations; and we would get a
> better picture of whether this is critical or not and what we are dealing
> with.
>
> The basic assumption for now is that this is a specific issue of your specific
> situation.  And with all due respect, even if you say that this happens to you
> in a number of projects (like Milkman with the Samyiang lens),  the basic
> assumption stays that it is an issue of your setup and not of the Hugin code. 
>  
> To be considered an issue with the Hugin code, it must be confirmed by more
> than one user.  This is what we have triagers working on the bug tracker for.
>
> > I have gone back to 2009.4 with no issues.
>
> That's a long way back.  I would be surprised that an issue is hiding in the
> code for one year with no report.  You will forgive me for thinking that the
> issue is on your end rather in the Hugin code until proven different.
>
> > Let me know if there is any other
> > testing needed for the issue I described the the RC1 thread.
>
> I see that the optimizer is set to optimize custom parameters.  The choice of
> custom parameters is to optimize one exposure for each stack; and for each of
> those exposures it is set to optimize y/p/r/X/Y/Z.  Plus the lens parameters. 
>  
> all in one go.  This is calling for troubles.
>
> I assu

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[kfj]

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' preset, it shouldn't exist.

I think it shows yet again that doing panoramas and mosaics are quite
different processes. Since the introduction of mosaic mode, the
options in the optimizer tab have multiplied in an attempt to cater
for every possible combination. I have had very limited success with
translation changes in panoramas, it seems to sometimes work if the CP
situation is very good and the panorama doesn't have a very large fov,
but I reckon it's generally best not to touch X,Y and Z for panoramas
and maybe only try in the last run when everything else is already
well settled (luckily wo de have undo now!). Translation adds yet
another set of degrees of fredom to the optimization problem - often
that's plain too much and the whole thing fails. Even in mosaics I
have rarely succeeded optimizing 'everything' - often I do a cyclical
thing where I optimize, like, two parameters at a time (like, X,Y Y,Z
Z,Y ...)
Anyway, removing the 'everything' preset is possibly a good idea for
now. How about making the presets customizable, like the presets for
the CPGs? If there was a reasonable selection of untemperamental
standard presets, less experienced users wouldn't be tempted straight
away to optimize 'everything' and get nothing for it.

Kay

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[kfj]

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
call it a smartener ;-)
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
ptoimggen.py script, I'll give it  some thought.

Kay

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[Bruno Postle]

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 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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Declaring 2010.4.0 final and moving on

[RueiKe]

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 no issues.  Let me know if there is any other
testing needed for the issue I described the the RC1 thread.

Regards,
Rick

On Dec 27, 7:59 am, Yuval Levy  wrote:
> Hi all,
>
> There are still some issues with 2010.4.0, none of which is particularly
> critical, tragic, or urgent.  Yes, 2010.4.0 is far from perfect and in
> particularly this [0] screenshot is a pain to the eye.
>
> But there is also plenty of stuff waiting to be integrated, and the usual
> suspects have been given a lot in their sprint to fix bugs in the last month.
>
> Should we declare 2010.4.0 final and move on to integrate the panorama
> overview branch?  Or should we wait for some more fixes, apply them to 2010.4
> and issue another release candidate?
>
> Yuv
>
> [0] 
>
>  signature.asc
> < 1KViewDownload

-- 
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_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx