optimizer errors in trunk w/ layout branch (2010.1.0.4834)
kevin
is very nice for mosaics which I mostly do) but I've noticed that the
optimzer sometimes doesn't work correctly. Even with good control
points it'll place images in the wrong areas. I first noticed it on
smaller stitches of 7-8 images, it would always be the last or next to
last image in the series that wouldn't be placed correctly. For
stitches with more images it seems to be various ones in the set.
Here's a screen shot of the fast preview to show what I'm talking
about:
http://www.bluelavalamp.net/hugin/after_optimize.jpg
The top image was made using hugin version 2009.4.0.4742. After
detecting the control points I went and reset everything in the
"Camera and Lens" tab. Then I ran the optimizer using the "Positions
(incremental" setting. That gave me a max error of 18.548. Opened
the fast preview, used identify to show the 3rd to last image in the
set - placement is pretty good. Save the .pto file.
Then I open the saved .pto file in hugin version 2010.1.0.4834. I run
optimizer again using the "Positions (incremental" setting. This time
it comes up with a max error of 135.164 and the lens parameter "View"
is changed for some of the lenses even though those parameters are not
marked to be optimized. Open the fast preview, use identify on the
same image as above and the result is the bottom image.
Has anyone else had problems with the optimizer on the layout branch?
Carl von Einem
(hugin-mac-2010.1.0-svn4837.dmg) did some unexpected things that I
haven't seen in older versions. I'm not sure but it looks like values
for a and c tend to get very high. Also optimizing for roll or pitch
sometimes made the images go berserk in the preview window.
I just tested one new project so I wasn't really sure if it could be my
mistake. After opening the same project in hugin 2009.4 I got much
better optimizing results.
Carl
kevin schrieb am 30.12.09 16:34:
Oskar Sander
In your case this was a ordinary panorama w.o. XYZ i assume, right?
I had a stability problem recurring in some (4) layout projects. A couple of images get completly wrong positions. Looking closer in the project i found bogus control points between unrelated images, this probably threw the optimization off. The problem seems to be that the CP error figure did not reflect this correctly so these bad CP did not stand out, nor the other correct CPs on the same image.
I thought this was a stability problem caused by the wrong CP + all degrees of freedom in my mosaic-project only, but maybe it is an issue with the error calculation/cost function in optimization then.
/O
--
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 hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
--
/O
Tduell
I can report a similar experience to the above with a Fedora build of
2010.1.0-svn4837.
I have a project that would always end up haywire prior to the
implementation of cpclean. I could only get a good result with
manually selected control points, so this project has become one of
those that I use to test any new version.
The result using 2010.1.0-svn4837 appears even more out of kilter than
I have seen previously. Removing obvious bad control points (between
non overlapping photos), re-optimising and running cpclean has little
or no effect. Roll angles have really bad values.
I have removed this version and reverted to 2009.4 but can re-install
and investigate further if needed.
Cheers,
Terry
kevin
cause even more problems with images being placed in the wrong spot.
On Dec 30, 3:46 pm, Oskar Sander <oskar.san...@gmail.com> wrote:
> Well, not sure if it is the same problem or not but I had some stability
> issues with layouts that puzzled me a bit.
>
> In your case this was a ordinary panorama w.o. XYZ i assume, right?
>
> I had a stability problem recurring in some (4) layout projects. A couple
> of images get *completly *wrong positions. Looking closer in the project i
> > hugin-ptx+...@googlegroups.com<hugin-ptx%2Bunsu...@googlegroups.com>
T. Modes
> I've been using the trunk version of hugin with the layout code (which
> is very nice for mosaics which I mostly do) but I've noticed that the
> optimzer sometimes doesn't work correctly.
I commit a patch to the trunk (rev. 4851). This patch fixes an issue
with writing the optimizer scripts.
Maybe this patch could solve some the the mentioned problems. Please
give it a try.
Thomas
Tduell
On Jan 5, 5:52 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
[snip]
> I commit a patch to the trunk (rev. 4851). This patch fixes an issue
> with writing the optimizer scripts.
> Maybe this patch could solve some the the mentioned problems. Please
> give it a try.
This revision does come close to fixing the problems that I had seen.
My test project is handled really well by the 2009.4.0 release
version, without any intervention on my part...just using the
assistant; this version (4852) manages to put two control points in an
unconnected pair of images. A result can be obtained by removing the
incorrect control points, resetting camera and lens parameters and
then re-optimising. The result is not initially as good as that from
2009.4.0, being more off centre and with more roll angle.
I am using autopano-sift-c-2.5.1-1, enblend-4.0, and build hugin using
libpano13-2.9.15.
Please let me know if you need any additional info/files etc.
Cheers,
Terry
Bruno Postle
>
>On Jan 5, 5:52 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
>> I commit a patch to the trunk (rev. 4851). This patch fixes an issue
>> with writing the optimizer scripts.
>> Maybe this patch could solve some the the mentioned problems. Please
>> give it a try.
>This revision does come close to fixing the problems that I had seen.
Yes the trunk seems to be ok again, I've just optimised five
panoramas with no problems.
The photometric optimisation is ok too, I remember a report that
this was very slow, but it is ok for me.
--
Bruno
kevin
final images. Thanks!
Tduell
On Jan 6, 11:57 am, kevin <ke...@bluelavalamp.net> wrote:
> Yeah, this fixes the problem for me. So far no offsetting of the
> final images. Thanks!
Not everything OK here, perhaps it's me!
Photometric optimisation seems a bit crook.
I set up a project with some scaled images (to reduce size of
package), and ran it through 2009.4.0.4742 and 2010.1.0.4852 (current
trunk).
I did everything the same for the two versions of hugin, and the
result from 4852 is quite a bit different to that from 4742.
I have uploaded a tar archive ( San-G-3.tar.gz [1]) which contains the
photos, resulting panos and the pto files from the two versions of
hugin. The naming should be pretty obvious, everything from
2009.4.0.4742 has 4742 in the name, and similarly for 2010.1.0.4852.
If the link below is haywire (I have had some trouble with these in
the past) look for the tar archive named above.
As others are reporting success with the trunk, it probably points to
something at my end, but don't know what that can be. As I say above,
I have used the same settings with 4742 and 4852, but the resulting
panos don't look alike, and 4742 is much more like what I would
consider acceptable.
So, either something is still amiss with the trunk, in which case this
may help, or something amiss here and hopefully someone can use the
uploaded info to set me straight.
[1] http://hugin-ptx.googlegroups.com/web/San-G-3.tar.gz?gsc=7OIBlgsAAABNbhQI4OauOm6prPL6fC32
Cheers,
Terry
Tduell
On Jan 6, 4:39 pm, Tduell <tdu...@iinet.net.au> wrote:
[snip]
> Not everything OK here, perhaps it's me!
> Photometric optimisation seems a bit crook.
Further to this story.
A bit of experimenting has revealed a workaround to what I have been
experiencing with the current trunk, and this might throw some light
on the issue for those that understand these things.
If I go through the process of alignment (using 'assistant' tab), then
reset exposure, color, vignetting, camera response on all photos and
then re-optimise, then select photometrics in fast preview, the
resulting stitch appears to be the same as results from hugin
2009.4.0.4742.
If I don't do the reset and re-optimise, the color and exposure in the
resulting panos are poor.
I have tried this approach with two projects and get bad results if I
don't reset/re-optimise and good results if I do.
Running the same projects through 2009.4.0.4742 and only using
'assistant' steps of 'align' and 'Create panorama' always gives a good
result.
It might be useful if someone could try to reproduce this using the
test images I uploaded (San-G-3.tar.gz).
If it's not due to differences between 4742 and current trunk, could
someone please provide some guidance as to what might be happening
here?
Cheers,
Terry
T. Modes
> Further to this story.
> A bit of experimenting has revealed a workaround to what I have been
> experiencing with the current trunk, and this might throw some light
> on the issue for those that understand these things.
In the mean time I have found the function, where something goes wrong
with photometric optimization. But I have not completed the patch. I
will try to solve it in the next days. Please have some patience.
Thomas
Tduell
Thanks for that info.
My only impatience, if that is how it appeared, was in trying to
understand whether it was a problem in the trunk or a local problem
with my build.
It is a bit curious that others haven't been seeing the problem.
Cheers,
Terry
Bruno Postle
>My only impatience, if that is how it appeared, was in trying to
>understand whether it was a problem in the trunk or a local problem
>with my build.
>It is a bit curious that others haven't been seeing the problem.
I noticed that the photometric optimisation result wasn't very good,
but the photos were full of snow, so I'd expect it to not work so
well.
--
Bruno
Tduell
I'm not sure I understand what you mean by 'full of snow'. I am not
seeing anything that I would describe that way, but perhaps I'm not
looking properly.
The example images were downscaled so as to not have to provide such a
large archive for anyone else to download and test, but the same/
similar result was obtained with the original images.
The thing is that the same photos were used for both versions of
hugin, and (I thought) with quite different results.
Cheers,
Terry
Bruno Postle
>On Jan 8, 10:15 am, Bruno Postle <br...@postle.net> wrote:
>>
>> I noticed that the photometric optimisation result wasn't very good,
>> but the photos were full of snow, so I'd expect it to not work so
>> well.
>
>I'm not sure I understand what you mean by 'full of snow'. I am not
>seeing anything that I would describe that way, but perhaps I'm not
>looking properly.
I meant it was actually snowing when I was shooting:
http://www.flickr.com/photos/36383814@N00/4251620391/
--
Bruno
Tduell
On Jan 8, 11:42 am, Bruno Postle <br...@postle.net> wrote:
>
> I meant it was actually snowing when I was shooting:
>
> http://www.flickr.com/photos/36383814@N00/4251620391/
Oops...sorry. I completely misunderstood, thinking your comment
referred to the example photos that I uploaded.
Cheers,
Terry
T. Modes
> Thanks for that info.
> My only impatience, if that is how it appeared, was in trying to
> understand whether it was a problem in the trunk or a local problem
> with my build.
> It is a bit curious that others haven't been seeing the problem.
>
I commited a fix for the photometric optimization (rev. 4862). I
tested with your example San-G3. When using p1020264-p1020266-4852.pto
as it is (without reset) and now optimizing I'm getting similiar
values for the photometric variables (Eev, vignetting, response) as in
p1020264-p1020266-4742.pto.
But the photometric optimization is still slower than the previous
version, especially when using the default settings in the photometric
tab (when using the custom parameter set it not so different regarding
the speed).
> I have a project that would always end up haywire prior to the
> implementation of cpclean. I could only get a good result with
> manually selected control points, so this project has become one of
> those that I use to test any new version.
> My test project is handled really well by the 2009.4.0 release
> version, without any intervention on my part...just using the
> assistant; this version (4852) manages to put two control points in an
> unconnected pair of images.
Could you provide this test project? So I could have a look to check
whats going wrong in the trunk. The project file pto (after running cp
generator and before cpclean) is suifficient. Also give the image
pairs which share wreong cp but are not overlapping.
Thomas
Tduell
On Jan 8, 5:35 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> Hi Terry,
[snip]
> I commited a fix for the photometric optimization (rev. 4862). I
> tested with your example San-G3. When using p1020264-p1020266-4852.pto
> as it is (without reset) and now optimizing I'm getting similiar
> values for the photometric variables (Eev, vignetting, response) as in
> p1020264-p1020266-4742.pto.
>
OK, thanks for all your work on this problem. I will try to build this
version as soon as I can and run my usual checks.
> But the photometric optimization is still slower than the previous
> version, especially when using the default settings in the photometric
> tab (when using the custom parameter set it not so different regarding
> the speed).
OK.
>
> > I have a project that would always end up haywire prior to the
> > implementation of cpclean. I could only get a good result with
> > manually selected control points, so this project has become one of
> > those that I use to test any new version.
> > My test project is handled really well by the 2009.4.0 release
> > version, without any intervention on my part...just using the
> > assistant; this version (4852) manages to put two control points in an
> > unconnected pair of images.
>
> Could you provide this test project? So I could have a look to check
> whats going wrong in the trunk. The project file pto (after running cp
> generator and before cpclean) is suifficient. Also give the image
> pairs which share wreong cp but are not overlapping.
I have packaged up the two non-overlapping images which share the
wrong control points, and included the pto file generated immediately
after alignment.
The package is named 'Thomas.tar.gz' [1] and has been uploaded to the
hugin-ptx group site.
For the record the settings I used were...
Optimizer - everything
Exposure - Low dynamic range, variable white balance
Stitcher - Equirectangular, blended pano, JPEG
Blender options - -l 29
I trust this is sufficient for you, but if not please let me know.
[1] http://hugin-ptx.googlegroups.com/web/Thomas.tar.gz?gsc=MNnezwsAAABzXVfantXCoE2_CBqWFzQ1
Thanks again for your help. I'll now get on with building rev 4862.
Cheers,
Terry
Tduell
On Jan 8, 5:35 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> Could you provide this test project? So I could have a look to check
> whats going wrong in the trunk. The project file pto (after running cp
> generator and before cpclean) is suifficient. Also give the image
> pairs which share wreong cp but are not overlapping.
I have just run a number of tests on a build of svn 4876.
My favourite test project now optimises well in all respects.
I also ran a couple of other projects and they too appear to be good.
It looks as though the trunk optimiser issues are all sorted.
Thanks, Thomas, well done.
Cheers,
Terry