Error Message
rich
advid Linux user and run PCLinuxOS on all of my computers. Recently I
installed the latest hugin ( I believe the latest development
package.) Before this PCLinuxOS has just carried the oldest version
0.7.4. This version is 0.7.0.3161. I also installed enblend and the
other files necessary to run the program from their repositories
automatically. It is indeed different than the earlier version 0.7.4..
I might add that I have been using 'Autopanopro' (Linux version 1.4.2
on my system also.). I'm an avid panorama photographer hobbyist and
want to see very much the success of this program. It is an excellent
photographic
tool for this type of photography. To make this long story short
I've tried to stitch a 7 photo pano and upon near completion I get the
following error message:
nona -z PACKBITS -r ldr -m TIFF_m -o Antelope1 -i 0 /home/richard/tmp/
huginpto_2FKFUj
nona -z PACKBITS -r ldr -m TIFF_m -o Antelope1 -i 1 /home/richard/tmp/
huginpto_2FKFUj
nona -z PACKBITS -r ldr -m TIFF_m -o Antelope1 -i 2 /home/richard/tmp/
huginpto_2FKFUj
nona -z PACKBITS -r ldr -m TIFF_m -o Antelope1 -i 3 /home/richard/tmp/
huginpto_2FKFUj
nona -z PACKBITS -r ldr -m TIFF_m -o Antelope1 -i 4 /home/richard/tmp/
huginpto_2FKFUj
nona -z PACKBITS -r ldr -m TIFF_m -o Antelope1 -i 5 /home/richard/tmp/
huginpto_2FKFUj
nona -z PACKBITS -r ldr -m TIFF_m -o Antelope1 -i 6 /home/richard/tmp/
huginpto_2FKFUj
enblend --compression 100 -a -f9578x5071 -o Antelope1.jpg
Antelope10000.tif Antelope10001.tif Antelope10002.tif
Antelope10003.tif Antelope10004.tif Antelope10005.tif
Antelope10006.tif
==== enblend, version 2.5 ====
Usage: enblend [options] -o OUTPUT INPUTS
Common options:
-a Pre-assemble non-overlapping images
-h Print this help message
-l number Number of levels to use (1 to 29)
-o filename Write output to file
-v Verbose
-w Blend across -180/+180 boundary
-z Use LZW compression
Extended options:
-b kilobytes Image cache block size (default=2MiB)
-c Use CIE L*a*b* color space
-g Associated alpha hack for Gimp (ver. < 2) and
Cinepaint
-f WIDTHxHEIGHT Manually set the size of the output image.
Useful for cropped and shifted input TIFF images,
such as those produced by Nona.
-m megabytes Use this much memory before going to disk
(default=1GiB)
enblend: invalid option -- -
make: *** [Antelope1.jpg] Error 1
Program suggests I copy the message and send in: Just wondering is
there something I'm doing wrong?
What do I need to do to get satisfactory completion? Is the program
indicating that I'm leaving an option out in enblend?
Any help would be appreciated.
Richard
Bruno Postle
>
>==== enblend, version 2.5 ====
>enblend: invalid option -- -
Hi, for current hugin SVN pre-releases, you also need a pre-release
version of enblend-3.1. This can be downloaded and compiled from
enblend CVS.
--
Bruno
Cyril Brulebois
> Hi, for current hugin SVN pre-releases, you also need a pre-release
> version of enblend-3.1. This can be downloaded and compiled from
> enblend CVS.
Hi. While I can understand the need for “current” enblend
release/snapshot for “current” hugin release/snapshot, it'd be
super-nice if you could do some kind of runtime detection. You could
explore one of the following ways:
- test enblend version and adapt dialog options accordingly (like:
don't propose a feature which isn't available);
- or test enblend version just before running the process, and warn if
the detected version isn't sufficient for some option(s).
Mraw,
KiBi.
Bruno Postle
> - test enblend version and adapt dialog options accordingly (like:
> don't propose a feature which isn't available);
Unfortunately there are lots of new enblend features that hugin now
uses: PNG, JPEG and EXR output, different TIFF compressions, and
exposure blending with enfuse.
> - or test enblend version just before running the process, and warn if
> the detected version isn't sufficient for some option(s).
I think that definitely there is a way we can do some testing like
this, but it isn't likely before the 0.7.0 release.
This problem only bites people who compile their own, anyone using
packaged versions should get dependency requirements configured
properly.
--
Bruno
Cyril Brulebois
> Unfortunately there are lots of new enblend features that hugin now
> uses: PNG, JPEG and EXR output, different TIFF compressions, and
> exposure blending with enfuse.
I see…
> > - or test enblend version just before running the process, and warn
> > if the detected version isn't sufficient for some option(s).
>
> I think that definitely there is a way we can do some testing like
> this, but it isn't likely before the 0.7.0 release.
>
> This problem only bites people who compile their own, anyone using
> packaged versions should get dependency requirements configured
> properly.
… which also includes people using our Debian packages since there's
neither an hugin release or a (recent) enblend one, and we thus have to
pick a snapshot (freeze is next week).
I'm wondering whether we should instead not package hugin in the stable
release at all. Currently 0.7.0~svn3191-1 (or a -2) might enter testing
(thus stable after some weeks) in time but I'm not sure whether it makes
sense since we're going to ship enblend 3.0, and no later version.
I initially planned to patch hugin to fix the dialogue, so as not to
propose any compression at all, but if we're going to disable all the
above-mentioned features, that's going to be quite a PITA, if doable at
all.
Mraw,
KiBi.
Bruno Postle
>
>… which also includes people using our Debian packages since there's
>neither an hugin release or a (recent) enblend one, and we thus have to
>pick a snapshot (freeze is next week).
>
>I'm wondering whether we should instead not package hugin in the stable
>release at all. Currently 0.7.0~svn3191-1 (or a -2) might enter testing
>(thus stable after some weeks) in time but I'm not sure whether it makes
>sense since we're going to ship enblend 3.0, and no later version.
That's a problem, you would need to roll hugin back nearly a year to
avoid using these enblend-3.1 features and still have something
reasonably 'stable' - But the hugin 0.7.0 release will be quite a
different thing from hugin as it was last July.
enblend CVS is actually very stable and still supports everything
that enblend-3.0 did. Would it help if enblend-3.1 was released
soon?
--
Bruno
Yuval Levy
> On Mon 21-Jul-2008 at 04:40 +0200, Cyril Brulebois wrote:
>> … which also includes people using our Debian packages since there's
>> neither an hugin release or a (recent) enblend one, and we thus have to
>> pick a snapshot (freeze is next week).
>>
>> I'm wondering whether we should instead not package hugin in the stable
>> release at all. Currently 0.7.0~svn3191-1 (or a -2) might enter testing
>> (thus stable after some weeks) in time but I'm not sure whether it makes
>> sense since we're going to ship enblend 3.0, and no later version.
>
> That's a problem, you would need to roll hugin back nearly a year to
> avoid using these enblend-3.1 features and still have something
> reasonably 'stable' - But the hugin 0.7.0 release will be quite a
> different thing from hugin as it was last July.
this is a real problem. I don't think it makes sense to roll back. we
already see enough bug reports related to this.
> enblend CVS is actually very stable and still supports everything
> that enblend-3.0 did. Would it help if enblend-3.1 was released
> soon?
moving forward is the right thing to do. but one week time is a very
short notice. is it possible, rather than rolling back hugin, to use a
current enblend snapshot in a similar way as an svn-hugin snapshot was
yoused in your tests, Cyril? enblend cvs is very stable indeed, but i
don't like to see pressure on Andrew to release it within one week.
Yuv
Bruno Postle
>
>moving forward is the right thing to do. but one week time is a very
>short notice. is it possible, rather than rolling back hugin, to use a
>current enblend snapshot in a similar way as an svn-hugin snapshot was
>yoused in your tests, Cyril? enblend cvs is very stable indeed, but i
>don't like to see pressure on Andrew to release it within one week.
I'd be happy to see hugin and enblend stable releases immediately,
an imminent Debian freeze is as good a reason as any to push it out.
There are 21 hugin 0.7.0 bugs in the tracker, and although there are
one or two that I'd really like to see fixed (e.g 1981284), actually
hugin and enblend are already 'release quality'.
..at least for Linux, I'm not sure where the Windows/OS X builds are
at.
(it's tempting to release panoglview and autopano-sift-C tarballs
anyway, since they are overdue).
--
Bruno
Gerry Patterson
Is now a good time to go through the bug list again to see if there are some that you would like to defer to 0.7.1 or later? I had assigned the bug you mentioned to myself and started looking at a sol'n. Most bugs are coming in the same priority so I just pick ones I can understand, repeat, and feel reasonably confident I can come up with a fix for.
Best Regards,
- Gerry
Pablo d'Angelo
Bruno Postle wrote:
> On Mon 21-Jul-2008 at 09:23 -0400, Yuval Levy wrote:
>
> I'd be happy to see hugin and enblend stable releases immediately,
> an imminent Debian freeze is as good a reason as any to push it out.
>
> There are 21 hugin 0.7.0 bugs in the tracker, and although there are
> one or two that I'd really like to see fixed (e.g 1981284), actually
> hugin and enblend are already 'release quality'.
>
> ..at least for Linux, I'm not sure where the Windows/OS X builds are
> at.
I agree. Unfortunately I didn't have much time for coding on hugin lately,
and its unlikely to change in the near future, so bugfixes from me will be
few. I'm very happy that Gerry is making nice progress in killing the
remaining bugs. I think it will probably take at least month or two until
most of the bugs currently listed for the 0.7.0 release have been fixed,
which is IMHO too long for a 0.7.0 release.
ciao
Pablo
Bruno Postle
>Bruno Postle wrote:
>> hugin and enblend are already 'release quality'.
>>
>> ..at least for Linux, I'm not sure where the Windows/OS X builds are
>> at.
>
>I agree.
Are the Windows and OS X installers 'ready to go'?
--
Bruno
Yuval Levy
> On Mon 21-Jul-2008 at 09:23 -0400, Yuval Levy wrote:
>> i don't like to see pressure on Andrew to release it within one week.
>
> I'd be happy to see hugin and enblend stable releases immediately,
The one wish does not exclude the other. It's a few months that I'd like
to see stable releases. There are trade-offs between the two wishes. And
they also trade-off against how polished the released package is.
Windows installer is ready for release. I'm currently traveling. When
I'm back home I promised to deliver an installer with the current
version that will be bundled with http://www.nodalninja.com/ products.
> (it's tempting to release panoglview and autopano-sift-C tarballs
> anyway, since they are overdue).
no autopano-sift-C in the NN-bundled version.
Yuv
Cyril Brulebois
> That's a problem, you would need to roll hugin back nearly a year to
> avoid using these enblend-3.1 features and still have something
> reasonably 'stable' - But the hugin 0.7.0 release will be quite a
> different thing from hugin as it was last July.
As pointed out in further replies, it doesn't make sense to roll back.
> enblend CVS is actually very stable and still supports everything that
> enblend-3.0 did. Would it help if enblend-3.1 was released soon?
I've asked my comaintainers' (Cc'd) opinion, and I'm still waiting for
Sebastian's answer (enblend maintainer). It'd at least make hugin more
usable for unstable users, assuming it'd be released and uploaded soon.
And maybe, if release managers accept it, enblend 3.1 could be granted a
freeze exception, which would mean that hugin eventually has a chance to
migrate as well to testing, and then to be released with lenny.
Summarizing, releasing enblend 3.1 those very days would:
- put a bit of pressure on Sebastian's shoulders;
- probably make enblend users happy;
- grant hugin (snapshot) users a better hugin experiences;
- eventually, and I insist on this *eventually* make it possible for
enblend 3.1 and hugin to be shipped in the next stable release; if
release managers don't accept the freeze exception, enblend 3.0 will
be shipped, hugin not at all, and eventually made available through
backports.org (but that's an additional step/repositories for stable
users, which everyone tries to avoid).
I really hope it'll be possible for hugin to make it in time, but there
are a lot of dependencies here: upstreams, maintainers, release team. No
room for certainty here. :)
Mraw,
KiBi.
Cyril Brulebois
Forwarding Sebastian's message, he isn't subscribed (yet).
----- Forwarded message from Sebastian Harl <s...@tokkee.org> -----
From: Sebastian Harl <s...@tokkee.org>
To: hugi...@googlegroups.com
Cc: pkg-photot...@lists.alioth.debian.org
Subject: Re: [Pkg-phototools-devel] [hugin-ptx] Re: Whether to release hugin
in Debian stable?
Date: Tue, 22 Jul 2008 19:38:53 +0200
User-Agent: Mutt/1.5.13 (2006-08-11)
Message-ID: <20080722173...@albany.tokkee.org>
Hi,
On Tue, Jul 22, 2008 at 04:26:26PM +0200, Cyril Brulebois wrote:
> Bruno Postle <br...@postle.net> (21/07/2008):
> > enblend CVS is actually very stable and still supports everything that
> > enblend-3.0 did. Would it help if enblend-3.1 was released soon?
So, what's the reason why it has not been released so far? This kinda
sounds like doing the release in a hurry just to get it in time for
Lenny, which would be a rather bad thing.
Imho, the worst thing that could happen is to get enblend 3.1 into
unstable before the freeze so it will eventually migrate to testing /
Lenny and _then_ realize that there are still some major bugs that
cannot be resolved before Lenny. In that case, enblend would be removed
from Lenny and we would release without it (as we could not "drop back"
to 3.0).
> And maybe, if release managers accept it, enblend 3.1 could be granted a
> freeze exception, which would mean that hugin eventually has a chance to
> migrate as well to testing, and then to be released with lenny.
Iff we get a 3.1 package into unstable before the weekend, it would
still make it into Lenny. I really doubt that we'd get a freeze
exception if we upload after the Freeze.
> Summarizing, releasing enblend 3.1 those very days would:
> - put a bit of pressure on Sebastian's shoulders;
If it would be released within the next few days, I'm pretty sure that I
_could_ finish the package before the Freeze. However, as stated above,
I'm quite uncertain that this is a good idea.
Just to make things clear: I would really love to see enblend 3.1 +
hugin 0.7 in Lenny but given the really short amount of time that is
left to get things right I think it would be better to ship a fairly
well tested enblend 3.0 + hugin 0.6 and make 3.1 + 0.7 available thru
backports.org after the remaining issues (which includes more than just
a few days of testing) have been settled.
Cheers,
Sebastian
Bruno Postle
>> > enblend-3.0 did. Would it help if enblend-3.1 was released soon?
>So, what's the reason why it has not been released so far? This kinda
>sounds like doing the release in a hurry just to get it in time for
>Lenny, which would be a rather bad thing.
This is a real shame, it sounds like it is too late to catch the
freeze.
>Imho, the worst thing that could happen is to get enblend 3.1 into
>unstable before the freeze so it will eventually migrate to testing /
>Lenny and _then_ realize that there are still some major bugs that
>cannot be resolved before Lenny.
There are snapshots in fedora-9 (enblend 2008-05-29 & hugin
2008-05-28) apparently without problems, so these are 'good' - but
fedora doesn't build on as many platforms as debian, and this doesn't
help with possible toolchain/library differences.
--
Bruno
Gerry Patterson
I have commited a fix for 1981284 to SVN. I have tested it under GNU/Linux.
Best Regards,
- Gerry
Simon Oosthoek
> Hello,
>
> I have commited a fix for 1981284 to SVN. I have tested it under GNU/Linux.
>
Hi Gerry
thanks for your hard work on the bugfixes, I'm impressed with the rate
you pump out fixes :-)
This one didn't build for me on kubuntu hardy (8.04.1), I thought I'd
let you know now, perhaps I can look a little further tomorrow...
[ 77%] Building CXX object
src/hugin1/hugin/CMakeFiles/hugin.dir/CommandHistory.o
[ 78%] Building CXX object src/hugin1/hugin/CMakeFiles/hugin.dir/PanoPanel.o
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:
In member function ‘void PanoPanel::DoStitch()’:
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:905:
error: expected primary-expression before ‘<<’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:905:
error: expected primary-expression before ‘<<’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:905:
error: expected primary-expression before ‘<<’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:905:
error: expected primary-expression before ‘<’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:905:
error: expected primary-expression before ‘.’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:908:
error: expected `;' before ‘wxConfigBase’
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:910:
error: expected primary-expression before ‘==’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:910:
error: expected primary-expression before ‘==’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:910:
error: expected primary-expression before ‘==’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:910:
error: expected primary-expression before ‘=’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:912:
error: expected primary-expression before ‘>>’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:912:
error: expected primary-expression before ‘>>’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:912:
error: expected primary-expression before ‘>>’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:912:
error: expected primary-expression before ‘>’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:912:
error: expected primary-expression before ‘.’ token
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:916:
error: expected `;' before ‘wxProcess’
/home/simon/src/hugin-cvs/hugin-svn/hugin/src/hugin1/hugin/PanoPanel.cpp:917:
error: ‘my_process’ was not declared in this scope
make[2]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/PanoPanel.o] Error 1
make[1]: *** [src/hugin1/hugin/CMakeFiles/hugin.dir/all] Error 2
make: *** [all] Error 2
Cheers
Simon
PS, regarding the topic, I think it would be best to release
enblend/hugin ASAP and get it into the next debian stable.
Gerry Patterson
Hi Simon,
I think you might have a locally modified file in your tree. I recently committed a fix for 1987509 regarding enfuse/enblend parameters being sent to hugin_stitch_project. It required flushing the config file to disk before the call to hugin_stitch_project. I recall someone else requesting a config flush on the mailing list regarding startup paths. Perhaps you were trying that out?
- Best Regards,
- Gerry
Bruno Postle
>
>This one didn't build for me on kubuntu hardy (8.04.1), I thought I'd
>let you know now, perhaps I can look a little further tomorrow...
Build works for me (fedora FC-8 & FC-9), I haven't had a chance to
test the bugfixes.
>PS, regarding the topic, I think it would be best to release
>enblend/hugin ASAP and get it into the next debian stable.
enblend releases are up to Andrew. I think I'll try and upload a
hugin beta5 or rc1 release tomorrow.
--
Bruno
Bruno Postle
Panoglview is a hardware-accelerated viewer for equirectangular
panoramas. This release contains build updates, fixes for rendering
artefacts and support for partial panoramas via project file
extensions:
http://sourceforge.net/project/showfiles.php?group_id=77506&package_id=152817
Bruno Postle
This release contains many bugfixes and speed improvements, plus
support for feature identification in conformal space:
http://sourceforge.net/project/showfiles.php?group_id=77506&package_id=285211
Stephan Hegel
Is this the same like SVN r3224 ?
Rgds,
Stephan.
Stephan Hegel
I get an SEGFAULT when exiting the program (File->Quit):
(gdb) run
Starting program: /home/steve/Incoming/panoglview-0.2.2/src/panoglview
[Thread debugging using libthread_db enabled]
[New Thread 0x2aafb3cfb950 (LWP 12010)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aafb3cfb950 (LWP 12010)]
0x00002aafa864c2b0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) where
#0 0x00002aafa864c2b0 in ?? () from /lib64/ld-linux-x86-64.so.2
#1 0x00002aafa86449d7 in ?? () from /lib64/ld-linux-x86-64.so.2
#2 0x00002aafa864a05e in ?? () from /lib64/ld-linux-x86-64.so.2
#3 0x00002aafa86448e6 in ?? () from /lib64/ld-linux-x86-64.so.2
#4 0x00002aafab84936d in ?? () from /lib64/libdl.so.2
#5 0x00002aafab84908f in dlclose () from /lib64/libdl.so.2
#6 0x00002aafaa07bb19 in wxDynamicLibrary::Unload () from /usr/lib64/libwx_baseu-2.8.so.0
#7 0x00002aafa9776725 in wxGnomePrintLibrary::~wxGnomePrintLibrary ()
from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#8 0x00002aafa9776765 in wxGnomePrintModule::OnExit () from /usr/lib64/libwx_gtk2u_core-2.8.so.0
#9 0x00002aafaa045c10 in wxModule::DoCleanUpModules () from /usr/lib64/libwx_baseu-2.8.so.0
#10 0x00002aafaa0338b4 in wxEntryCleanup () from /usr/lib64/libwx_baseu-2.8.so.0
#11 0x00002aafaa033c40 in wxEntry () from /usr/lib64/libwx_baseu-2.8.so.0
#12 0x000000000040c962 in main (argc=1, argv=0x60281) at panoapp.cpp:54
(gdb)
Rgds,
Stephan.
Simon Oosthoek
> I think you might have a locally modified file in your tree. I
recently
> committed a fix for 1987509 regarding enfuse/enblend parameters being
> sent to hugin_stitch_project. It required flushing the config file to
> disk before the call to hugin_stitch_project. I recall someone else
> requesting a config flush on the mailing list regarding startup paths.
> Perhaps you were trying that out?
Hi Gerry
You're right, I totally forgot I did that...
It compiles fine after resolving the merge conflict.
Cheers
Simon
Rich
> Hi Bruno,
>
> Is this the same like SVN r3224 ?
release is tagged from trunk revision 3221 :
A /autopano-sift-C/tags/release-2.5.0 (from /autopano-sift-C/trunk:3221)
actual tagging happened in revision 3224
> Rgds,
> Stephan.
>
>
> Bruno Postle wrote:
>> autopano-sift-C-2.5.0 released
>>
>> This release contains many bugfixes and speed improvements, plus
>> support for feature identification in conformal space:
>>
>> http://sourceforge.net/project/showfiles.php?group_id=77506&package_id=285211
--
Rich
Bruno Postle
>
> I think I'll try and upload a hugin beta5 or rc1 release tomorrow.
[updating the thread subject as this is more general interest]
I'll do a hugin release candidate tarball later if nobody objects.
--
Bruno
Pablo d'Angelo
Fine with me. I'm not sure if all translation updates in the sf tracker have
been applied.
ciao
Pablo
Gerry Patterson
There are still a few bugs tags for the 0.7.0 release. Do want to skip these for now or shall I keep committing fixes?
- Gerry
Ken Warner
a Linux release?
Bruno Postle
>
>There are still a few bugs tags for the 0.7.0 release. Do want to skip
>these for now or shall I keep committing fixes?
Keep going, there has been a regression with the OS X scroll bars,
so I'll make today's release a 'beta' and we can do a release
candidate after this.
--
Bruno
Bruno Postle
>
>Are you guys talking about a Windows release or
>a Linux release?
I'm talking about a 'source' release, the binary releases for each
platform can come after - and they don't have to be exactly the same
version anyway.
--
Bruno
Bruno Postle
>
>Fine with me. I'm not sure if all translation updates in the sf
>tracker have been applied.
Done, there are Korean and Hungarian updates, plus a new Bulgarian
translation. I've left the German update since it conflicts with
more recent changes in SVN.
--
Bruno
Yuval Levy
I've tried to produce a Windows binary installer release today, but the
latest changes to Enblend (21-July) break building here with Pablo's SDK.
Yuv
Bruno Postle
https://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.
Too many changes to list here since the last beta release was 18
months ago, see README and INSTALL_cmake for installation details.
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
what about dialogs that are behind the main window ? they seem quite
confusing, especially for novice users - would be nice to get rid of
that problem in the release...
--
Rich
Bruno Postle
>
>> Keep going, there has been a regression with the OS X scroll bars,
>> so I'll make today's release a 'beta' and we can do a release
>> candidate after this.
>
>what about dialogs that are behind the main window ? they seem quite
>confusing, especially for novice users - would be nice to get rid of
>that problem in the release...
Yes this is an annoyance, is this in the tracker?
https://sourceforge.net/tracker/?group_id=77506&atid=550441
--
Bruno
Felix Hagemann
>
> I've confirmed that this builds and runs on Fedora F9 x86_64, test
> reports from other platforms would be welcome.
Builds and runs on Debian Testing i386.
Stitched a 48 image bracketed full spherical without problems.
Felix
Simon Oosthoek
> A hugin-0.7.0_beta5 source tarball is available here:
>
> https://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.
>
I've built it on kubuntu 8.04.1 and stitched a couple of images, worked
fine.
/Simon
Rich
i only found an older, already closed report...
https://sourceforge.net/tracker/index.php?func=detail&aid=1661456&group_id=77506&atid=550441
so i submitted a new one at
https://sourceforge.net/tracker/index.php?func=detail&aid=2027795&group_id=77506&atid=550441
--
Rich
Simon Oosthoek
> panoglview-0.2.2 released
>
> Panoglview is a hardware-accelerated viewer for equirectangular
> panoramas. This release contains build updates, fixes for rendering
> artefacts and support for partial panoramas via project file
> extensions:
I noticed there's barely any documentation to be found either with the
package or on the web (or I couldn't find it quickly enough ;-)
I did notice this page: http://wiki.panotools.org/Panoglview
So I added a tiny note about what it can do there, but I know nearly
nothing about it... Please extend where possible!
Partial panoramas sounds like a feature I would need, since I rarely
(never) shoot full 180x360 panoramas, how can I use it?
And GL accelleration would appear to be standard, but I don't think my
compiled version is using it, even though I have nvidia's proprietary
drivers installed. Glxgears is running at around 2450 frames/s, so I
believe GLX is active... Why not panoglview?
Cheers
Simon
Bruno Postle
>
>I did notice this page: http://wiki.panotools.org/Panoglview
>So I added a tiny note about what it can do there, but I know nearly
>nothing about it... Please extend where possible!
>
>Partial panoramas sounds like a feature I would need, since I rarely
>(never) shoot full 180x360 panoramas, how can I use it?
You use project files. There are no examples in the distribution
but they can be created by opening an equirectangular image and
saving a .paf 'project'.
These are simple text files and fairly self-explanatory, but the
interesting thing is that these .paf files contain stuff like camera
field-of-view, pan, tilt, boundaries and now partial panorama
settings.
..anyway there is some future potential with all this:
* Creating a .paf project from a partial equirectangular .pto
project.
* Panning to a view and using these settings as an initial
QTVR/flash viewpoint.
* Panning to a viewpoint, saving the project and using nona to
extract a high-res version of the view.
* This extracted view can be edited in something like the gimp and
reinserted into the panorama - Basically the functionality of the
old pteditor tool.
--
Bruno
Simon Oosthoek
> On Fri 25-Jul-2008 at 21:12 +0200, Simon Oosthoek wrote:
>> I did notice this page: http://wiki.panotools.org/Panoglview
>> So I added a tiny note about what it can do there, but I know nearly
>> nothing about it... Please extend where possible!
>>
>> Partial panoramas sounds like a feature I would need, since I rarely
>> (never) shoot full 180x360 panoramas, how can I use it?
>
> You use project files. There are no examples in the distribution
> but they can be created by opening an equirectangular image and
> saving a .paf 'project'.
>
> These are simple text files and fairly self-explanatory, but the
> interesting thing is that these .paf files contain stuff like camera
> field-of-view, pan, tilt, boundaries and now partial panorama
> settings.
>
Thanks for explaining, unfortunately I won't have much time soon to play
with it, but I've taken the liberty of pasting your description on the
wiki page, so others can already take advantage...
Cheers
Simon
Cyril Brulebois
> A hugin-0.7.0_beta5 source tarball is available here:
>
> https://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.
Hi, and congrats for this next beta.
Here's an update of the Debian plans. I hope the other members of the
pkg-phototools share my thoughts, otherwise I'll send you an update
(unless you're not interested at all, in which case, just say the word).
hugin_0.7.0~svn3191+beta5-1 finishing its final build, upload to Debian
unstable in the next few minutes. Testers are welcome to grab it from
incoming.debian.org (for the next few hours), or from the nearest Debian
mirrors. Built for i386 first, buildds (automatic build daemons) will
take care of the other architectures.
> Note that as I write a recent CVS enblend-3.1 snapshot is required
Regarding that, I've merged Steve Cotton's patch (see #491227[1]) which
disables the --compression option. From the feedback we got from users,
it looks like hugin still is usable even with enblend 3.0; and if you
don't raise any objection, the 1st plan is to try and get beta5 shipped
into the Debian stable, along with enblend 3.0. I've added some
documentation through README.Debian (attached at the end of [2]) about
enblend 3.0 versus 3.1.
1. http://bugs.debian.org/491227
2. http://lists.alioth.debian.org/pipermail/pkg-phototools-devel/2008-July/000358.html
Once you've released enblend 3.1, we'll try and get it packaged into the
experimental distribution, and if everything goes fine (if it builds,
works fine on various architectures, and if we've got massive and
positive user feedback on it), we might try and push it into the next
Debian stable as well, but that's not sure it'll be feasible. That would
be the 2nd plan.
If we have to stick with plan 1, we'll provide enblend 3.1 and probably
hugin 0.7 (once it's released) through backports.org, which should be a
not-so-bad solution for people that would need full features.
Some questions:
- I've added enblend to the dependencies of the hugin package, which
contains hugin, hugin_stitch_project, and nona_gui. I think it's the
right place, but maybe it's also needed for one (or several) of the
binaries that are available in the hugin-tools package (that is: all
the other binaries)?
- Same question for make, and exiftool.
A remark:
- Could you please rename doc/autooptimizer.pod into
doc/autooptimiser.pod? I've added a quick hack so that we still ship
the appropriate manpage, though.
Mraw,
KiBi.
Bruno Postle
>
>If we have to stick with plan 1, we'll provide enblend 3.1 and probably
>hugin 0.7 (once it's released) through backports.org, which should be a
>not-so-bad solution for people that would need full features.
Ok, if you are going to combine hugin-0.7.0 and enblend-3.0 I
suggest that you ship a dummy 'enfuse' with this enblend.deb that
looks something like this:
#!/bin/sh
echo "Error, you need at least enblend-3.1 for exposure blending"
/bin/false
>Some questions:
> - I've added enblend to the dependencies of the hugin package, which
> contains hugin, hugin_stitch_project, and nona_gui. I think it's the
> right place, but maybe it's also needed for one (or several) of the
> binaries that are available in the hugin-tools package (that is: all
> the other binaries)?
none of the binaries call enblend directly, but if you are stitching
using the Makefile system on the command-line then you would need
nona, make, exiftool and enblend (and enfuse if you are 'exposure
blending').
So the hugin GUI definitely requires enblend, the 'normal' use of
the command-line tools would usually involve enblend, but it is
quite possible that there is a valid use of the hugin command-line
tools that doesn't involve enblend.
> - Same question for make, and exiftool.
hugin-gui requires: hugin-tools, enblend, make, exiftool
hugin-tools suggests: enblend, make, exiftool
>A remark:
> - Could you please rename doc/autooptimizer.pod into
> doc/autooptimiser.pod?
Done, sorry we haven't integrated them into the install target yet.
--
Bruno
Cyril Brulebois
Bruno Postle <br...@postle.net> (28/07/2008):
> On Sun 27-Jul-2008 at 06:33 +0200, Cyril Brulebois wrote:
> > If we have to stick with plan 1, we'll provide enblend 3.1 and
> > probably hugin 0.7 (once it's released) through backports.org, which
> > should be a not-so-bad solution for people that would need full
> > features.
>
> Ok, if you are going to combine hugin-0.7.0 and enblend-3.0 I
> suggest that you ship a dummy 'enfuse' with this enblend.deb that
> looks something like this:
>
> #!/bin/sh
> echo "Error, you need at least enblend-3.1 for exposure blending"
> /bin/false
… since Sebastian might include that in a further upload of 3.0, which
should be granted a freeze exception since it's mostly documentation
(I'm thinking of such a script with a pointer to a file documenting the
situation).
> > - I've added enblend to the dependencies of the hugin package, which
> > contains hugin, hugin_stitch_project, and nona_gui. I think it's
> > the right place, but maybe it's also needed for one (or several)
> > of the binaries that are available in the hugin-tools package
> > (that is: all the other binaries)?
>
> none of the binaries call enblend directly, but if you are stitching
> using the Makefile system on the command-line then you would need
> nona, make, exiftool and enblend (and enfuse if you are 'exposure
> blending').
Looks like I've got to learn more about that Makefile system, then. At
least someone having installed “hugin” (hugin-gui) should be safe.
> So the hugin GUI definitely requires enblend, the 'normal' use of the
> command-line tools would usually involve enblend, but it is quite
> possible that there is a valid use of the hugin command-line tools
> that doesn't involve enblend.
>
> > - Same question for make, and exiftool.
>
> hugin-gui requires: hugin-tools, enblend, make, exiftool
OK, I got this right at least.
> hugin-tools suggests: enblend, make, exiftool
That, not yet, but since I believe most users will install “hugin”,
which pulls “hugin-tools”, they should be safe anyway. I'll fix this
when possible.
Thanks for your answers.
> Done, sorry we haven't integrated them into the install target yet.
No problem, I still had my tiny loop around, and I kept it in our
Makefile.
Mraw,
KiBi.
Sebastian Harl
On Tue, Jul 29, 2008 at 06:34:56AM +0200, Cyril Brulebois wrote:
> Cc'ing pkg-phototools???
FYI, I'm now subscribed to hugin-ptx as well... ;-)
> Bruno Postle <br...@postle.net> (28/07/2008):
> > On Sun 27-Jul-2008 at 06:33 +0200, Cyril Brulebois wrote:
> > > If we have to stick with plan 1, we'll provide enblend 3.1 and
> > > probably hugin 0.7 (once it's released) through backports.org, which
> > > should be a not-so-bad solution for people that would need full
> > > features.
> >
> > Ok, if you are going to combine hugin-0.7.0 and enblend-3.0 I
> > suggest that you ship a dummy 'enfuse' with this enblend.deb that
> > looks something like this:
> >
> > #!/bin/sh
> > echo "Error, you need at least enblend-3.1 for exposure blending"
> > /bin/false
>
> ??? since Sebastian might include that in a further upload of 3.0, which
> should be granted a freeze exception since it's mostly documentation
> (I'm thinking of such a script with a pointer to a file documenting the
> situation).
Sounds good to me. I was actually already thinking about shipping a
shell wrapper around enblend as well to filter out 3.1-specific command
line options and printing a warning when they were used. I'm not
entirely sure if that's a good thing to do though. Any comments?
Cheers,
Sebastian
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin