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
Doh, I mean a hugin-0.7.0_rc1 (release candidate 1) source tarball
of course.
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
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
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
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
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 :) )
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
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
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
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
> 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. |
The images and pto files are here:
http://esby.free.fr/hugin/report/000/
esby / Y. Tennevin
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
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
> 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).
> 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.
esby / Y. Tennevin
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 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.
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
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:
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
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>>
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.
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.
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
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
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
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
>
> >
>
Sorry I wasn't clear, current enblend HEAD compiles fine but it
crashes during blending.
--
Bruno
>> 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
not on Windows with MSVC 2008 EE with Pablo's Hugin SDK.
I've notified both Pablo and Andrew about a week ago.
Yuv