hugin-0.7.0_rc1 released
Bruno Postle
http://sourceforge.net/project/showfiles.php?group_id=77506&package_id=78426
I've confirmed that this builds and runs on Fedora F9 x86_64, test
reports from other platforms would be welcome.
This is a release candidate, i.e. the final release may be
identical.
See README and INSTALL_cmake for more information.
Note that as I write a recent CVS enblend-3.1 snapshot is
required, however CVS enblend is currently broken and a
version before 2008-07-24 is needed. See this bug report
for updates:
http://sourceforge.net/tracker/index.php?func=detail&aid=2027314&group_id=123407&atid=696410
--
Bruno
Bruno Postle
>
>A hugin-0.7.0_beta5 source tarball is available here:
Doh, I mean a hugin-0.7.0_rc1 (release candidate 1) source tarball
of course.
Michael Galloway
-- michael
Tom Sharpless
Have built for Windows, self installer will soon be on http//
tksharpless.net.
Had a scare first time I ran it, there were various ugly GUI rendering
errors; but rebooting fixed that (Windows XP is still __Windows__,
after all, tho it only needs rebooting about twice a week).
Cheers, Tom
On Jul 28, 7:53 pm, Bruno Postle <br...@postle.net> wrote:
> On Tue 29-Jul-2008 at 00:49 +0100, Bruno Postle wrote:
>
>
>
> >A hugin-0.7.0_beta5 source tarball is available here:
>
> Doh, I mean a hugin-0.7.0_rc1 (release candidate 1) source tarball
> of course.
>
> >I've confirmed that this builds and runs on Fedora F9 x86_64, test
> >reports from other platforms would be welcome.
>
> >This is a release candidate, i.e. the final release may be
> >identical.
>
> >See README and INSTALL_cmake for more information.
>
> >Note that as I write a recent CVS enblend-3.1 snapshot is
> >required, however CVS enblend is currently broken and a
> >version before 2008-07-24 is needed. See this bug report
> >for updates:
>
Rich
> A hugin-0.7.0_beta5 source tarball is available here:
>
> http://sourceforge.net/project/showfiles.php?group_id=77506&package_id=78426
>
> I've confirmed that this builds and runs on Fedora F9 x86_64, test
> reports from other platforms would be welcome.
>
> This is a release candidate, i.e. the final release may be
> identical.
i'd suggest to get in at least the remaining fixes for dialogs appearing
behind the main window -
https://sourceforge.net/tracker/?func=detail&atid=550441&aid=2027795&group_id=77506
if the chosen fix is acceptable, it shouldn't be too hard to apply it to
the other, remaining dialogs (i hope :) )
> See README and INSTALL_cmake for more information.
>
> Note that as I write a recent CVS enblend-3.1 snapshot is
> required, however CVS enblend is currently broken and a
> version before 2008-07-24 is needed. See this bug report
> for updates:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=2027314&group_id=123407&atid=696410
>
> --
> Bruno
--
Rich
Bruno Postle
>
>i'd suggest to get in at least the remaining fixes for dialogs appearing
>behind the main window -
>https://sourceforge.net/tracker/?func=detail&atid=550441&aid=2027795&group_id=77506
>
>if the chosen fix is acceptable, it shouldn't be too hard to apply it to
>the other, remaining dialogs (i hope :) )
Ok, if some more fixes are added I'll do another release candidate.
Otherwise, if favourable OS X and Windows build reports come-in
first, then I'll release this rc1 as 0.7.0-final.
BTW, this 0.7.0-rc1 tarball is equivalent to the hugin trunk SVN
revision 3245.
--
Bruno
Bruno Postle
>
>i will test builds on opensuse 11 (i386 and x86_64) tomorrow. is there a
>reference set of images available?
The Two Photos tutorial is a good test of the basic functionality:
http://hugin.sourceforge.net/tutorials/two-photos/
Though it doesn't cover exposure blending or HDR, this is covered by
the Enfuse 360° tutorial:
http://hugin.sourceforge.net/tutorials/enfuse-360/
Unfortunately this one takes a while to work through, it would be
nice to have a simple 'single-stack' enfuse/HDR tutorial, but we
don't have that.
--
Bruno
Michael Galloway
yes, indeed. i have been doing a fair bit of HDR pano building lately.
when/if things calm down at work i could put together something with
enfuse/HDR.
-- michael
Gerry Patterson
i'd suggest to get in at least the remaining fixes for dialogs appearing
On 2008.07.29. 02:49, Bruno Postle wrote:
> A hugin-0.7.0_beta5 source tarball is available here:
>
> http://sourceforge.net/project/showfiles.php?group_id=77506&package_id=78426
>
> I've confirmed that this builds and runs on Fedora F9 x86_64, test
> reports from other platforms would be welcome.
>
> This is a release candidate, i.e. the final release may be
> identical.
behind the main window -
https://sourceforge.net/tracker/?func=detail&atid=550441&aid=2027795&group_id=77506
if the chosen fix is acceptable, it shouldn't be too hard to apply it to
the other, remaining dialogs (i hope :) )
Hello Rich,
There are a number of popups that need would updating, but it is simple to do (for the most part). I am still waiting to see if it behaves as expected under Windows and MacOSX before I update the rest of the dialogs.
- Gerry
tennevin yves
> OK!!
>
> Have built for Windows, self installer will soon be on http//
> tksharpless.net.
>
> Had a scare first time I ran it, there were various ugly GUI rendering
> errors; but rebooting fixed that (Windows XP is still __Windows__,
> after all, tho it only needs rebooting about twice a week).
>
> Cheers, Tom
>
The default output options are grayed out.
Output - Normal
Blended panorama.
Remapped images.
are not clickable...
Kinda difficult to create normal panoramas with it :o
Tried to reboot, did not change anything.
esby
Yuval Levy
> I installed it.
> The default output options are grayed out.
>
> Output - Normal
> Blended panorama.
> Remapped images.
>
> are not clickable...
>
> Kinda difficult to create normal panoramas with it :o
> Tried to reboot, did not change anything.
weird. I built and packaged it and everything worked fine.
I built an installer version without autopano that will be bundled with
Nodal Ninja starting next week. They can't distribute autopano because
it is patent-tainted. A new installer is overdue on my blog...
Yuv
Bruno Postle
>
>The default output options are grayed out.
>
>Output - Normal
>Blended panorama.
>Remapped images.
>
>are not clickable...
Hi we need to know exactly the steps to reproduce this, are you
creating a new project? opening an existing one? 'normal' or
involving stacked bracketed exposures?
--
Bruno
Simon Oosthoek
Isn't this related to a recent bugfix where these options are greyed out
until you load images for the project?
So another question is: how many images are loaded when this problem occurs?
Cheers
Simon
Alex Romosan
> Bruno Postle wrote:
>> On Tue 29-Jul-2008 at 15:51 +0200, tennevin yves wrote:
>>> The default output options are grayed out.
>>>
>>> Output - Normal
>>> Blended panorama.
>>> Remapped images.
>>>
>>> are not clickable...
>>
>> Hi we need to know exactly the steps to reproduce this, are you
>> creating a new project? opening an existing one? 'normal' or
>> involving stacked bracketed exposures?
>>
>
> Isn't this related to a recent bugfix where these options are greyed out
> until you load images for the project?
i've seen this as well and i tracked it down to line 316 (well that
logic block) in src/hugin1/hugin/PanoPanel.cpp.
for selected panorama projects hugin decides that i have HDR stacks
and refuses to let me use enblend to make a panorama. i ended up
setting
opt.outputLDRBlended = true
in the code itself and then i can make panoramas which looked fine so
i am not sure what's the purpose of that restriction.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
tennevin yves
>> Hi we need to know exactly the steps to reproduce this, are you
>> creating a new project? opening an existing one? 'normal' or
>> involving stacked bracketed exposures?
>>
>>
>
> Isn't this related to a recent bugfix where these options are greyed out
> until you load images for the project?
>
> So another question is: how many images are loaded when this problem occurs?
>
>
I initally did some recropping for each image.
As my camera has a little problem, but it's not related with hugin.
The images and pto files are here:
http://esby.free.fr/hugin/report/000/
esby / Y. Tennevin
Yuval Levy
> So another question is: how many images are loaded when this problem occurs?
woops, I only tested with an HDR pano this time. I looked at it again
and here are my findings:
at zero images, Normal output is available, Exposure Blending and Merge
to HDR are grayed out.
at one image, Normal output is available, the other two are grayed out.
I did a single image remapping today and it worked almost well. The
errors are purely cosmetic:
<http://sourceforge.net/tracker/index.php?func=detail&aid=2031421&group_id=77506&atid=550441>
at two or more images of same or different exposure, Normal is grayed
out while exposure blending and merge to hdr are available. This is a
show stopping bug :(
filed.
<http://sourceforge.net/tracker/index.php?func=detail&aid=2031575&group_id=77506&atid=550441>
thanks Alex Romosan and everybody else for nailing it down.
Yuv
Tom Sharpless
Sorry to hear there is a UI problem on Windows; glad to hear it is not
something I did.
--Tom
On Jul 29, 11:19 am, Yuval Levy <goo...@levy.ch> wrote:
> Simon Oosthoek wrote:
> > So another question is: how many images are loaded when this problem occurs?
>
> woops, I only tested with an HDR pano this time. I looked at it again
> and here are my findings:
>
> at zero images, Normal output is available, Exposure Blending and Merge
> to HDR are grayed out.
>
> at one image, Normal output is available, the other two are grayed out.
> I did a single image remapping today and it worked almost well. The
> errors are purely cosmetic:
> at two or more images of same or different exposure, Normal is grayed
> out while exposure blending and merge to hdr are available. This is a
> show stopping bug :(
>
> filed.
Yuval Levy
> glad to hear it is not something I did.
The only way to ever avoid mistakes is to never do anything.
Whoever did it should be glad and proud, for they are helping us move
forward.
Or as Thomas Edison used to say after each experiment: "I have not
failed. I've just found another way that won't work".
Let's keep finding.
Yuv
Alex Romosan
> Sorry to hear there is a UI problem on Windows; glad to hear it is
> not something I did.
i see this on linux with normal panoramas (no HDR). i loaded the
pictures, optimize the position, exposure (LDR and white balance)
enblend crashed on me (i am on an amd64) saved the panorama, tried
again and the enblend stiching (under normal) was greyed out. "fixed"
it in the code as i outlined in my previous message, updated enblend
in cvs to an older version that works and i got a working panorama
(http://caliban.lbl.gov/panoramas/tahoe.jpg).
Gerry Patterson
Hugin examines the position of images and tries to decide what output options to make available. If all of the images are stacked on top of each other, then a fused output (either enfuse or HDR) is assumed. If they are not, then only the 'normal' option is available.
So when one loads to images and doesn't optimize for position (or manually set roll, tilt, or pitch) all of the images are stacked onto each other and normal output is locked out. As soon as one makes a change, the panorama configuration is examined and output options are updated accordingly.
However, it seems this doesn't take into account certain use cases. Unfortunately, I am having trouble understanding what it is people are trying to do. Please post a simple workflow outlining the problem and I will put in the changes.
Best Regards,
- Gerry
Alex Romosan
> Hugin examines the position of images and tries to decide what
> output options to make available. If all of the images are stacked
> on top of each other, then a fused output (either enfuse or HDR) is
> assumed. If they are not, then only the 'normal' option is
> available.
>
> So when one loads to images and doesn't optimize for position (or
> manually set roll, tilt, or pitch) all of the images are stacked
> onto each other and normal output is locked out. As soon as one
> makes a change, the panorama configuration is examined and output
> options are updated accordingly.
>
> However, it seems this doesn't take into account certain use cases.
> Unfortunately, I am having trouble understanding what it is people
> are trying to do. Please post a simple workflow outlining the
> problem and I will put in the changes.
that explains what i am seeing. in my case there was a very large
overlap in some of the pictures, but i still wanted to include them
because they provided some more coverage on the border (but the
exposure was very different because the sun went behind the clouds). i
don't think hugin should try to guess and even more annoyingly disable
any options. one reason i always liked unix as an operating system is
exactly because it gives me the tools to shoot myself in the foot and
then _lets_ me do it if i am stupid enough. moreover, in my particular
case enblend worked just fine (after i "fixed" the hugin code) so i
couldn't understand why hugin won't let me use enblend.
i hate it when a piece of software thinks it's smarter than i am and
will prevent me from doing something i want to do. that might be the
expected behaviour under windows but unix users have different
expectations.
tennevin yves
> Hi All,
>
> Hugin examines the position of images and tries to decide what output
> options to make available. If all of the images are stacked on top of
> each other, then a fused output (either enfuse or HDR) is assumed. If
> they are not, then only the 'normal' option is available.
>
> So when one loads to images and doesn't optimize for position (or
> manually set roll, tilt, or pitch) all of the images are stacked onto
> each other and normal output is locked out. As soon as one makes a
> change, the panorama configuration is examined and output options are
> updated accordingly.
>
> However, it seems this doesn't take into account certain use cases.
> Unfortunately, I am having trouble understanding what it is people are
> trying to do. Please post a simple workflow outlining the problem and
> I will put in the changes.
>
> Best Regards,
>
> - Gerry
>
>
I see two possibility:
* warn the user when something not normal is going to be started. (eg:
the user tries to output an HDR with a 'normal panorama.')
* adds an expert mode, that disables the locking feature.
esby / Y. Tennevin
Yuval Levy
> that explains what i am seeing. in my case there was a very large
> overlap in some of the pictures, but i still wanted to include them
> because they provided some more coverage on the border (but the
> exposure was very different because the sun went behind the clouds).
how much overlap? I just tested with 50% overlap and once position
hugin's guesstimate is correct.
I've updated
<https://sourceforge.net/tracker/index.php?func=detail&aid=2031575&group_id=77506&atid=550441>
with a suggested solution.
> i hate it when a piece of software thinks it's smarter than i am and
> will prevent me from doing something i want to do.
me too.
> that might be the expected behaviour under windows but unix users
> have different expectations.
has nothing to do with windows vs. unix - many unix/linux users let a
central piece of software prevent them from doing something they want to
do: <http://www.desktoplinux.com/news/NS8745257437.html>
Yuv
Alex Romosan
> Alex Romosan wrote:
>> that explains what i am seeing. in my case there was a very large
>> overlap in some of the pictures, but i still wanted to include them
>> because they provided some more coverage on the border (but the
>> exposure was very different because the sun went behind the clouds).
>
> how much overlap? I just tested with 50% overlap and once position
> hugin's guesstimate is correct.
turns out there was a picture that was completely overlapped by the
other pictures (and behind them). the other border pictures overlap
something like 90% but that doesn't seem to make any difference. once
i removed it i could once again use enblend. even with that picture in
the series i still think i should be allowed to use enblend if i want
to.
Yuval Levy
> i still think i should be allowed to use enblend if i want to.
in principle i tend to agree with you. then i see the bug reports filed
by people who were allowed to use enblend if they wanted to (before the
change) and come to prefer the current, limiting solution.
I like Yves suggestion of just warning rather than disabling.
Yuv
Guido Kohlmeyer
The different behaviour regarding the output check boxes was introduced
by Gerry in SVN 3218.
I percieved similar confusing things. For instance, I wanted to stich
few pictures with different exposures, which were taken with automatic
camera mode. After automatic control point estimation and so on, hugin
set HDR mode and Enfuse of whole pano.
I set LDR mode in preview window, but the Enfuse of pano was still
checked but not active/enabled.
Afterwards I cannot enable the Enfuse and HDR check boxes.
Maybe Garry can comment the implementation of disabling the check boxes
If stacked pictures are detected.
Regards,
Guido
Alex Romosan schrieb:
Bruno Postle
>
>turns out there was a picture that was completely overlapped by the
>other pictures (and behind them). the other border pictures overlap
>something like 90% but that doesn't seem to make any difference.
>once i removed it i could once again use enblend. even with that
>picture in the series i still think i should be allowed to use
>enblend if i want to.
This should still happen, the two images that align with each other
will be merged with enfuse, then this enfused result will be blended
with the other photos using enblend.
--
Bruno
Guido Kohlmeyer
thanks for your feedback, right before I wrote my request for it.
I think one of the main problem is to specify criteria, when check boxes
are active or not. Of course it depends highly on the alignment of the
pictures and secondly on some events, e.g. add of a picture or new
alignment optimization.
Currently I doubt, that the process of check box activation is
transparent and comprehensible to the user. Otherwise we won't discuss
it here.
I propose to defere it to a future version with renewed user interface.
Guido
Gerry Patterson schrieb:
> Hi All,
>
> Hugin examines the position of images and tries to decide what output
> options to make available. If all of the images are stacked on top of
> each other, then a fused output (either enfuse or HDR) is assumed. If
> they are not, then only the 'normal' option is available.
>
> So when one loads to images and doesn't optimize for position (or
> manually set roll, tilt, or pitch) all of the images are stacked onto
> each other and normal output is locked out. As soon as one makes a
> change, the panorama configuration is examined and output options are
> updated accordingly.
>
> However, it seems this doesn't take into account certain use cases.
> Unfortunately, I am having trouble understanding what it is people are
> trying to do. Please post a simple workflow outlining the problem and I
> will put in the changes.
>
> Best Regards,
>
> - Gerry
>
>
>
>
>
> On Tue, Jul 29, 2008 at 11:27 AM, Alex Romosan <rom...@sycorax.lbl.gov
> <mailto:rom...@sycorax.lbl.gov>> wrote:
>
>
> Tom Sharpless <TKSha...@gmail.com <mailto:TKSha...@gmail.com>>
Harry van der Wolf
I downloaded the rc1 and built it with cmake on OSX. I did 2 partial panoramas, a 360 and an enfused, partial panorama. All works fine.
For some reason XCode crashes instantly on opening the the project so I can't do a bundle build (but I can't publish anyway as long as I'm on holiday). I need to check whether that's my system, changes by Ippei or the fact that the project is SVN based and the rc1 off course not.
I get back this weekend so probably early next week I can publish an OSX build.
Harry
Stephan Hegel
Bruno Postle wrote:
> A hugin-0.7.0_beta5 source tarball is available here:
>
> http://sourceforge.net/project/showfiles.php?group_id=77506&package_id=78426
rc1 builds fine on openSuSE 10.3, x86_64.
> Note that as I write a recent CVS enblend-3.1 snapshot is
> required, however CVS enblend is currently broken and a
> version before 2008-07-24 is needed.
I've got a CVS Snapshot from July 18th, seems to be o.k. I ran one huge
test set through it without a crash.
Regards,
Stephan.
Stephan Hegel
Bruno Postle wrote:
> The Two Photos tutorial is a good test of the basic functionality:
>
> http://hugin.sourceforge.net/tutorials/two-photos/
>
> Though it doesn't cover exposure blending or HDR, this is covered by
> the Enfuse 360° tutorial:
>
> http://hugin.sourceforge.net/tutorials/enfuse-360/
Is this set of images or a similar set - fisheye, bracketed - freely
available for test purposes ?
Rgds,
Stephan.
Bruno Postle
>
>at two or more images of same or different exposure, Normal is grayed
>out while exposure blending and merge to hdr are available. This is a
>show stopping bug :(
I haven't had any time to do any testing of this. I'm not going to
be near a build system for the next week, so I won't be able to do
another hugin release candidate just yet.
--
Bruno
Toby Haynes
On Jul 29, 5:21 pm, Bruno Postle <br...@postle.net> wrote:
> This should still happen, the two images that align with each other
> will be merged with enfuse, then this enfused result will be blended
> with the other photos using enblend.
Halifax waterfront, Nova Scotia. I typically heavily overlap images
(more than 50%) so that it there is a dud in the middle, I can remove
it without leaving a hole. It also gives me better vignetting
correction but that is a secondary consideration.
To give you some figures, each photo has a FOV of 45'. There are 8
images which cover a view of 130'. The RPM reports as
hugin-0.7.0-0.4.20080727svn.fc9.i386.
Cheers,
Toby Haynes
Bruno Postle
>
>On Jul 29, 5:21 pm, Bruno Postle <br...@postle.net> wrote:
>> This should still happen, the two images that align with each other
>> will be merged with enfuse, then this enfused result will be blended
>> with the other photos using enblend.
>
>I'm also seeing the "Normal" Option greyed out with a panorama of the
>Halifax waterfront, Nova Scotia. I typically heavily overlap images
>(more than 50%) so that it there is a dud in the middle, I can remove
>it without leaving a hole.
If you stitch it with 'exposure blending' enabled, do you still get
an acceptable result?
Can you post a copy of the .pto project somewhere? as even if we
remove the new 'greying-out' functionality hugin will still 'think'
you have an exposure stack.
--
Bruno
Yuval Levy
probably the most sensible thing to do is what Guido suggested and roll
back the change for the current release.
There are a number of things that are unpolished in the user interface,
and they are better dealt with a proper in depth analysis and a plan of
UI changes for the next release.
Yuv
Guido Kohlmeyer
I build enblend on 2008-07-20 right after I got latest version from CVS
and have the source still on my machine. I build it on Win32 and an
executable is available too.
Is this what you are looking for?
Guido
Bruno Postle schrieb:
> A hugin-0.7.0_beta5 source tarball is available here:
>
> http://sourceforge.net/project/showfiles.php?group_id=77506&package_id=78426
>
> I've confirmed that this builds and runs on Fedora F9 x86_64, test
> reports from other platforms would be welcome.
>
> This is a release candidate, i.e. the final release may be
> identical.
>
> See README and INSTALL_cmake for more information.
>
> Note that as I write a recent CVS enblend-3.1 snapshot is
> required, however CVS enblend is currently broken and a
> version before 2008-07-24 is needed. See this bug report
> for updates:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=2027314&group_id=123407&atid=696410
>
> --
> Bruno
>
> >
>
hbl
I have been unable to compile the 7/20/2008 CVS version without
errors. Did you use MS VC++ 2008, v9.0?
Toby Haynes
On Jul 30, 3:18 pm, Bruno Postle <br...@postle.net> wrote:
> On Wed 30-Jul-2008 at 12:08 -0700, Toby Haynes wrote:
> >I'm also seeing the "Normal" Option greyed out with a panorama of the
> >Halifax waterfront, Nova Scotia. I typically heavily overlap images
> >(more than 50%) so that it there is a dud in the middle, I can remove
> >it without leaving a hole.
>
> If you stitch it with 'exposure blending' enabled, do you still get
> an acceptable result?
to get a single image. If I remove just image 3 from the stack, the
"Normal"
> Can you post a copy of the .pto project somewhere? as even if we
> remove the new 'greying-out' functionality hugin will still 'think'
> you have an exposure stack.
http://tjwhaynes.googlepages.com/Halifax-Panomatic.pto.
Cheers,
Toby Haynes
Bruno Postle
>
>I build enblend on 2008-07-20 right after I got latest version from CVS
>and have the source still on my machine. I build it on Win32 and an
>executable is available too.
>Is this what you are looking for?
Sorry I wasn't clear, current enblend HEAD compiles fine but it
crashes during blending.
--
Bruno
Bruno Postle
>> Can you post a copy of the .pto project somewhere? as even if we
>> remove the new 'greying-out' functionality hugin will still 'think'
>> you have an exposure stack.
>
>I've used Photometric optimisation on this pto. You can get it at
>http://tjwhaynes.googlepages.com/Halifax-Panomatic.pto.
Your image 3 has almost exactly the same roll/pitch/yaw as image 4,
so I can see why hugin thinks these should be fused with enfuse.
These sort of closely aligned images really don't blend very well
with enblend.
>> If you stitch it with 'exposure blending' enabled, do you still get
>> an acceptable result?
>
>I end up with 5 images that I would need to put through enblend again
>to get a single image. If I remove just image 3 from the stack, the
>"Normal"
What should happen is that 'exposure blending' with enfuse is just
the first step, after this the images should be blended with enblend
into the single final image.
If this isn't happening then something has gone wrong - Perhaps it
is because image 3 is disabled, but the 'stack detection' doesn't
notice.
--
Bruno
Yuval Levy
> current enblend HEAD compiles fine but it crashes during blending.
not on Windows with MSVC 2008 EE with Pablo's Hugin SDK.
I've notified both Pablo and Andrew about a week ago.
Yuv