what is hugin doing to the exposure?
don
I've come over this problem recently. I was using Hugin (with
autopanosift and enblend) about 2 years ago and for simple panoramas
(1 row of photos with fixed exposure) it worked perfectly. I installed
new Hugin recently (Version 0.7.0 (SVN 3465)) and when using the
stitching wizard, the results are very strange - even though the
exposure was fixed in both photos, Hugin makes something with them and
that results in A) very weird brightness/contrast and B) in visible
seams between the photos. The settings of the stitcher tab are here:
http://don.vn.cz/temp/repo/hugin/panosettings.gif
here is the result from Hugin: http://don.vn.cz/temp/repo/hugin/panohugin.jpg
here is the result from photoshop's photomerge:
http://don.vn.cz/temp/repo/hugin/panophotoshop.jpg
any tips? thank you.
dkloi
> Hugin makes something with them and
> that results in A) very weird brightness/contrast and B) in visible
> seams between the photos. The settings of the stitcher tab are here:http://don.vn.cz/temp/repo/hugin/panosettings.gif
>
> here is the result from Hugin:http://don.vn.cz/temp/repo/hugin/panohugin.jpg
> here is the result from photoshop's photomerge:http://don.vn.cz/temp/repo/hugin/panophotoshop.jpg
>
> any tips? thank you.
processed from RAW? You may not get the same output even though the
exposure was fixed, depending on the exact processing chain.
Try using the exposure optimisation tab, it'll fine tune the
differences between the two image. It also means that you no longer
have to lock exposure between taking source images, very useful if the
scene has much different brightness in different parts. I've been
using auto-exposure ever since this feature was introduced and only
need to bracket if the contrast is too great within a single frame.
Example:
http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Clarke_Quay_small.jpg
I didn't need to bracket this 6+1+1 pano. Exposures ranged from 0.5s
to 2s at f/5.6. I also optimised the RAW development of each
individual frame to balance shadow and highlight detail. Exposure
optimisation was able to match all these widely different exposed
frames.
Cheers,
Daniel.
Bart van Andel
[...]
> any tips? thank you.
Tip: you're still using a fairly old version. Version 0.8.0 has come
out not so long ago, and we are over 1000 svn commits further than
your current version. Newer versions might solve your issue, so please
try this first. You haven't supplied which OS you're using, but (links
to) instructions where to find recent builds for Windows, Linux or OSX
or compile them yourself can always be found on Yuv's blog [1].
[1] http://panospace.wordpress.com/downloads/
--
Bart
don
tab, but that didn't give me any good result. The source photos are
JPEGs, straight from camera, both shot at 1/160 f11 @ ISO 100. To me
it seems like Hugin is doing some kind of exposure optimisation which
is not really necessary, hence the strange result. Perhaps it's worth
mentioning that I'm using the stitch assistent - I choose the two
photos from my hard drive, press ALIGN and when Hugin shows me
Panorama preview, it already looks strange (http://don.vn.cz/temp/repo/
hugin/huginpreview.jpg)
On 9 říj, 14:36, dkloi <dkl...@googlemail.com> wrote:
> On 9 Oct, 09:22, don <don...@gmail.com> wrote:
>
> > Hugin makes something with them and
> > that results in A) very weird brightness/contrast and B) in visible
> > seams between the photos. The settings of the stitcher tab are here:http://don.vn.cz/temp/repo/hugin/panosettings.gif
>
> > here is the result from Hugin:http://don.vn.cz/temp/repo/hugin/panohugin.jpg
> > here is the result from photoshop's photomerge:http://don.vn.cz/temp/repo/hugin/panophotoshop.jpg
>
> > any tips? thank you.
>
> How did you take and process the input images? In camera JPG, or
> processed from RAW? You may not get the same output even though the
> exposure was fixed, depending on the exact processing chain.
>
> Try using the exposure optimisation tab, it'll fine tune the
> differences between the two image. It also means that you no longer
> have to lock exposure between taking source images, very useful if the
> scene has much different brightness in different parts. I've been
> using auto-exposure ever since this feature was introduced and only
> need to bracket if the contrast is too great within a single frame.
>
don
download - the latest ones seem to be for Windows Vista only. So I
tried installing "hugin-SVN3943-setup.exe" but the result is still the
same...
Lukáš Jirkovský
if you've fixed exposure it should be enough to reset the exposure settings.
All you need to do is to go to the "Camera and Lens" select all images and:
1. in new version click on "Reset" button and select exposure.
2. in old version click on "Load EXIF". You may need to re-optimize
project in "Optimizer" tab then.
Lukas
Bart van Andel
answer and my new reply)
On Fri, Oct 9, 2009 at 3:37 PM, don <don...@gmail.com> wrote:
> I'm on Windows XP SP3. Not sure which version I can download, the
> latest ones seem to be for Windows Vista only, so i tried "hugin-
> SVN3943-setup.exe" - and the result is still abou the same.
Why not try the newest one? If it works on XP and you inform Ad
(either through this list or by email) he can inform others about this
fact too, just like Oskar Sander did with the build you've just tried.
Anyway, there's a tab called "Exposure", which is where you can apply
exposure correction to the images. This should improve your result.
--
Bart
dkloi
> Thanks for the advice. I tried fiddling with the settings in EXPOSURES
> tab, but that didn't give me any good result. The source photos are
> JPEGs, straight from camera, both shot at 1/160 f11 @ ISO 100. To me
> it seems like Hugin is doing some kind of exposure optimisation which
> is not really necessary, hence the strange result. Perhaps it's worth
> mentioning that I'm using the stitch assistent - I choose the two
> photos from my hard drive, press ALIGN and when Hugin shows me
> Panorama preview, it already looks strange (http://don.vn.cz/temp/repo/
> hugin/huginpreview.jpg)
Low Dynamic Range, or Low Dynamic Range with Variable White balance,
and then optimise. Preview the stitch, the images should overlap
pretty well even without blending.
Example Pre-Exposure Optimisation http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/AlignImages.jpg
Example Post-Exposure Optimisation, no blending
http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/NotBlended.jpg
You camera could be doing some processing to the image prior to
writing out the JPEG which could be the source of your problem. Make
sure the EV numbers are the same for both images in the Camera and
Lens tab. Hugin uses the EV numbers to calculate the relative
brightness of the images.
Cheers,
Daniel.
don
latest version (0.8.0.3943 Ad Huikeshoven), which was said to work on
Vista. I chose default installation, run Hugin.exe, loaded images,
pressed Align, it started looking for control points but in the end it
didn't find any (previous versions did).I addded the control points
manually and then did some exposure optimalization - the end result
was nearly OK, but still I think that PS CS4 produced it slighly
better. But because I'm too lazy to add control points manually, I
went back to the last fully working version (0.8.0.3943 Ad
Huikeshoven), did the same (except adding control points manully - the
assistant took care of this), then did the optimalization (low dynamic
range)...and the end result was bad again. I believe I must be doing
something very wrong, because this seems like incredibly easy task and
I'd swear that few years back it would have worked for me in Hugin
without any problems.
Daniel, my panorama preview looks nothing like yours - I can clearly
see the stitches in mine. It is not that bad in Fast Preview Panorama
as it is in Preview Panorama (what is the difference?) though.
If any of you would like to try and have a go with the photos, I've
uploaded them here:
http://don.vn.cz/temp/repo/hugin/_MG_8888small.jpg
http://don.vn.cz/temp/repo/hugin/_MG_8889small.jpg
thanks guys.
On 10 říj, 03:56, dkloi <dkl...@googlemail.com> wrote:
> On 9 Oct, 14:24, don <don...@gmail.com> wrote:
>
> > Thanks for the advice. I tried fiddling with the settings in EXPOSURES
> > tab, but that didn't give me any good result. The source photos are
> > JPEGs, straight from camera, both shot at 1/160 f11 @ ISO 100. To me
> > it seems like Hugin is doing some kind of exposure optimisation which
> > is not really necessary, hence the strange result. Perhaps it's worth
> > mentioning that I'm using the stitch assistent - I choose the two
> > photos from my hard drive, press ALIGN and when Hugin shows me
> > Panorama preview, it already looks strange (http://don.vn.cz/temp/repo/
> > hugin/huginpreview.jpg)
>
> What exactly did you fiddle with in the exposure tab? Try selecting
> Low Dynamic Range, or Low Dynamic Range with Variable White balance,
> and then optimise. Preview the stitch, the images should overlap
> pretty well even without blending.
>
> Example Post-Exposure Optimisation, no blendinghttp://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/NotBlended.jpg
RizThon
I just dropped your 2 images in hugin (it automatically chooses "Normal (rectilinear)", 24mm and 3.43 for the lens info), I automatically added the control points and clicked the "Stitch now!" button (all default / automatic values: Rectilinear, FOV 36x20, size 1494x811, "Blended panorama" checked)and I get a nice blended panorama...
Here's the pto project:
# hugin project file
#hugin_ptoversion 2
p f0 w1494 h811 v36 E14.2408 R0 n"TIFF_m c:NONE r:CROP"
m g1 i0 f0 m2 p0.00784314
# image lines
#-hugin cropFactor=3.42522
i w1600 h1067 f0 Eb1 Eev14.2407913106641 Er1 Ra-0.487184405326843 Rb-0.656815350055695 Rc0.530101180076599 Rd-0.175079703330994 Re0.266844481229782 Va1 Vb-0.562101693275359 Vc0.697986748519527 Vd-0.465450043300806 Vx0 Vy0 a0.00981937612810012 b-0.0242854440807008 c0.115908411251388 d0 e0 g0 p1.86975840070512 r7.45839605972155e-017 t0 v24.6992627798865 y-6 Vm5 u10 n"_MG_8888small.jpg"
#-hugin cropFactor=3.42522218289397
i w1600 h1067 f0 Eb1 Eev14.1310773935208 Er1 Ra=0 Rb=0 Rc=0 Rd=0 Re=0 Va=0 Vb=0 Vc=0 Vd=0 Vx=0 Vy=0 a=0 b=0 c=0 d=0 e=0 g=0 p1.94688357427167 r-4.58960554821018e-014 t=0 v=0 y5.3315254049968 Vm5 u10 n"_MG_8889small.jpg"
# specify variables that should be optimized
v p1 r1 y1
v
# control points
c n0 N1 x1079.11301 y596.213184 X373.027032 Y602.18922 t0
c n0 N1 x1220.530422 y599.102304 X515.502063 Y602.735974 t0
c n0 N1 x1162.478479 y611.132028 X458.413643 Y615.554016 t0
c n0 N1 x1151.312451 y610.784152 X447.697109 Y615.451378 t0
c n0 N1 x1156.34132 y624.963225 X452.109932 Y629.637137 t0
c n0 N1 x1255.329885 y586.293772 X548.894429 Y591.38195 t0
c n0 N1 x1156.34132 y624.963225 X452.109932 Y629.637137 t0
c n0 N1 x1293.826983 y536.78735 X583.969347 Y542.337458 t0
c n0 N1 x1452.982383 y578.174896 X718.702932 Y579.499934 t0
c n0 N1 x1000.783409 y539.74238 X288.310223 Y543.714683 t0
c n0 N1 x1184.090007 y599.721106 X480.139624 Y603.590377 t0
c n0 N1 x1508.872868 y617.994293 X762.222422 Y613.007973 t0
c n0 N1 x1493.373942 y613.081415 X749.654938 Y609.450382 t0
c n0 N1 x1255.329885 y586.293772 X548.894429 Y591.38195 t0
c n0 N1 x922.505554 y584.044079 X197.687794 Y591.935524 t0
c n0 N1 x1000.783409 y539.74238 X288.310223 Y543.714683 t0
c n0 N1 x946.718196 y584.221199 X224.062558 Y592.061588 t0
c n0 N1 x1097.636405 y556.367918 X393.459208 Y561.809487 t0
c n0 N1 x1481.369191 y624.845392 X738.565614 Y620.145061 t0
c n0 N1 x1554.910862 y629.042134 X795.170011 Y622.561956 t0
#hugin_optimizeReferenceImage 0
#hugin_blender enblend
#hugin_remapper nona
#hugin_enblendOptions
#hugin_enfuseOptions
#hugin_hdrmergeOptions
#hugin_outputLDRBlended true
#hugin_outputLDRLayers false
#hugin_outputLDRExposureRemapped false
#hugin_outputLDRExposureLayers false
#hugin_outputLDRExposureBlended false
#hugin_outputHDRBlended false
#hugin_outputHDRLayers false
#hugin_outputHDRStacks false
#hugin_outputLayersCompression PACKBITS
#hugin_outputImageType jpg
#hugin_outputImageTypeCompression NONE
#hugin_outputJPEGQuality 80
#hugin_outputImageTypeHDR exr
#hugin_outputImageTypeHDRCompression
RizThon
don
tried to use the resized photos I linked here - it stitched it without
problems. So I then took the original files (5616x3744) and did the
same process - and now the stitch looks bad again.
On 12 říj, 10:17, RizThon <rizt...@gmail.com> wrote:
> By the way in the Fast Preview i can also easily see the intersection of the
> 2 pictures because they don't match perfectly (the horizon is good but in
> the sky a cloud isn't stitched correctly and same a lot closer on the grass)
> and there's some visible vignetting. But the blended panorama is just
> perfect.
>
RizThon
Also previously I said that I could clearly distinguish the 2 pictures in the fast preview, but it's not as pronounced as on your screenshot http://don.vn.cz/temp/repo/hugin/huginpreview.jpg where it really looks like the exposure of the 2nd picture was modified.
don
http://don.vn.cz/temp/repo/hugin/_MG_8888.JPG
http://don.vn.cz/temp/repo/hugin/_MG_8889.JPG
(both files are 7 MB big)
On 12 říj, 11:52, RizThon <rizt...@gmail.com> wrote:
> Can you post the original pictures? I'll just check if I get the same
> results as you...
>
> Also previously I said that I could clearly distinguish the 2 pictures in
don
some problems?
On 12 říj, 12:20, don <don...@gmail.com> wrote:
> here are the originalshttp://don.vn.cz/temp/repo/hugin/_MG_8888.JPGhttp://don.vn.cz/temp/repo/hugin/_MG_8889.JPG
>
> On 12 říj, 11:52, RizThon <rizt...@gmail.com> wrote:
>
> > Can you post the original pictures? I'll just check if I get the same
> > results as you...
>
> > Also previously I said that I could clearly distinguish the 2 pictures in
RizThon
Bart van Andel
- Open Hugin 2009.2.4450 (by Ad), on my Windows Vista SP3 setup.
- Clicked "Align..." on the assistant tab, which started APSCpp 2.5.2.
As you can see in the output which I pasted below, something is going
wrong: APSCpp is reporting FOV of 180 degrees. It should be closer to
75 degrees, if the 24mm reported focal length is correct. This is a
(known) bug with the current 2.5.2 build.
- Trying the "Create control points" button using Panomatic instead
(Images tab), the images got aligned well enough. Not perfect, but
well enough.
- Opened the GL preview. The image borders are clearly visible, partly
from the imperfect overlap, but also in the blue part of the sky.
- Opened the traditional preview. Image borders less well pronounced.
- Ran Exposure optimization with the default setting (low dynamic
range). The traditional preview looks better now, while the GL preview
still shows the same borders (pressing the Photometrics button shows
the optimized results, which are quite good).
- Stitching results in a seamless stitch.
NB: upon trying with an older version of APSCpp (the one supplied with
SVN 4075), the "Align" button in the assistant tab yields a perfect
result (including correct exposures) right away.
--
Bart
APSCpp output below
---------
APSCpp, enhanced autopano-sift-c version 2.5.2 23July2009
Default fisheye lens type is equal-area.
Focal length will be computed from hfov.
Stereographic projection enabled for hfov >= 65.0 degrees.
Filename C:\temp\panotemp\_MG_8888.JPG
rectilinear width 5616 height 3744 hfov 180
reduce to 1600 x 1066 (Scale 3.5100)...
convert to stereographic projection ...
find keypoints ...
32 keypoints found
Filename C:\temp\panotemp\_MG_8889.JPG
rectilinear width 5616 height 3744 hfov 180
reduce to 1600 x 1066 (Scale 3.5100)...
convert to stereographic projection ...
find keypoints ...
15 keypoints found
---------
On 12 okt, 12:20, don <don...@gmail.com> wrote:
> here are the originalshttp://don.vn.cz/temp/repo/hugin/_MG_8888.JPGhttp://don.vn.cz/temp/repo/hugin/_MG_8889.JPG
>
Yuval Levy
Bart van Andel wrote:
> - Open Hugin 2009.2.4450 (by Ad), on my Windows Vista SP3 setup.
> - Clicked "Align..." on the assistant tab, which started APSCpp 2.5.2.
It can't be APSCpp 2.5.2 - APSCpp 2.5.2 has not been released yet.
If a binary says it is 2.5.2... caveat emptor.
The current status of APSCpp:
* 2.5.2 does not exist. The trunk, that will eventually become 2.5.2, is
broken, work in progress, with no estimated time to fix. Nobody is
actively working on it *now*. Nobody should distribute binaries made
from APSCpp's trunk, as requested by Bruno a few weeks ago.
* 2.5.0 is the official "stable" release, but it has memory leaks and is
likley to crash on large projects / low memory.
* Bruno issued recently a tarball of APSCpp 2.5.1 (RC2 right now) which
is 2.5.0 + fixes. The RCs are also tagged in SVN. RC2 is the recommended
one to build and distribute, and is likely to become the official stable
release before the end of the month.
> NB: upon trying with an older version of APSCpp (the one supplied with
> SVN 4075), the "Align" button in the assistant tab yields a perfect
> result (including correct exposures) right away.
I don't recall what version of APSCpp is delivered with Ad's SVN 4075
snapshot (note that SVN 4075 is not enough to characterize a version of
Hugin - it could be trunk/4075; or 2009.2/4075; or 0.7.0/4075).
From what you describe it seems that it is 2.5.0.
Bottom line of all of this: CAVEAT EMPTOR. Verify binaries before using
them and before trusting them to do what you expect them to do.
Thanks Bart for going through the pains of doing it.
Yuv
Bart van Andel
> Thank you, Bart, for going through this well done analysis.
You're being sarcastic, which is okay, but this might indicate that
the version information on APSCpp (and probably other tools as well)
is not descriptive enough in its current form.
APSCpp from Ad's 4075 build ("Version 0000.00.0.4075 Ad Huikeshoven"
in hugin's About screen -- it isn't mentioned anywhere from which
branch, not inside Hugin, not on Ad's download page, but on this group
[1] it is mentioned as "SVN version 4075, or hugin 0.8.0-rc5") simply
says "Version 2.5.0 for hugin 0.7". The version supplied with Ad's
4012 build is an exact binary copy.
APSCpp from Ad's 4450 build ("Version 2009.2.4450") says "Version
2.5.2 23July2009" which is apparently incorrect. Maybe it should be
mentioned in the version information that this is an alpha or
development prerelease? Currently it's confusing. And yes, this
version is broken [2].
What about a new command line argument "--version" which gives
detailed version information, like: version number, build state (alpha/
beta/rc/release etc), which branch (can this even be done
automatically?), SVN revision, build date, compiler, build by whom?
Sounds like a nice job for a fresh Hugin programmer (including myself,
but I currently should really be doing other things).
[1] http://groups.google.com/group/hugin-ptx/browse_thread/thread/9f37a2e61f6df4b9/d8beb0d42999c95d
[2] http://groups.google.com/group/hugin-ptx/browse_thread/thread/1ada7205b99df03f/3edfa168b49ba7d3?lnk=gst&q=4450#3edfa168b49ba7d3
--
Bart
Yuval Levy
> On 12 okt, 19:00, Yuval Levy <goo...@levy.ch> wrote:
>> Thank you, Bart, for going through this well done analysis.
>
>> If a binary says it is 2.5.2... caveat emptor.
> Point taken. It sounded really convincing though... ;)
>
> You're being sarcastic, which is okay
I AM NOT SARCASTIC. I AM DEAD SERIOUS (AND YES, I AM SCREAMING, BECAUSE
IT SEEMS THAT USERS DON'T HEAR THE MESSAGE).
> but this might indicate that
> the version information on APSCpp (and probably other tools as well)
> is not descriptive enough in its current form.
that's part of the problem. Let's see if I can make it clear.
"Caveat emptor" means that if you download something from somewhere, you
should check that it is what it says to be.
This starts with the builder. It is the builder's responsibility to make
sure the code that he downloaded from SourceForge is not tampered. This
is why we have sha1 checksums.
Tampering can happen along the road. An error in an internet
transmission. Or a malicious attack on SourceForge. Or plenty of other
things.
Once the code is on the builder's machine even more things can go wrong
- a bug in the build chain, an obscure corrupt registry entry, a
firewall blocking a critical operation, a virus or trojan infecting the
freshly created binary... you name it. There is a lot of risk involved,
and I have not even mentioned *intentional tampering* - e.g. a malicious
person wanting to spread a virus will piggy-back on users' blind
excitement for free (as in beer) software
It is the end-users' responsibility to verify what executable they
download and run on their system.
The builder can be proactive and help them; communicate to them what he
built from; how he built; and providing checksums. But this is
completely out of control of the Hugin project.
What we can control is that the sourcecode that we upload to SF is
"good". We do this with a basic test before uploading; and with sha1
checksums to guarantee integrity.
We also try to automate and systemize version naming to give
*additional* indication of what this stuff is, but it is *very easy* for
anybody to change the version string. Bottom line: don't rely on a
version string only.
> APSCpp from Ad's 4075 build ("Version 0000.00.0.4075 Ad Huikeshoven"
> in hugin's About screen -- it isn't mentioned anywhere from which
> branch, not inside Hugin, not on Ad's download page, but on this group
> [1] it is mentioned as "SVN version 4075, or hugin 0.8.0-rc5") simply
> says "Version 2.5.0 for hugin 0.7". The version supplied with Ad's
> 4012 build is an exact binary copy.
Nice research. *I* could build a very simple program whose only purpose
is "format C:\" and make it look like Hugin, and have the same version
string "Version 0000.00.0.4075 Ad Huikeshoven". So what do you do next?
run it? then complain with Ad? or with the Hugin team?
> What about a new command line argument "--version" which gives
> detailed version information, like: version number, build state (alpha/
> beta/rc/release etc), which branch (can this even be done
> automatically?)
you're trying to solve the wrong problem with the wrong tool.
Wrong problem: it does not matter what Hugin or APSCpp *say* - if you've
come so far, you've already exposed yourself to a major risk.
Wrong tool: if what you look for is "build state", there are only two
states: official: download from SourceForge. unofficial: everything
else. CAVEAT EMPTOR.
That said, it is not that we are not trying to give you information.
Ad has improved his communication. On his website he tries to mention
which version of the most dynamic projects (autopano, libpano,
enblend/enfuse and of course Hugin) he uses. That communication could be
improved with the branch when there are branches in the repository. Just
an SVN number does not say which branch was used, and Hugin trunk/4450
is different than Hugin 2009.2/4450. It will perform differently and
will deceive user's expectations. Moreover, Ad's installers do not have
a sha1 checksum. How do I know that I downloaded what he uploaded? that
his server has not been attacked and tampered by a third party? that
something went wrong in the pipes?
We, the Hugin team, have improved communication. Much of the sensible
version information is already in the Hugin tools. APSCpp is not a Hugin
tool and follows a different convention. Build state is not relevant
(see above) and would require manual intervention, which means there
would be omissions and mistakes. We currently automate the basic thing
which is version number (odd/even minor version for trunk/release), and
the SVN number. For Windows there is an additional check where the
Builder has to enter a name and a date, but these are not verified
entries - I can run the CMake build system and enter "Barack Obama" in
the HUGIN_BUILDER field and "25-Dec 24 B.C." on the build date.
And what can't be done automatically is not worth doing because there
will be errors and omissions.
, SVN revision, build date, compiler, build by whom?
> Sounds like a nice job for a fresh Hugin programmer (including myself,
> but I currently should really be doing other things).
yeah, right. there are always other things to do. then just don't get
into trouble. if you don't have time to verify what you download before
installing it, don't install it.
Yuv
Bart van Andel
Of course you're completely right (and I'm dead serious too, sorry
that I misunderstood). You can never really trust anything you
download, or rely blindly on what a program says to be.
> > What about a new command line argument "--version" which gives
> > detailed version information, like: version number, build state (alpha/
> > beta/rc/release etc), which branch (can this even be done
> > automatically?)
>
> you're trying to solve the wrong problem with the wrong tool.
idea. I was only mentioning it because it *might* help making
different versions / builds *better* distinguishable than they are
now. Of course anyone can still tamper with it. But at least with
versions downloaded from sf.net, it may become easier to point a
finger correctly. As long as people download their builds (or, albeit
a little less reliable, unaltered source code) from sf.net and find
problems, they can tell with a higher accuracy which version is to
blame.
By the way I'm just copying the --version idea from lots of other
tools available everywhere. If so many tools are using it, I reckon it
can't be that bad an idea...
> > Sounds like a nice job for a fresh Hugin programmer (including myself,
> > but I currently should really be doing other things).
>
> yeah, right. there are always other things to do.
take more time than I should currently spend. It's a matter of
priority, and there are only so many hours in a week/day etc. In time,
I will...
--
Bart
Bruno Postle
>
>By the way I'm just copying the --version idea from lots of other
>tools available everywhere. If so many tools are using it, I reckon it
>can't be that bad an idea...
With the current Hugin trunk the command-line tools -h option does
tell you the exact current version:
nona -h
nona: stitch a panorama image
nona version 2009.5.0.4622
The next enblend release will have a --version string that includes
all sorts of information including the name of the person who built
the binary.
--
Bruno