Windows hugin-2010.2.0_rc1 Build
Matthew Petroff
http://www.box.net/shared/k5zn0d9bsh
A Windows installer can be found here:
http://www.box.net/shared/bxcdivzsaz
Matthew
Oskar Sander
Nice thankyou!
Is this using the new windows installer, any experiences on the list using this build?
/O
--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
--
/O
kfj
On Sep 20, 5:09 pm, Oskar Sander <oskar.san...@gmail.com> wrote:
> Is this using the new windows installer, any experiences on the list using
> this build?
low in the path (some auxiliary software has issues with spaces in
file paths, so it's always a good idea to avoid this sort of trouble).
It runs fine, and an issue I had earlier with erroneous handling of
the loading of stereographic images has disappeared with it. So far I
haven't noticed anything untoward, but I've also been busy with other
stuff, so I haven't really tested it much, either.
KFJ
kfj
There seems to be a problem with the CPGs. In the installation dialog,
I checked all CPGs to be installed. Of the four, the installation text
mentions only match-n-shift, panomatic and autopano, so autopano-sift-
c is omitted. Of these, only match-n-shift and panomatic appear in my
target directory, autopano is missing.
Of the two which have made it to my installation, Panomatic works most
of the time, but match-n-shift creates no control points (I think it
fails somewhere along the way, but I can't see if it prints an error
message since the window closes so quickly. the lengthy process of
putting images into a temporary directory runs, but after that, the
CPG terminates very suddenly)
with regards
KFJ
kfj
hugin I could track down, including installation directories and start
menu entries, on my Windows system, to try and make a fresh install
with no relics from previous installations. Then I installed into a
new path. Again I asked for all CPGs to be installed, and the
installation dialog said it was downloading them. But the same CPG
omissions I noticed earlier still apply. If the new stuff is just
installed over a current installation, all the old CPGs will still be
there, so the problem might not manifest. Of course it might be that
the missing CPGs are actually downloaded to somewhere where I can't
find them, but I couln't find them anywhere :(
I also noticed that I could not get rid od my old CPG settings, and I
have no idea where they are actually stored. In the registry perhaps?
I would have liked to get rid of them before doing my install-to-a-
clean-state attempt.
The newly installed CPGs and the CPG settings (also for the missing
ones) produce problems on my system. match-n-shift won't run - now
this may be because I don't have ImageMagick installed, but the
version that the installer installs does not know the -m (nomagick)
flag. If I replace it with m-n-s from my previous install, it runs, if
I give it the right autopano to work with. And what about the -a and -
b flags? What are they for?
As far as autopano is concerned, there is a name conflict here with
autopano by A. Jenny and autopano by S. Nowozin, which is a different
thing altogether. A. Jenny's is used as standalone CPG, whereas
Nowozin's is used with existing .key files (like in conjunction with
generatekeys), if my understanding is correct.
And the settings for autopano-sift-c include '--projection %f,%v',
which does not work with the autopano-sift-c.exe I took from my
previous installation [version 2.5.2] (since the installer didn't
actually install it).
Now that I have all the (old) CPGs together again, the new hugin runs
well and only occasionally crashes (sometimes after using panomatic,
but I can't figure out when and when not) - so far I haven't found
anything crucially wrong with it. But I think the CPG deployment needs
some finetuning ;)
with regards
KFJ
Matthew Petroff
http://www.box.net/shared/hnf7vgtjp2
All of the control point generators should install properly now.
All of them work properly for me on a clean install except match-n-
shift. When selected, hugin runs PTmender instead, but I can't figure
out why.
On Sep 24, 11:24 am, kfj <_...@yahoo.com> wrote:
> I also noticed that I could not get rid od my old CPG settings, and I
> have no idea where they are actually stored. In the registry perhaps?
them you had to check "Clean Registry Settings" when you ran the
uninstaller.
I also made changes to Panomatic.nsh in order to take advantage of
SourceForge mirrors. A random mirror from a list of ten is chosen for
the download of Panomatic, and if it fails the other mirrors are tried
until one works. In addition, I changed HuginSetup_common.nsh to set
the default control point generator to one of the ones the installer
downloads, if it does so.
These changes are available here: http://www.box.net/shared/b8gg663s0g
Matthew
kfj
> Here is a new installer based on the latest script:http://www.box.net/shared/hnf7vgtjp2
>
> All of the control point generators should install properly now.
their intarface with hugin is still partly flawed. And there are still
some bits missing.
I have installed hugin with your new installer, and I think you
haven't taken into account the point I have made previously about
autopano.exe. Please note that there are two different programs which
both use this name and are totally incompatible, as far as their
command lines are concerned.
The first one is autopano by A. Jenny. This is the one which your
installer installs as autopano.exe. It takes command line arguments
with leading slashes, and a valid set of arguments line [from the
hugin CPG settings dialog] looks something like
/allinone /path:%d /keys:%p /project:oto /name:%o /size:1024 /f %i
you use this command line in the 'autopano 103' settings. Quite
rightly this CPG is labeled as being of type 'autopano (by A. Jenny)'
The second one is autopano by S. Nowozin. your installer does not
install this one. I have a version 2.5.2 from a previous install; I'm
not entirely certain which installer installed it, because the newest
I can find on Nowozins web page is 2.3 or 2.4. This program takes
command line parameters with leading minusses, a valid command line
[from the hugin CPG settings dialog] looks like
autopano --maxmatches %p %o %k
and it is a different program altogether. It is used in the 'Autopano-
SIFT-C (multirow/stacked)' CPG setting as the second stage of the CPG
process. This two-stage-process also uses a program called
generatekeys.exe as it's first stage, which your installer does not
install, so the attempt to use 'Autopano-SIFT-C (multirow/stacked)'
fails for two reasons:
- generatekeys.exe is missing
- the wrong autopano.exe is called
> All of them work properly for me on a clean install except match-n-
> shift. When selected, hugin runs PTmender instead, but I can't figure
> out why.
combines several programs to achieve it's goal:
a) it calls PTmender to warp the images according to their projection
b) it calls generatekeys.exe to extract SIFT features from the warped
images
c) it uses autopano (by S. Nowozin, not A. Jenny) to create a pto
so the call to PTmender is only the first step. match-n-shift has to
have generatekeys.exe and autopano.exe (by S. Nowozin) present to
function.
So match-n-shift cannot work if it does not have both generatekeys and
autopano (by S. Nowozin).
Since match-n-shift seems to have the calls to generatekeys and
autopano hardcoded, and 'Autopano-SIFT-C (multirow/stacked)' also uses
these two programs by these names, I think the easiest way out is to
give autopano by A. Jenny a different name (like
autopano_by_jenny.exe) - or put it into a subdirectory, and change the
settings for 'Autopano 103' to call this program.
To get 'Autopano-SIFT-C (multirow/stacked)' and 'Match-n-shift' to
work, you must also install generatekeys.exe and autopano.exe (by S.
Nowozin). This will involve an additional download, since Nowozin also
uses the SIFT algorithm (correct me if I'm wrong).
I hope this will sort out the CPG issues with your installer! Thanks
for caring about the Windows side of things, it's about time a recent
version of hugin becomes available to Windows users by a route they
feel comfortable with.
with regards
KFJ
PhG
:)
Bruno Postle
>
>If I understand match-n-shift correctly, it is a perl script which
>combines several programs to achieve it's goal:
>
>a) it calls PTmender to warp the images according to their projection
>b) it calls generatekeys.exe to extract SIFT features from the warped
>images
>c) it uses autopano (by S. Nowozin, not A. Jenny) to create a pto
This is an older version of match-n-shift, recent versions use
autopano-sift-c directly instead of generatekeys/autopano.
..but all the useful functionality of match-n-shift (support for
bracketed stacks, control-point cleaning) is now in Hugin, so really
there is no need to ship match-n-shift.exe with a Hugin installer.
--
Bruno
kfj
On Sep 25, 2:52 pm, Bruno Postle <br...@postle.net> wrote:
> This is an older version of match-n-shift, recent versions use
> autopano-sift-c directly instead of generatekeys/autopano.
anyway?
KFJ
thePanz
And thank you for the Windows build (could you also provide a x64
one?)
On Sep 25, 4:23 am, Matthew Petroff <matt...@mpetroff.net> wrote:
> Control point generator settings are stored in the registry. To remove
> them you had to check "Clean Registry Settings" when you ran the
> uninstaller.
>
> I also made changes to Panomatic.nsh in order to take advantage of
> SourceForge mirrors. A random mirror from a list of ten is chosen for
> the download of Panomatic, and if it fails the other mirrors are tried
> until one works. In addition, I changed HuginSetup_common.nsh to set
> the default control point generator to one of the ones the installer
> downloads, if it does so.
> These changes are available here:http://www.box.net/shared/b8gg663s0g
available on BitBucket (I'll post it on SourceForce ASAP).
I've been a little busy in latest days, and I've found this thread
really interesting. In CPGs there are a lot of confusing settings and
binaries: maybe we can make a point on that, maybe listing all the
available (and download-able) CPG with their params to set in Hugin.
I'll then fix the installer according to your finding.. :)
Cheers
Matthew Petroff
> there is no need to ship match-n-shift.exe with a Hugin installer.
the autopano option that used generatekeys.exe since they do not seem
necessary. I also added an install option to clean the registry before
installing, to prevent future confusions like KFJ had.
The installer is available here:
http://www.box.net/shared/lukhztu4q5
The changes are available here:
http://www.box.net/shared/u20j3zsxea
Matthew
kfj
On Sep 25, 8:31 pm, Matthew Petroff <matt...@mpetroff.net> wrote:
> I made further changes to the installer, removing match-n-shift and
> the autopano option that used generatekeys.exe since they do not seem
> necessary. I also added an install option to clean the registry before
> installing, to prevent future confusions like KFJ had.
'Autopano-SIFT-C (multirow/stacked)' entry is actually the cleanest
solution, since the creation of panoramas from brackets with special
treatment for stacks is something quite advanced anyway. Best to leave
it out of the installer. I had looked into the matter today trying to
figure out ways to get around the need for Nowozin's autopano and
generatekeys to avoid the name conflict. Since Bruno proposed to omit
the match-n-shift, there was only the 'Autopano-SIFT-C (multirow/
stacked)' left. I played with it for a while and found out that the
two-stage process that involved generatekeys and autopano could be
simply exchanged by a one-step process, e.g. with panomatic, seemingly
without loss of functionality - but as I say, I think it's even better
without it altogether.
I haven't tried the registry-cleaning option yet, since I wanted to
have a path back in case things went amiss, but I'll try that out as
well and give you feedback, maybe tomorrow.
Thanks again for the nice installer!
with regards
KFJ
T. Modes
> 'Autopano-SIFT-C (multirow/stacked)' entry is actually the cleanest
> solution, since the creation of panoramas from brackets with special
> treatment for stacks is something quite advanced anyway. Best to leave
> it out of the installer.
"simple" panoramas. It is faster (in most cases) in comparision to
match all images at once, and more important it reduces drastically
the risk of getting wrong connections/control points. If there are no
stacks, this step is simply skipped.
So with multi-row the cp detection is more robust and therefore a
newbie will get better results with it than with an "all in one"
setting.
Thomas
kfj
On Sep 26, 9:18 am, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> That's simply wrong. The multirow/stack option has also advantages for
> "simple" panoramas. It is faster (in most cases) in comparision to
> match all images at once, and more important it reduces drastically
> the risk of getting wrong connections/control points. If there are no
> stacks, this step is simply skipped.
> So with multi-row the cp detection is more robust and therefore a
> newbie will get better results with it than with an "all in one"
> setting.
>
in the future. It's just a matter of creating a new CPG entry and
populating it with the desired calls. I agree that stacks are a good
thing, that's why I tried to find a way of keeping the entry by
replacing the two-step CPG process involving autopano/generatekeys by
something the user might have already (he may or may not have any of
the CPGs, since the user can choose which to install).
I still feel the initial install is better off lean, but I it's just
my personal preference.
with regards
KFJ
T. Modes
> in the future. It's just a matter of creating a new CPG entry and
> populating it with the desired calls. I agree that stacks are a good
> thing, that's why I tried to find a way of keeping the entry by
> replacing the two-step CPG process involving autopano/generatekeys by
> something the user might have already (he may or may not have any of
> the CPGs, since the user can choose which to install).
panomatic, select then one-step detector).
But using the two-step approach (involving autopano/generatekeys from
autopano-sift-c) has advantages. In this case each image is only
probed once to find keypoints. The keypoints are cached to disc. At
the end the temp files are deleted.
If you call inside a script, you break this functionality.
Thomas
kfj
On Sep 26, 6:04 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> You can use the multi-row detector also with other cp detectors (like
> panomatic, select then one-step detector).
> But using the two-step approach (involving autopano/generatekeys from
> autopano-sift-c) has advantages. In this case each image is only
> probed once to find keypoints. The keypoints are cached to disc. At
> the end the temp files are deleted.
panorama from 8 brackets of 3 images each, using align_image_stack as
the stack aligner and the generatekeys/autopano combination for the
interstack alignment. First CPs were generated for the 8 brackets and
put into my panorama. Then the second image of each stack was put to
the SIFT by generatekeys, resulting in 8 keyfiles. Next, there was a
pairwise comparison between sequentially adjacent keyfiles. What the
advantage of such a process over treating all second-in-stack images
with a one-pass CPG would be I cannot figure out, particularly since
finally there was another use of the previously generated keyfiles,
putting them all together into the autopano process. If they had been
looked at by a one-pass CPG, this step would have been unnecessary.
Over all, the SIFT algorithm was performed once per image, as would be
in a one-pass CPG, but rather than just lumping it all together into
one tree and doing a global match, there was some pairwise comparing
done.
What does one gain from the additional pairwise comparison? Or what am
I missing? If the SIFT keyfiles had been generated when the images in
the stacks were looked at by align_image_stack, there could have been
some gain, but I could not see anything along these lines happening.
Did I not look in the right place [my TEMP directory]? Or is there
something wrong with setting the whole panorama-of-stacks process like
I did?
Since I'm just in the process of asking questions concerning CPGs, let
me add these questions:
Is there a way to automatically sort the images into stacks by telling
hugin it's a series of brackets with N exposures each? I'm thinking
here along the lines of enfuse_align_droplet.bat
Is there a way to let hugin pick the first image of each bracket
rather than the second for the positioning run? My Canon does them
+/-0, -X, +X, and the default behaviour is rather inconvenient since
it will look at the underexposed images only which are really just
there to get the sky right.
Alternatively, is there a way to make hugin also find CPs for the
other two expoure levels [apart from manually]? This would make sense,
because different parts of the images become good sources for CPs with
different exposure levels.
with regards
KFJ
Bruno Postle
It is part of Panotools::Script:
http://search.cpan.org/dist/Panotools-Script
I used to upload occasional Windows .exe of the various scripts, but
not lately. The current match-n-shift makes heavy use of Makefiles,
which, although it has been coded to be cross-platform, has had no
testing on Windows as far as I know.
--
Bruno
Bruno Postle
>
>I'd like to understand this process properly. I ran a test with a
>panorama from 8 brackets of 3 images each, using align_image_stack as
>the stack aligner and the generatekeys/autopano combination for the
>interstack alignment. First CPs were generated for the 8 brackets and
>put into my panorama. Then the second image of each stack was put to
>the SIFT by generatekeys, resulting in 8 keyfiles. Next, there was a
>pairwise comparison between sequentially adjacent keyfiles. What the
>advantage of such a process over treating all second-in-stack images
>with a one-pass CPG would be I cannot figure out, particularly since
>finally there was another use of the previously generated keyfiles,
>putting them all together into the autopano process. If they had been
>looked at by a one-pass CPG, this step would have been unnecessary.
>Over all, the SIFT algorithm was performed once per image, as would be
>in a one-pass CPG, but rather than just lumping it all together into
>one tree and doing a global match, there was some pairwise comparing
>done.
>What does one gain from the additional pairwise comparison? Or what am
>I missing?
The matching of every photo with every other photo is 'expensive' in
computation, particularly with projects with hundreds of photos.
Worse than that, nearly all the comparisons between photos are
between pairs that don't actually overlap, even a small
false-positive rate results in enough 'bad' control points to
completely wreck a project.
The 'multirow' method only compares photos that are very likely to
overlap, so there are many fewer errors even with huge projects
(The generatekeys/autopano pair isn't ideal for this as they
exchange data via XML, which is slow, the new cpfind tool in the
Hugin default branch shouldn't have this problem).
align_image_stack is much better at matching photos with varying
exposure than autopano-sift-c. It is also fast since it assumes an
almost-aligned stack.
--
Bruno
Yuval Levy
> The multirow/stack option has also advantages for
> "simple" panoramas.
it is IMHO probably the best default choice. Advanced users can fiddle with
other things if they want.
Yuv
Yuval Levy
> The newly installed CPGs and the CPG settings (also for the missing
> ones) produce problems on my system. match-n-shift won't run - now
> this may be because I don't have ImageMagick installed
and because Windows does not have a proper package management system, so it is
not possible for the installer to know what you do or don't have. The
solution would be for the installer to also install ImageMagick if it is
possible to check whether it is already present before doing so.
> As far as autopano is concerned, there is a name conflict here with
> autopano by A. Jenny and autopano by S. Nowozin, which is a different
> thing altogether. A. Jenny's is used as standalone CPG, whereas
> Nowozin's is used with existing .key files (like in conjunction with
> generatekeys), if my understanding is correct.
the name autopano has been over-used. the above two tools are unmaintained and
for all practical purpose it is better to ignore them / remove them from the
installer all together.
> And the settings for autopano-sift-c include '--projection %f,%v',
> which does not work with the autopano-sift-c.exe I took from my
> previous installation [version 2.5.2] (since the installer didn't
> actually install it).
autopano-sift-c is the only one in the "autopano" series (i.e. SIFT-based CP
detectors) worth considering, but it too has problems. 2.5.2 is broken, use
2.5.1 instead.
> I think the CPG deployment needs some finetuning ;)
That's a nice understatement. In terms of software deployment in general
Windows is a pain because of the lack of package manager. You should really
give Kubuntu a try. There is, of course, a learning curve, but I think you'll
be delighted.
Yuv
kfj
On Sep 27, 6:06 am, Yuval Levy <goo...@levy.ch> wrote:
> Windows is a pain because of the lack of package manager. You should really
> give Kubuntu a try. There is, of course, a learning curve, but I think you'll
> be delighted.
Ubuntu studio 9.x. on a Thinkpad. But it's a handcrafted setup where
the Windows System partition is encrypted with Truecrypt and the whole
show is still booted with grub legacy using some dirty tricks copying
specific sectors to and fro. I just daren't update it because last
time I had a double boot system like that, upgrading linux just
totally f....d up my setup, resulting in me having to repartition,
restore... it took days of work. Ubuntu now uses grub 2, I haven't the
faintest clue if it will respect my setup, let alone understand that
it mustn't touch anything after, I think, the 8th sector of the disk,
let alone install grub 2 over it. I have toyed with installing Ubuntu
10.4 into my (encrypted) Windows partition and play with it a bit, but
I still haven't done it, because I'm still annoyed with Ubuntu for
wrecking another double-boot-system (also laptop, but no Truecrypt) I
tried to upgrade from 9.4 to 9.10 just a couple of weeks ago, and then
when I tried to istall 10.4 post-recovery, it went black-screen on me
no matter how hard I tried. It's not all so fantastic in the Linux
universe, and if you go off the beaten track with an Ubuntu system
(like, install bleeding edge software instead of the Canonical-
sanctioned versions that come with your distro) you may find yourself
in similar situations as a windows user who's got some old version of
something that doesn't cooperate with something else.
Ah, I'll stop whining and complaining, and, yes, I should do more on
Linux, it'd be so much more my style - but I'm only human and my
Windows system is running so smoothly I can't get myself to invest a
couple of weeks to recreate my software environment in Linux. And now
I even have hugin 2010.2.0, and it works well so far!
with regards
KFJ
kfj
On Sep 27, 1:11 am, Bruno Postle <br...@postle.net> wrote:
> On Sun 26-Sep-2010 at 10:20 -0700, kfj wrote:
>
> The matching of every photo with every other photo is 'expensive' in
> computation, particularly with projects with hundreds of photos.
> Worse than that, nearly all the comparisons between photos are
> between pairs that don't actually overlap, even a small
> false-positive rate results in enough 'bad' control points to
> completely wreck a project.
>
images. One is to actually match every image with every other,
pairwise. Naturally, the increase in computation time with the number
of images will be quadratic (or worse because less data is close by,
like cached). Panomatic uses this method, at least if run with the
default settings, and, indeed, from a few ten images up it becomes a
very lengthy process. But other programs like Jenny's autopano seem to
put all feature vectors into one big pool and work on them in one go
which still takes longer if there are more images, but since it's some
tree structure it is _much_ better than quadratic (logarithmic?). In
my experience, the false-positives aren't so much of a problem - and I
think the new method to remove false-positives by a statistical method
seems to get rid of any that are left quite effectively. It's an
interesting topic, though, and I sometimes feel that keeping the SIFT
or SURF keys one has spent time on computing for further reference if
the images ever have to be touched again would be a nice thing. I have
actually missed the ability to export the SIFT/SURF keys from most
CPGs, in whatever format they might allow for that.
> (The generatekeys/autopano pair isn't ideal for this as they
> exchange data via XML, which is slow
If these data are kept, more sophisticated matching schemes become
feasible - the question is just if the 'throw them all in and match
them together' approach isn't so effective that other approaches
simply don't promise much gain.
with regards
KFJ
Yuval Levy
> the increase in computation time with the number
> of images will be quadratic (or worse
computation time is not the real issue here (unless you waste your time
waiting in front of the computer while it does the job).
false positives between non-adjacent images are the real issue.
> my experience, the false-positives aren't so much of a problem
it's very much dependent on the type of scene and the lens focal distance.
You might just not be shooting the kind of panos that do exhibit this kind of
problem.
Yuv
Matthew Petroff
> And thank you for the Windows build (could you also provide a x64
> one?)
not have a 64bit Windows installation so the build is untested.
The build is available here:
http://www.box.net/shared/3ivhx5h75l
An installer is available here:
http://www.box.net/shared/b4jdoc8kki
In regards to control point generators, is it possible to use single
step generators (panomatic/autopano-SIFT-C) with modes other than "all
images at once?" I tried to do so but got strange results. Panomatic
added 0 control points for all of the other modes, while autopano-SIFT-
C added tight groupings of control points that did not match.
Matthew
thePanz
Multirow/stacked control point generation.
Further details (and downloads) are here:
http://thepanz.netsons.org/post/hugin-2010-2-0-rc1-installer
@Yuv: sorry for my delay! In reply to your eMail about
subrepositories, what I mean for Mercurial Sub-Repositories is here:
http://mercurial.selenic.com/wiki/Subrepositories, we could "split"
Hugin (core) development from various installers. The main feature
that I'd like to add is a CMake script to full automatic installer
generation, unfortunately I've never used CMake :(
Thank you for your time!
Cheers
Oskar Sander
I just sucessfully downloaded your 32b installer with all controll point generators and it seems to work perfectly so far! Tanks alot!
One problem i seem always have lately with the hugin kits, is the enblend.exe doesnt run on my XP. "The system cannot execute the specified command"
this happens for both the ordinary and the openmp versions.
Funny enough, I can run enblend_GPU, which I always substitute from an old version.
Please enlighten me, is there HW differences that these programs rely on (naively i would expect the GPU verion being most sensitive to HW differences)
Cheers
--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
--
/O
Yuval Levy
On September 28, 2010 06:50:42 am Oskar Sander wrote:
> One problem i seem always have lately with the hugin kits, is the
> enblend.exe doesnt run on my XP. "The system cannot execute the specified
> command"
> this happens for both the ordinary and the openmp versions.
what processor do you have in your system?
> Funny enough, I can run enblend_GPU, which I always substitute from an old
> version.
in the GPU version, it is the video card that runs the show. So: what video
card do you have?
> Please enlighten me, is there HW differences that these programs rely on
> (naively i would expect the GPU verion being most sensitive to HW
> differences)
they are both sensitive to different parts of the hardware. I have added an
FAQ [0], [1] but even my little Atom supports SSE2 so I am "blind". Can you
please check it is correct and update if necessary?
Yuv
[0]
http://wiki.panotools.org/Hugin_FAQ#Enblend:_The_system_cannot_execute_the_specified_command
[1] http://wiki.panotools.org/Hugin_FAQ#Enblend-
Enfuse_OpenMP_SSE_GPU:_which_one_is_the_right_one_for_me.3F
Oskar Sander
My computer is running XP Professional SP2, Intel Core2 Duo P8600, 2.4GHz
Before adding that to the list of non-supported CPUs, shoudnt that generation have the SSE2?
Cheers
--
/O
T. Modes
>
> My computer is running XP Professional SP2, Intel Core2 Duo P8600, 2.4GHz
>
> Before adding that to the list of non-supported CPUs, shoudnt that
> generation have the SSE2?
>
Package (x86)?
This is necessary to run the openmp version (as stated in the README)
Thomas
Yuval Levy
it's definitely not lack of SSE2 support with an Intel Core2 Duo. Obviously I
have been away from Windows for too long and did not know about the MSVC
redistributable.
I have updated the first FAQ [0].
I have an issue with your "fixes" to the second FAQ [1], Thomas.
First of all, you have made it completely Windows-centric. The choices exist
also for other platform. For example the most current build for Debian /
Ubuntu has enblend-mp and enfuse-mp (for the OpenMP support).
Second, you made the assumption that everybody build always with GPU. Maybe
that's how you built your binaries, which I understand are on the SF download
page. But --enable-gpu-support=CHECK/yes/no ist still a build-time option and
so the category with/without GPU support is a relevant one.
Please fix
T. Modes
>
> I have an issue with your "fixes" to the second FAQ [1], Thomas.
>
> First of all, you have made it completely Windows-centric. The choices exist
> also for other platform. For example the most current build for Debian /
> Ubuntu has enblend-mp and enfuse-mp (for the OpenMP support).
and which advantage/disadvantage each have. But it does not say how to
identify a specific version or that the OpenMP version is called
enblend_mp. Or if enblend or enblend_mp is build with GPU support. But
this are the informations a newbie would expect/need to come to a
decision, which version is the right for him.
>
> Second, you made the assumption that everybody build always with GPU. Maybe
> that's how you built your binaries, which I understand are on the SF download
> page. But --enable-gpu-support=CHECK/yes/no ist still a build-time option and
> so the category with/without GPU support is a relevant one.
>
support, the gpu is not used by default for blending images. So in the
default calling (enblend -o output input1 input2 ...) an enblend
without and with gpu support behave the same. You need to specify the -
g switch to use the gpu.
Thomas
Yuval Levy
On September 29, 2010 11:53:48 am T. Modes wrote:
> Hi Yuv,
>
> > I have an issue with your "fixes" to the second FAQ [1], Thomas.
>
> I reverted the changes.
I have a different definition for "revert". I would say you "fixed", and now
we have two separate versions. you just renamed yours into another question.
But we have an inconsistency. How many categories of enblend-enfuse are
there?
> > First of all, you have made it completely Windows-centric. The choices
> > exist also for other platform. For example the most current build for
> > Debian / Ubuntu has enblend-mp and enfuse-mp (for the OpenMP support).
>
> But this was not in the FAQ. It stated only that there are 4 variants
> and which advantage/disadvantage each have.
Indeed, that FAQ was a generic, simplified description of the relevant build
options. It makes sense to put additional, platform-specific information in
separate, related questions, as you did. good start.
But I must criticize your version. It assumes that nobody built a version
without GPU support. You can control your builds; and you can control what
goes on the official website. But people download enblend-enfuse builds from
all sorts of places and so you can't assume that all builder exercise the care
that you do in selecting what they build and distribute.
> But it does not say how to
> identify a specific version or that the OpenMP version is called
> enblend_mp. Or if enblend or enblend_mp is build with GPU support.
because I don't know. If somebody know, they can add the information.
Andreas?
we have to be careful with assumptions. The advantage of Debian/Ubuntu is
that there is an official repository, so if somebody types `sudo apt-get
install enblend` I can reasonably assume that he received the packages built
by Andreas. But even on Ubuntu, somebody can download a .deb file from a
third party site and then I can no longer assume names nor features. The
default enblend-enfuse build will call those binaries enblend and enfuse, no
matter what features are selected at build time.
the right way to address this tricky situation in your FAQ is to state that
"if you downloaded a binary *from the official site*" then there are only
those three builds/categories.
> But
> this are the informations a newbie would expect/need to come to a
> decision, which version is the right for him.
Disagree. If the FAQ was for a newbie, I would write it this way:
Q: wich version of enfuse-enblend is the right one for a Windows newbie?
A: download an official version from the enblend website (put a link). there
are three versions available:
1. if you have a modern multi-core CPU, _openMP is for you
2. if you have an old CPU that does not support SSE2, _NOSSE is for you
3. if blending fails and you are using large images, try the standard/default
version.
If you downloaded your enblend version from another source, you can find out
which features it supports with `enblend -v -V`.
(1) "Extra feature: OpenMP: yes" then it is the OpenMP version
(2), **I don't even know how to identify a NOSSE version
(3) "Extra feature: image cache: yes" then it may be the normal version,
however the normal version could also be compiled without image cache
(4) another interesting piece of information to look for is "Extra feature:
GPU acceleration: yes" - official builds all have this feature enabled, but it
is possible that the version you downloaded is not GPU enabled. To use the
GPU when stitching, pass the option --gpu
see, there are four big categories with variations, not just three, even if it
makes sense to offer only three for download.
> > Second, you made the assumption that everybody build always with GPU.
> > Maybe that's how you built your binaries, which I understand are on the
> > SF download page. But --enable-gpu-support=CHECK/yes/no ist still a
> > build-time option and so the category with/without GPU support is a
> > relevant one.
>
> You are only partially correct. Even if enblend is build with gpu
> support, the gpu is not used by default for blending images. So in the
> default calling (enblend -o output input1 input2 ...) an enblend
> without and with gpu support behave the same. You need to specify the -
> g switch to use the gpu.
no, you are off-topic. the topic was "which versions of enblend are there",
not "how do I use them". that said, it makes sense to make the user aware
that they need to pass the --gpu switch (-g is a gimp related option), so I
updated the FAQ.
now please solve the inconsistency/confusion and don't mention that there are
three categories of enblend, but that the official site offers three specific
versions for download.
Yuv
Yuval Levy
On September 28, 2010 05:12:29 am thePanz wrote:
> what I mean for Mercurial Sub-Repositories is here:
> http://mercurial.selenic.com/wiki/Subrepositories, we could "split"
> Hugin (core) development from various installers.
Interesting. But there are a lot of caveats. We'll need some testing to see
if/how this will work on SourceForge.
> The main feature
> that I'd like to add is a CMake script to full automatic installer
> generation, unfortunately I've never used CMake :(
look at this as an opportunity to start learning CMake :-)
Yuv
Oskar Sander
I must admitt i am not the best in class reading READMEs.Installing that runtime library fixed my enblend problem.
However, I had the same problem with both enblend_openmp.exe and enblend.exe
So it seems like there is a dependency (wrong?) also with the ordinary enblend version?
Anyway, the open mp wersion use the dual cores better i suppose, right? Looking at the trends for the future, it seems like the Moores law for cpu power will continue to apply, however now by adding multiples of cores instead of just add sheer speed to each core. So, processes that can split the task may be the ones that prevail. GPUs will probably also continue to increase capacity, but to me it does not seem to be as a generic solution, right?
Cheers
/O
--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
--
/O
thePanz
Ciao Yuval (I noticed now that this isn't the first time you write me
in Italian ;) )
> > what I mean for Mercurial Sub-Repositories is here:
> >http://mercurial.selenic.com/wiki/Subrepositories, we could "split"
> > Hugin (core) development from various installers.
>
> Interesting. But there are a lot of caveats. We'll need some testing to see
> if/how this will work on SourceForge
HuginSetup where I can commit my changes.. then we'll keep in sync or
try to use those new Mercurial Features... what do you think?
> look at this as an opportunity to start learning CMake :-)
making, and so on..) from too much time now.. and from my latest
researches I found that CMake requires some Visual Studio install :(
Maybe when I'll have some free time left from my PhD courses I'll try
to dig into CMake scripting! :)
Cheers
Yuval Levy
On September 30, 2010 04:03:35 am Oskar Sander wrote:
> I must admitt i am not the best in class reading READMEs.Installing that
> runtime library fixed my enblend problem.
what is Microsoft's license about distributing the runtime? If I was
building/distributing an installer with an enblend binary, I would either
bunde the runtime inside the installer or detect its presence and download it
at install time.
> Anyway, the open mp wersion use the dual cores better i suppose, right?
> Looking at the trends for the future, it seems like the Moores law for cpu
> power will continue to apply, however now by adding multiples of cores
> instead of just add sheer speed to each core. So, processes that can split
> the task may be the ones that prevail. GPUs will probably also continue to
> increase capacity, but to me it does not seem to be as a generic solution,
> right?
the GPU vs. CPU choice is more complex than that. If speed is your concern,
update to the latest video card graphics and run a quick timed test with and
without `--gpu`
Yuv
Yuval Levy
On September 30, 2010 09:22:51 am thePanz wrote:
> Ciao Yuval (I noticed now that this isn't the first time you write me
> in Italian ;) )
the image at [0] is about one hour north-west of you (Milano, right?) ;)
> You're right.. maybe you can create a new repository only for
> HuginSetup where I can commit my changes.. then we'll keep in sync or
> try to use those new Mercurial Features... what do you think?
done [1]. it's empty now, you can fill it. integration / sync keeping is not
critical (like now between bitbucket and SF) can be thought of later.
Yuv
[0] http://panospace.wordpress.com/2009/06/29/one-month-with-ubuntu/
[1] http://hugin.hg.sourceforge.net/hgweb/hugin/windowsSetup/
thePanz
On Sep 30, 6:46 pm, Yuval Levy <goo...@levy.ch> wrote:
> ciao Emanuele,
>
> On September 30, 2010 09:22:51 am thePanz wrote:
>
> > Ciao Yuval (I noticed now that this isn't the first time you write me
> > in Italian ;) )
>
> the image at [0] is about one hour north-west of you (Milano, right?) ;)
hour far from me) :)
By the way.. did you enjoy Switzerland? ;) Did you also travel to
Italy?
> done [1]. it's empty now, you can fill it. integration / sync keeping is not
> critical (like now between bitbucket and SF) can be thought of later.
clicks) :)
I'm trying to commit to that repo, but I got this response pushing
changes to it:
###
pushing to ssh://ep...@hugin.hg.sourceforge.net/hgroot/hugin/windowsSetup
searching for changes
remote: abort: could not lock repository hgroot/hugin/windowsSetup:
Permission denied
('unexpected response:', '')
###
Maybe I'm not allowed to push to that repository?
Let me know! :)
Cheers! ... Buona Giornata! :)
Yuval Levy
> By the way.. did you enjoy Switzerland? ;) Did you also travel to
> Italy?
I used to live there, and travel very often to Italy.
> I'm trying to commit to that repo, but I got this response pushing
> changes to it:
sorry, forgot to deal with Sourceforge's quirks, had to chmod g+w the new
repository. fixed.
> Maybe I'm not allowed to push to that repository?
SF does not have fine grained control. Every project member can write to
every repository, unless, like in this case, it is not group writable. Then
only the user who owns the repo (usually the one who created it) can write.
<sarcasm>
I love SourceForge
</sarcasm>
buona domenica
Yuv
JeCh
be fixed IMHO before releasing the final version. I believe those only
concern the Windows version.
1) Autopano-SIFT-C (not the multirow/stacked version) doesn't work. It
creates only a few control points and those are completely wrong. Can
someone else confirm this? If it works for you, what is your command
line in settings?
2) Many problems with HDR (not panoramic) images.
a) The images get incorrectly aligned (although the control points
are OK).
b) Strong distortion of images when using the "straighten" function
in preview.
c) The problem mentioned here:
http://groups.google.com/group/hugin-ptx/browse_thread/thread/43c002b01166c7b5/8341f47694c4e61f
3) Hugin can't process images stored in path with non ASCII
characters. Usually the problem appears when running Nona. First I
thought it can be fixed by using a different encoding of .tmp files.
But that didn't help. So I tried to convert the path to the short
(DOS) names and that fixed the problem. The same problem appears if I
try to use Autopano-SIFT-C multirow. I believe that these problems
would be fixed by using short path names (http://msdn.microsoft.com/en-
us/library/aa364989%28VS.85%29.aspx). They are already used in .bat
files for user profile directory.
I hope the problems 1 and 3 could be fixed quite easily (and should be
fixed before releasing the final version IMHO). The problems in 2) are
quite difficult to describe and reproduce. But I would assist as much
as I can if somebody wants to look into it.
Many thanks for all of your ward work.
Bruno Postle
>Since we are already in RC state, there are some things which should
>be fixed IMHO before releasing the final version. I believe those only
>concern the Windows version.
>
>1) Autopano-SIFT-C (not the multirow/stacked version) doesn't work. It
>creates only a few control points and those are completely wrong. Can
>someone else confirm this?
autopano-sift-c isn't part of Hugin. It sounds like you have a
snapshot of autopano-sift-c, the only version we can recommend is
the 2.5.1 release.
>2) Many problems with HDR (not panoramic) images.
> a) The images get incorrectly aligned (although the control points
>are OK).
I'm not sure, can you provide an example project?
> b) Strong distortion of images when using the "straighten" function
>in preview.
Yes the straighten function has always failed with non-panoramic
scenes (i.e. it doesn't work unless there is a spread of yaw
values). This has been the same for the last few releases, it isn't
going to change soon unless somebody gets annoyed enough to fix it.
> c) The problem mentioned here:
>http://groups.google.com/group/hugin-ptx/browse_thread/thread/43c002b01166c7b5/8341f47694c4e61f
I tried your test photos, but they are 5EV apart. There is
basically no exposure overlap between the photos, I don't see how
you could construct usable HDR data from this (exposure fusion is ok
though).
>3) Hugin can't process images stored in path with non ASCII
>characters. Usually the problem appears when running Nona. First I
>thought it can be fixed by using a different encoding of .tmp files.
>But that didn't help. So I tried to convert the path to the short
>(DOS) names and that fixed the problem. The same problem appears if I
>try to use Autopano-SIFT-C multirow.
I'm guessing you are using Windows with a Russian codepage? Hugin
works fine with non-ascii characters on OS X, Windows and Linux, but
apparently not on Windows with Russian/Czech character sets. This
has been a known problem for a long time, but is impossible to fix
without a developer who has this particular combination.
The entire system for running external programs has been rewritten
in the current trunk/default branch. So hopefully this problem is
already fixed there, but it won't be possible to backport these
major changes to the 2010.2 branch (we would very much like you to
test this new code if you can).
So aside from the HDR issues, these are all problems that have
existed in past releases.
--
Bruno
JeCh
>
> autopano-sift-c isn't part of Hugin. It sounds like you have a
> snapshot of autopano-sift-c, the only version we can recommend is
> the 2.5.1 release.
>
OK, so maybe the installer should link to this older version, because
the linked 2.5.2 doesn't work. thePanz, could you fix this, please?
> > a) The images get incorrectly aligned (although the control points
> >are OK).
>
> I'm not sure, can you provide an example project?
>
As I said, it's hard to reproduce, but I'll try to get some useful
information if it happens to me again.
> Yes the straighten function has always failed with non-panoramic
> scenes (i.e. it doesn't work unless there is a spread of yaw
> values). This has been the same for the last few releases, it isn't
> going to change soon unless somebody gets annoyed enough to fix it.
OK, so could it be at least disabled in these situations when using
the assistant mode?
> > c) The problem mentioned here:
> >http://groups.google.com/group/hugin-ptx/browse_thread/thread/43c002b...
>
> I tried your test photos, but they are 5EV apart. There is
> basically no exposure overlap between the photos, I don't see how
> you could construct usable HDR data from this (exposure fusion is ok
> though).
So I should have taken one more photo with no exposure correction,
right? I took a +2 EV and -3 EV photos. I'm quite new to HDR, so the
problem might be very likely at my side. But I got some quite good
results from Luminance HDR. It's pretty far from perfect, but it shows
it should be possible to make a HDR out of the images:
http://img338.imageshack.us/f/pokusg.jpg/ (tonemapped version).
> I'm guessing you are using Windows with a Russian codepage? Hugin
> works fine with non-ascii characters on OS X, Windows and Linux, but
> apparently not on Windows with Russian/Czech character sets. This
> has been a known problem for a long time, but is impossible to fix
> without a developer who has this particular combination.
>
> The entire system for running external programs has been rewritten
> in the current trunk/default branch. So hopefully this problem is
> already fixed there, but it won't be possible to backport these
> major changes to the 2010.2 branch (we would very much like you to
> test this new code if you can).
Czech Republic is in Central Europe, so we don't use Russian character
set. We use CP-1250 or ISO-8859-2, these are standard letters with
some added like ěščřžýáíé. The same letters are used in Poland,
Sovakia, Slovenia, Croatia and other countries. My idea for a quick
fix is to use short path (like C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/)
for image files. This should fix the problem at least for CE
languages.
If you have some other solution in the current trunk, I will be happy
to test it if somebody can provide me a compiled binary. I did some
PHP, PyQt and PyGTK coding, but I never programmed anything in C/C++.
I have absolutely no experience with compiling SW on Windows.
Thanks a lot for your replies.
Henk Tijdink
projection %f%v in the parameter line in the preference tab.
Then even Autopano SIFT-C 2.5.2 of T.K. Sharples generates enough
control points.
I've no problems with this version of Autopano SIFT-C.
This solution is already mentioned in another thread of release
candidate 2.
There is a link to an installer of RC2 too in this thread, which has
the right parameters after installation.
Kind regards,
Henk Tijdink
http://groups.google.com/group/hugin-ptx/browse_thread/thread/4b98583adb282798#
On 4 okt, 11:39, JeCh <vladimir.ji...@gmail.com> wrote:
> Since we are already in RC state, there are some things which should
> be fixed IMHO before releasing the final version. I believe those only
> concern the Windows version.
>
> 1) Autopano-SIFT-C (not the multirow/stacked version) doesn't work. It
> creates only a few control points and those are completely wrong. Can
> someone else confirm this? If it works for you, what is your command
> line in settings?
>
> 2) Many problems with HDR (not panoramic) images.
> a) The images get incorrectly aligned (although the control points
> are OK).
> b) Strong distortion of images when using the "straighten" function
> in preview.
thePanz
On Oct 5, 2:17 am, JeCh <vladimir.ji...@gmail.com> wrote:
> On 5 říj, 00:36, Bruno Postle <br...@postle.net> wrote:
>
> > autopano-sift-c isn't part of Hugin. It sounds like you have a
> > snapshot of autopano-sift-c, the only version we can recommend is
> > the 2.5.1 release.
>
> OK, so maybe the installer should link to this older version, because
> the linked 2.5.2 doesn't work. thePanz, could you fix this, please?
it! :) If you have any link I'm open to fix the installer using the
2.5.1 panomatic build
Regarding the arguments bug: I've already fix them in latest installer
release, I don't know if Mathew provided a new build with my latest
installer script.
Regards
davidefa
following address: http://www.sendspace.com/file/0mgb8o ( from this
post: http://old.nabble.com/Hugin-2009.4.0-Win-XP-autopano-sift-c-2.5.2-bug-td27435344.html
)
- a windows build of autopano-sift-c 2.5.2 16.February.2010 ( not
23July2009 ) can be found in lemur's build svn.5046 at the following
address: http://lemur.dreamhosters.com/hugin/hugin.win32.5046.rar
Regards
Davide Fabbri
Henk Tijdink
fixed the argument bug.
However in Hugin the default settings in the preference screen resets
these values when you resets the preferences to the default values.
See post http://groups.google.com/group/hugin-ptx/browse_thread/thread/4b98583adb282798#.
There is a version 2.5.1 of autopano SIFT-C here too:
http://hugin.panotools.org/testing/hugin/
However this version of cygming has some additional files in the
zipfile , that are needed.
More installers of Hugin there on that webpage.
In the installer Hugin 2009.02 RC1dd.26-10-09 is autopano-SIFT-C
2.5.1.
Can't find if it is RC1, RC2 or final version.
Kind regards,
Henk
Bruno Postle
>The solution for autopano SIFT-C is removing the parameters --
>projection %f%v in the parameter line in the preference tab.
Please don't change the default parameters in any installer, this is
how Hugin gets a bad name: "it doesn't work".
There are two valid ways of sending parameters to autopano-sift-c:
--maxmatches %p --projection %f,%v %o %i
--maxmatches %p %o %s
The first method is broken with some/most 2.5.2 snapshots, but is
ok with the actual released versions (2.5.0 & 2.5.1) - This is why
it is the default setting in Hugin.
The second method is broken with any release or snapshot before
2.5.1, but should get the best results because it can cope with
matching photos from different lenses.
Both methods work with autopano-sift-c 2.5.1.
So really the _only_ version of autopano-sift-c that should be
distributed is the 2.5.1 release. I understand that very recent
snapshots are ok, but I haven't done any testing myself.
--
Bruno
Bart van Andel
> - a windows build of autopano-sift-c 2.5.1 can be found at the
> following address:http://www.sendspace.com/file/0mgb8o( from this
> )
Indeed. That's where I uploaded it once I had found it in one of the
older Hugin installers a while ago. I'm quite surprised that it's
actually still available, but maybe I had chosed this site for that
reason, can't remember. Probably not the easiest location for your
installer since to my knowledge you can't use a direct file url, so
you'll need to copy it somewhere else. This was an easy location,
since I lack private web space.
--
Bart
Bruno Postle
>
>> Yes the straighten function has always failed with non-panoramic
>> scenes (i.e. it doesn't work unless there is a spread of yaw
>> values). This has been the same for the last few releases, it
>> isn't going to change soon unless somebody gets annoyed enough to
>> fix it.
>
>OK, so could it be at least disabled in these situations when using
>the assistant mode?
It needs fixing, but if there isn't a fix available and the bug
isn't any worse than with previous releases it isn't going to delay
2010.2.0.
>So I should have taken one more photo with no exposure correction,
>right? I took a +2 EV and -3 EV photos. I'm quite new to HDR, so
>the problem might be very likely at my side.
I'm the wrong person to be giving HDR advice, but my recent
experience was ok with -2, 0, +2 sets (though I still prefer
exposure fusion to tonemapped HDR).
>> I'm guessing you are using Windows with a Russian codepage?
>> Hugin works fine with non-ascii characters on OS X, Windows and
>> Linux, but apparently not on Windows with Russian/Czech character
>> sets.
>Czech Republic is in Central Europe, so we don't use Russian
>character set. We use CP-1250 or ISO-8859-2, these are standard
>letters with some added like ěščřžýáíé. The same letters are used
>in Poland, Sovakia, Slovenia, Croatia and other countries.
We don't actually know why there is a problem, Japanese is ok, but
Czech isn't. It is some weird Windows thing.
>My idea for a quick fix is to use short path (like
>C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/) for image files. This should
>fix the problem at least for CE languages.
Quick fixes can turn up all sorts of problems. Once we have
2010.2.0 out of the way I expect there will be snapshots of the
trunk where this bug can be resolved one way or another.
--
Bruno
Matthew Petroff
> Regarding the arguments bug: I've already fix them in latest installer
> release, I don't know if Mathew provided a new build with my latest
> installer script.
I reverted the patch I had made previously since it apparently broke
functionality to fix a minor issue, broken default paths. After
2010.2.0 is released, I might try to fix it, but I don't think the
risk of breaking things is worth it this late in the release cycle. It
will also be less of an issue anyway, with cpfind on the way.
I did add lines to the installer that set .pto to associate with Hugin
and I made a better icon for .pto files. Currently the icon is in a
separate archive in the installer, extracting into share.
The changes are available here: http://www.mpetroff.net/hugin/installerchanges_2010-10-05.7z
In case it could be useful for other platforms and someone wants to
commit it, the icon itself is available here:
http://www.mpetroff.net/hugin/hugin-pto-icon.tar.gz
Matthew
Henk Tijdink
download site of his Hugin builds and the Panz adapt the installer
script for downloading then the right Autopano SIFT-C.
Kind regards,
Henk .
Yuval Levy
> Perhaps can Mathew Petrov copie the Autopano SIFT-C 2.5.1 to the
> download site of his Hugin builds and the Panz adapt the installer
> script for downloading then the right Autopano SIFT-C.
just pay attention where you copy Autopano-SIFT-C to - it is tainted by the
SIFT patent.
Yuv
Yuval Levy
> I made a better icon for .pto files. Currently the icon is in a
> separate archive in the installer, extracting into share.
> The changes are available here:
> http://www.mpetroff.net/hugin/installerchanges_2010-10-05.7z In case it
> could be useful for other platforms and someone wants to commit it, the
> icon itself is available here:
> http://www.mpetroff.net/hugin/hugin-pto-icon.tar.gz
thanks. do you care for repository write access?
regarding icons and so, there is a proposal [1] from Cristian for a visual
evolution of the current Hugin logo. It has been around for more than a year
now, and no objections. I think it should be finalized and go into 2010.4 (or
2011.0, whatever comes first).
Yuv
[1] http://groups.google.com/group/hugin-
ptx/browse_thread/thread/9d6a54f871b0ae2/6595323524ac209c
Matthew Petroff
> thanks. do you care for repository write access?
svg. I can also then add a Windows build to SourceForge once 2010.2.0
final is released. There are also a few fixes for the Windows 64-bit
build that I have been working on.
As for autopano-sift-c, I have no intention on building or
distributing a build for it as SIFT is patented in my jurisdiction.
Matthew
On Oct 6, 10:42 pm, Yuval Levy <goo...@levy.ch> wrote:
> On October 5, 2010 08:46:25 pm Matthew Petroff wrote:
>
> > I made a better icon for .pto files. Currently the icon is in a
> > separate archive in the installer, extracting into share.
> > The changes are available here:
> > icon itself is available here:
> >http://www.mpetroff.net/hugin/hugin-pto-icon.tar.gz
>
> thanks. do you care for repository write access?
>
> regarding icons and so, there is a proposal [1] from Cristian for a visual
> evolution of the current Hugin logo. It has been around for more than a year
> now, and no objections. I think it should be finalized and go into 2010.4 (or
> 2011.0, whatever comes first).
>
> Yuv
>
> [1]http://groups.google.com/group/hugin-
> ptx/browse_thread/thread/9d6a54f871b0ae2/6595323524ac209c
>
> < 1KViewDownload
JeCh
http://groups.google.com/group/hugin-ptx/browse_thread/thread/7740afd5982d1a6
Unfortunately the problem with non-ASCII characters is still there.
Are the changes in the system for running external programs, you were
talking about, already implemented in this version? Thank you.
JeCh
Yuval Levy
> I tried Hugin 2010.3 Windows build from this thread:
> http://groups.google.com/group/hugin-ptx/browse_thread/thread/7740afd5982d1
> a6
>
> Unfortunately the problem with non-ASCII characters is still there.
> Are the changes in the system for running external programs, you were
> talking about, already implemented in this version? Thank you.
Most likely yes. The new makefile lib has been integrated into 2010.3.
Sorry to read that the problem with non-ASCII characters is still there.
The bug is reported [0], however I vaguely recall somebody saying that a
solution would be to use the windows short path names and I don't find it
mentioned in the bug report. It was too late in the 2010.2 release cycle to
try, but maybe it is something you want to try for 2010.3 before we branch out
2010.4 for release?
Yuv
[0]
<http://sourceforge.net/tracker/?func=detail&aid=3086440&group_id=77506&atid=550441>