Photometric Optimization Doesn't Function in 2014.0.0
110 views
Skip to first unread message
Alex Blanck
Mar 21, 2015, 2:21:41 PM3/21/15
to hugi...@googlegroups.com
I'm having an odd problem in the precompiled version of Hugin for OSX (version 2014.0.0)
After aligning the panorama from the photos tab, everything looks good in the preview except for obvious vingetting at the borders between frames. I then attempt to optimize the photometric parameters by choosing low dynamic range and then clicking "Compute" in the photos tab. The calculation appears to run (perhaps a bit too quickly) and then I get a dialog telling me that photometric optimization is finished. However, after clicking yes there is no difference in the previews.
Additionally, if I change the photometric dropdown to "custom parameters" to reveal the exposure tab, I can see that none of the vingetting or exposure values have been changed (exposure is still based off of exif and vingetting is 0).
Has anyone else had a similar experience? I downgraded to the 2013 version and the photometric optimization seemed to work correctly.
Terry Duell
Mar 21, 2015, 5:51:04 PM3/21/15
to hugi...@googlegroups.com
Hello Alex,
It all appears to be working as it should here with a build of the current
repo source on Linux.
Cheers,
--
Regards,
Terry Duell
repo source on Linux.
Cheers,
--
Regards,
Terry Duell
Kornel Benko
Mar 22, 2015, 2:47:42 PM3/22/15
to hugi...@googlegroups.com
Am Sonntag, 22. März 2015 um 08:50:58, schrieb Terry Duell <tdu...@iinet.net.au>
> > After aligning the panorama from the photos tab, everything looks good in
> > the preview except for obvious vingetting at the borders between frames.
> > I then attempt to optimize the photometric parameters by choosing low
> > dynamic range and then clicking "Compute" in the photos tab. The
> > calculation
> > appears to run (perhaps a bit too quickly) and then I get a dialog
> > telling me that photometric optimization is finished. However, after
> > clicking yes
> > there is no difference in the previews.
I cannot see this. Instead the 'optimized' panorama is crappy.
> > Additionally, if I change the photometric dropdown to "custom parameters"
> > to reveal the exposure tab, I can see that none of the vingetting or
> > exposure values have been changed (exposure is still based off of exif
> > and vingetting is 0).
Seen it too, some days ago. But not with current hugin.
> > Has anyone else had a similar experience? I downgraded to the 2013
> > version and the photometric optimization seemed to work correctly.
> >
That is my impression too.
> It all appears to be working as it should here with a build of the current
> repo source on Linux.
>
> Cheers,
Terry, I have a small (5 pictures) panorama, for which you could try the photometric optimization.
The outcome is .. terrifying ..
Kornel
> Hello Alex,
>
> On Sun, 22 Mar 2015 05:13:16 +1100, Alex Blanck <ajbl...@gmail.com> wrote:
>
> > I'm having an odd problem in the precompiled version of Hugin for OSX
> > (version 2014.0.0)
I too in the actual version.
>
> On Sun, 22 Mar 2015 05:13:16 +1100, Alex Blanck <ajbl...@gmail.com> wrote:
>
> > I'm having an odd problem in the precompiled version of Hugin for OSX
> > (version 2014.0.0)
> > After aligning the panorama from the photos tab, everything looks good in
> > the preview except for obvious vingetting at the borders between frames.
> > I then attempt to optimize the photometric parameters by choosing low
> > dynamic range and then clicking "Compute" in the photos tab. The
> > calculation
> > appears to run (perhaps a bit too quickly) and then I get a dialog
> > telling me that photometric optimization is finished. However, after
> > clicking yes
> > there is no difference in the previews.
> > Additionally, if I change the photometric dropdown to "custom parameters"
> > to reveal the exposure tab, I can see that none of the vingetting or
> > exposure values have been changed (exposure is still based off of exif
> > and vingetting is 0).
> > Has anyone else had a similar experience? I downgraded to the 2013
> > version and the photometric optimization seemed to work correctly.
> >
> It all appears to be working as it should here with a build of the current
> repo source on Linux.
>
> Cheers,
The outcome is .. terrifying ..
Kornel
Terry Duell
Mar 22, 2015, 5:45:14 PM3/22/15
to hugi...@googlegroups.com
Hello Kornel,
On Mon, 23 Mar 2015 05:47:28 +1100, Kornel Benko <Kornel...@berlin.de>
wrote:
[snip]
>
>> It all appears to be working as it should here with a build of the
>> current repo source on Linux.
>>
>
zip, and I'll test.
Second thoughts, Dropbox would also allow others to test which might be
useful if we have varying results from different builds of hugin.
On Mon, 23 Mar 2015 05:47:28 +1100, Kornel Benko <Kornel...@berlin.de>
wrote:
[snip]
>
>> It all appears to be working as it should here with a build of the
>> current repo source on Linux.
>>
>
> Terry, I have a small (5 pictures) panorama, for which you could try the
> photometric optimization.
> The outcome is .. terrifying ..
>
OK. Put the images and the .pto on Dropbox or similar, or directly email a
> photometric optimization.
> The outcome is .. terrifying ..
>
zip, and I'll test.
Second thoughts, Dropbox would also allow others to test which might be
useful if we have varying results from different builds of hugin.
Kornel Benko
Mar 22, 2015, 7:23:18 PM3/22/15
to hugi...@googlegroups.com
Am Montag, 23. März 2015 um 08:45:08, schrieb Terry Duell <tdu...@iinet.net.au>
Sent privately.
Kornel
Kornel
Terry Duell
Mar 23, 2015, 6:09:31 PM3/23/15
to hugi...@googlegroups.com
[snip]
>
> Terry, I have a small (5 pictures) panorama, for which you could try the
> photometric optimization.
> The outcome is .. terrifying ..
>
For the record, I also get a 'terrifying' result from photometric
optimisation of Kornel's project with my Fedora build of hugin-2014.1.0.
The project can be recovered by resetting camera response.
I also rebuilt hugin-2013.0.0 (from a Fedora src.rpm) and this version
gets the photometric optimisation of Kornel's project correct without any
intervention.
>
> Terry, I have a small (5 pictures) panorama, for which you could try the
> photometric optimization.
> The outcome is .. terrifying ..
>
optimisation of Kornel's project with my Fedora build of hugin-2014.1.0.
The project can be recovered by resetting camera response.
I also rebuilt hugin-2013.0.0 (from a Fedora src.rpm) and this version
gets the photometric optimisation of Kornel's project correct without any
intervention.
T. Modes
Mar 24, 2015, 2:07:41 PM3/24/15
to hugi...@googlegroups.com
Am Montag, 23. März 2015 23:09:31 UTC+1 schrieb Tduell:
>
> Terry, I have a small (5 pictures) panorama, for which you could try the
> photometric optimization.
> The outcome is .. terrifying ..
>
For the record, I also get a 'terrifying' result from photometric
optimisation of Kornel's project with my Fedora build of hugin-2014.1.0.
The project can be recovered by resetting camera response.
I also rebuilt hugin-2013.0.0 (from a Fedora src.rpm) and this version
gets the photometric optimisation of Kornel's project correct without any
intervention.
Strange. There is - as far as I remember - no significant change to the photometric optimizer code between 2013.0 and 2014.0.
So I have no idea what's going wrong, and I have not observed the bug myself.
So you have a test project which fails reproducible and 2 changesets - one working and one not.
This is a good starting point for hg blame to find the culprit.
Thomas
Kornel Benko
Mar 24, 2015, 3:00:39 PM3/24/15
to hugi...@googlegroups.com, T. Modes
Am Dienstag, 24. März 2015 um 11:07:41, schrieb T. Modes <Thomas...@gmx.de>
No need for hg blame. Try
# hg log
and search for 6818
==> tmodes: Use C++11 <random> when possible
To see the diff:
# hg diff -c 6818
> Thomas
>
Kornel
# hg log
and search for 6818
==> tmodes: Use C++11 <random> when possible
To see the diff:
# hg diff -c 6818
> Thomas
>
Kornel
Kornel Benko
Mar 24, 2015, 3:06:39 PM3/24/15
to hugi...@googlegroups.com
Am Dienstag, 24. März 2015 um 20:00:24, schrieb Kornel Benko <Kornel...@berlin.de>
And before someone asks: I saw the diffs depending on '#ifdef HAVE_CXX11', and
that it should use boost as before, if using -DUSE_BOOST=ON in configuration.
But, it does not help.
Version 6817 is OK, 6818 is not OK.
Kornel
that it should use boost as before, if using -DUSE_BOOST=ON in configuration.
But, it does not help.
Version 6817 is OK, 6818 is not OK.
Kornel
T. Modes
Mar 24, 2015, 3:19:33 PM3/24/15
to hugi...@googlegroups.com
Am Dienstag, 24. März 2015 20:06:39 UTC+1 schrieb kornel:
> No need for hg blame. Try
> # hg log
> and search for 6818
> ==> tmodes: Use C++11 <random> when possible
>
That was not mentioned in the initial posts. They referred to 2013.0 and 2014.0 and not to current trunk.
See please be more precise and not so diffuse comments.
And before someone asks: I saw the diffs depending on '#ifdef HAVE_CXX11', and
that it should use boost as before, if using -DUSE_BOOST=ON in configuration.
from CMakeLists.txt
IF(USE_BOOST)
UNSET(USE_CXX11_THREAD)
UNSET(HAVE_CXX11)
..
Version 6817 is OK, 6818 is not OK.
Which compiler?
Have you tried with USE_BOOST? (Checked hugin_config.h?)
Could you provide the test project? I don't see the issue with my projects.
Thomas
Kornel Benko
Mar 24, 2015, 4:10:03 PM3/24/15
to hugi...@googlegroups.com
Am Dienstag, 24. März 2015 um 12:19:33, schrieb T. Modes <Thomas...@gmx.de>
> And before someone asks: I saw the diffs depending on '#ifdef HAVE_CXX11',
> > and
> > that it should use boost as before, if using -DUSE_BOOST=ON in
> > configuration.
> >
>
> from CMakeLists.txt
>
> IF(USE_BOOST)
> UNSET(USE_CXX11_THREAD)
> UNSET(HAVE_CXX11)
> ..
>
>
> > Version 6817 is OK, 6818 is not OK.
> >
>
> Which compiler?
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
> Have you tried with USE_BOOST? (Checked hugin_config.h?)
Yes, see some lines above where I mentioned it.
> Could you provide the test project? I don't see the issue with my projects.
>
> Thomas
Yes, I can. But only outside this list, the pictures are too big.
Kornel
>
> Am Dienstag, 24. März 2015 20:06:39 UTC+1 schrieb kornel:
> >
> > > No need for hg blame. Try
> > > # hg log
> > > and search for 6818
> > > ==> tmodes: Use C++11 <random> when possible
> > >
> >
>
> That was not mentioned in the initial posts. They referred to 2013.0 and
> 2014.0 and not to current trunk.
> See please be more precise and not so diffuse comments.
Yes, sorry. There were private mails with Terry.
> Am Dienstag, 24. März 2015 20:06:39 UTC+1 schrieb kornel:
> >
> > > No need for hg blame. Try
> > > # hg log
> > > and search for 6818
> > > ==> tmodes: Use C++11 <random> when possible
> > >
> >
>
> That was not mentioned in the initial posts. They referred to 2013.0 and
> 2014.0 and not to current trunk.
> See please be more precise and not so diffuse comments.
> And before someone asks: I saw the diffs depending on '#ifdef HAVE_CXX11',
> > and
> > that it should use boost as before, if using -DUSE_BOOST=ON in
> > configuration.
> >
>
> from CMakeLists.txt
>
> IF(USE_BOOST)
> UNSET(USE_CXX11_THREAD)
> UNSET(HAVE_CXX11)
> ..
>
>
> > Version 6817 is OK, 6818 is not OK.
> >
>
> Which compiler?
> Have you tried with USE_BOOST? (Checked hugin_config.h?)
> Could you provide the test project? I don't see the issue with my projects.
>
> Thomas
Kornel
T. Modes
Mar 24, 2015, 4:55:17 PM3/24/15
to hugi...@googlegroups.com
Hi Kornel,
Am Dienstag, 24. März 2015 21:10:03 UTC+1 schrieb kornel:
> Have you tried with USE_BOOST? (Checked hugin_config.h?)
Yes, see some lines above where I mentioned it.
> Could you provide the test project? I don't see the issue with my projects.
>
> Thomas
Yes, I can. But only outside this list, the pictures are too big.
I got the images, thanks. I committed a fix. It should be work again.
But I don't know why the boost option does not work, because in this case the effective code did not change in the mentioned changeset.
Thomas
PS: One comment to your project. Using a different lens for each image results in many variables to optimize. So each image has its own vignetting parameters and its own response curve. This is very fragile for optimize. It's better to use only one lens. Then all images share the same vignetting parameters and the same response curve.
Kornel Benko
Mar 24, 2015, 5:13:00 PM3/24/15
to hugi...@googlegroups.com
Am Dienstag, 24. März 2015 um 13:55:17, schrieb T. Modes <Thomas...@gmx.de>
> But I don't know why the boost option does not work, because in this case
> the effective code did not change in the mentioned changeset.
> Thomas
>
> PS: One comment to your project. Using a different lens for each image
> results in many variables to optimize. So each image has its own vignetting
> parameters and its own response curve. This is very fragile for optimize.
> It's better to use only one lens. Then all images share the same vignetting
> parameters and the same response curve.
(Sometimes, if the camera itself corrects images, it is better to use different lenses.)
Even if using only 1 lens, the optimized panorama is also with this new change not good.
I always have to deselect vignetting optimization to get some reasonable output.
Kornel
> Hi Kornel,
>
> Am Dienstag, 24. März 2015 21:10:03 UTC+1 schrieb kornel:
> >
> > > Have you tried with USE_BOOST? (Checked hugin_config.h?)
> >
> > Yes, see some lines above where I mentioned it.
> >
> > > Could you provide the test project? I don't see the issue with my
> > projects.
> > >
> > > Thomas
> >
> > Yes, I can. But only outside this list, the pictures are too big.
> >
>
> I got the images, thanks. I committed a fix. It should be work again.
It changed. It is not much better though.
>
> Am Dienstag, 24. März 2015 21:10:03 UTC+1 schrieb kornel:
> >
> > > Have you tried with USE_BOOST? (Checked hugin_config.h?)
> >
> > Yes, see some lines above where I mentioned it.
> >
> > > Could you provide the test project? I don't see the issue with my
> > projects.
> > >
> > > Thomas
> >
> > Yes, I can. But only outside this list, the pictures are too big.
> >
>
> I got the images, thanks. I committed a fix. It should be work again.
> But I don't know why the boost option does not work, because in this case
> the effective code did not change in the mentioned changeset.
> Thomas
>
> PS: One comment to your project. Using a different lens for each image
> results in many variables to optimize. So each image has its own vignetting
> parameters and its own response curve. This is very fragile for optimize.
> It's better to use only one lens. Then all images share the same vignetting
> parameters and the same response curve.
Even if using only 1 lens, the optimized panorama is also with this new change not good.
I always have to deselect vignetting optimization to get some reasonable output.
Kornel
Kornel Benko
Mar 24, 2015, 5:20:53 PM3/24/15
to hugi...@googlegroups.com
Am Dienstag, 24. März 2015 um 22:12:52, schrieb Kornel Benko <Kornel...@berlin.de>
Sorry, I overseen, that the compilation goes wrong and therefore use old hugin.
The error now is:
cd /usr/BUILD/BuildHugin_hg/src/hugin1/hugin && /usr/bin/c++ -DHUGIN_HSI -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -pthread -O3 -DNDEBUG -I/usr/BUILD/BuildHugin_hg/src -I/usr/src/hugin/hugin_hg/src/hugin_base -I/usr/src/hugin/hugin_hg/src/celeste -I/usr/BUILD/BuildHugin_hg/src/celeste -I/usr/src/hugin/hugin_hg/src -I/usr/include/x86_64-linux-gnu -I/usr/include/OpenEXR -I/usr/local/include -I/usr/include/python2.7 -isystem /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem /usr/include/wx-3.0 -I/usr/src/hugin/hugin_hg/src/hugin1 -fopenmp -o CMakeFiles/hugin.dir/TextureManager.cpp.o -c /usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp
In file included from /usr/include/exiv2/metadatum.hpp:39:0,
from /usr/include/exiv2/exif.hpp:34,
from /usr/include/exiv2/bmpimage.hpp:34,
from /usr/include/exiv2/exiv2.hpp:35,
from /usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:67:
/usr/include/exiv2/value.hpp:984:25: note: attribute for ‘struct Exiv2::DateValue::Date’ must follow the ‘struct’ keyword
EXIV2API struct Date
^
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp: In member function ‘void TextureManager::CheckUpdate()’:
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:431:31: error: ‘make_shared’ is not a member of ‘sharedPtrNamespace’
sharedPtrNamespace::make_shared<TextureInfo>(view_state, tex_width_p, tex_height_p)
^
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:428:34: error: expected primary-expression before ‘(’ token
(TextureKey(img_p, &photometric_correct),
^
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:431:31: error: ‘make_shared’ is not a member of ‘sharedPtrNamespace’
sharedPtrNamespace::make_shared<TextureInfo>(view_state, tex_width_p, tex_height_p)
^
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:431:74: error: expected primary-expression before ‘>’ token
sharedPtrNamespace::make_shared<TextureInfo>(view_state, tex_width_p, tex_height_p)
^
Kornel
The error now is:
cd /usr/BUILD/BuildHugin_hg/src/hugin1/hugin && /usr/bin/c++ -DHUGIN_HSI -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -pthread -O3 -DNDEBUG -I/usr/BUILD/BuildHugin_hg/src -I/usr/src/hugin/hugin_hg/src/hugin_base -I/usr/src/hugin/hugin_hg/src/celeste -I/usr/BUILD/BuildHugin_hg/src/celeste -I/usr/src/hugin/hugin_hg/src -I/usr/include/x86_64-linux-gnu -I/usr/include/OpenEXR -I/usr/local/include -I/usr/include/python2.7 -isystem /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem /usr/include/wx-3.0 -I/usr/src/hugin/hugin_hg/src/hugin1 -fopenmp -o CMakeFiles/hugin.dir/TextureManager.cpp.o -c /usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp
In file included from /usr/include/exiv2/metadatum.hpp:39:0,
from /usr/include/exiv2/exif.hpp:34,
from /usr/include/exiv2/bmpimage.hpp:34,
from /usr/include/exiv2/exiv2.hpp:35,
from /usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:67:
/usr/include/exiv2/value.hpp:984:25: note: attribute for ‘struct Exiv2::DateValue::Date’ must follow the ‘struct’ keyword
EXIV2API struct Date
^
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp: In member function ‘void TextureManager::CheckUpdate()’:
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:431:31: error: ‘make_shared’ is not a member of ‘sharedPtrNamespace’
sharedPtrNamespace::make_shared<TextureInfo>(view_state, tex_width_p, tex_height_p)
^
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:428:34: error: expected primary-expression before ‘(’ token
(TextureKey(img_p, &photometric_correct),
^
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:431:31: error: ‘make_shared’ is not a member of ‘sharedPtrNamespace’
sharedPtrNamespace::make_shared<TextureInfo>(view_state, tex_width_p, tex_height_p)
^
/usr/src/hugin/hugin_hg/src/hugin1/hugin/TextureManager.cpp:431:74: error: expected primary-expression before ‘>’ token
sharedPtrNamespace::make_shared<TextureInfo>(view_state, tex_width_p, tex_height_p)
^
Kornel
Terry Duell
Mar 24, 2015, 5:37:12 PM3/24/15
to hugi...@googlegroups.com
On Wed, 25 Mar 2015 08:20:47 +1100, Kornel Benko <Kornel...@berlin.de>
wrote:
>
project is now OK.
Thanks Thomas.
wrote:
>
> Sorry, I overseen, that the compilation goes wrong and therefore use old
> hugin.
>
Revision 6877 (e1a846fdd353) builds OK here (Fedora 21), and Kornel's test
> hugin.
>
project is now OK.
Thanks Thomas.
T. Modes
Mar 24, 2015, 5:39:18 PM3/24/15
to hugi...@googlegroups.com
Am Dienstag, 24. März 2015 22:20:53 UTC+1 schrieb kornel:
The error now is:
There is still USE_BOOST active. Fixed also this bug.
With this bug there I may ask how you could test the boost variant (USE_BOOST=TRUE) as written your mails.
Kornel Benko
Mar 24, 2015, 5:52:12 PM3/24/15
to hugi...@googlegroups.com
Am Dienstag, 24. März 2015 um 14:39:18, schrieb T. Modes <Thomas...@gmx.de>
Yes, and somehow my build tree was tainted. Recompiled with fresh build, it looks good now.
Thanks,
Kornel
Thanks,
Kornel
Reply all
Reply to author
Forward
0 new messages