[OSX] hugin0.7.0_RC2 for download

[Harry van der Wolf]

Hi Mac users,
I published another hugin build. It's the 0.7.0 RC2 build. It's an i386 and ppc build.

To start with: Again this is a build using my own scripts as I can't get the XCode project to work anymore on Tiger.

Changelog:

• Released a new bundle via my own scripts. I think (and hope) that I have the build process under control now (I'll keep my fingers crossed). It works for me on Tiger and Leopard. Please test.
• previous glitch where enfuse/enblend were only found in second instance has now been solved.
• exiv2 is now compiled into the bundle.
  
• Note: My bundle builds it's own Preferences file and does not use the Preferences from the (previous) XCode builds. This means that you have to check your preferences before building. The autopano and enblend/enfuse settings might be incorrect. Make sure enblend/enfuse settings are NOT on custom.

Information and binaries via my website
<http://panorama.dyndns.org/index.php?lang=en&subject=Hugin&texttag=Hugin>.
(The binaries itself are, as always, served from hugin.panotools.org who kindly provide the disk space and bandwidth).


Hoi,
Harry

[grow]

Harry,

Thanks for all your efforts on this new build.

I thought I was here to report a problem ... but as I typed this
message I realised that it was more like the return of a minor problem
that had gone away.

I installed it and opened an old project .pto file and checked that
the preferences were coming up the same as they did when that project
was open in a previous version.

Then I tried to get it to create some control points. I got an error
that read something like this:
command:
/Applications/Hugin.app/Contents/Resources/autopano-sift-c /private/
var/tmp/folders_501/Temporaryitems/ap_res7fkz07
"/Volumes/HD/VRs/IMG-1.tiff" "/Volumes/HD/VRs/IMG-2.tiff" "/
Volumes/HD/VRs/IMG-3.tiff"
failed with error code 255

As I typed this I realised that the filenames were IMG_X.tiff (rather
than IMG_X.tif) I hadn't even noticed that the problem with naming of
TIFF files had been fixed and had just forgotten to rename the source
files in that project. It had worked fine under Hugin_0.7_3176

So I opened another project file for a pano in which the source files
HAD been renamed and it has passed the point where it invokes autopano-
sift-c.

I also checked inside the Hugin application's Resources folder and
autopano-sift-c is included.

So I suppose my question is -
"Have we somehow moved back a version of autopano-sift-c with this
new build or has the new build undone the change that allowed version
3176 to cope with files of type .tiff? "

I am happy to continue renaming files of type .tiff to .tif so
please don't take this as a complaint!
I only mention it in case it is a symptom of some other problem.

all the best

George

On Aug 17, 10:47 am, "Harry van der Wolf" <hvdw...@gmail.com> wrote:
> Hi Mac users,
> I published another hugin build. It's the 0.7.0 RC2 build. It's an i386 and
> ppc build.
>
> To start with: Again this is a build using my own scripts as I can't get the
> XCode project to work anymore on Tiger.
>
> Changelog:
>

>    - Released a new bundle via my own scripts. I think (and hope) that I

>    have the build process under control now (I'll keep my fingers crossed). It
>    works for me on Tiger and Leopard. Please test.

>    - previous glitch where enfuse/enblend were only found in second instance
>    has now been solved.
>    - exiv2 is now compiled into the bundle.
>    - Note: My bundle builds it's own Preferences file and does not use the

[Harry van der Wolf]

Hi George,

First of all: Thanks for your feedback.

Now to your problems with tif(f). The 3176 build from Ippei comes without autopano-sift-c and also without other control point generators. My bundles come with extra binaries packaged in like autopano-sift-c, panomatic and matchpoint. You even mailed about the missing autopano-sift-c in 3176 and I replied (only a snippet):
"Still on holiday, but today with access to internet.

to George:
Ippei built the 3176 without autopano-sift-c, panomatic and matchpoint (which I always do). If you know how to "open" a package in Finder, you can copy autopano-sift-c from my 3133 version to Ippei's version. It is in Hugin.app/Contents/Resources. "

On my reply, your replied somewhat later (again only a snippet):
"Thanks Harry - yes that worked - but I'd guess that you knew it would!"

So, you used the autopano-sift-c from my build 3133 in Ippei's build 3176 and now this RC2 build has exactly the same autopano-sift-c: that's weird if it behaves differently. Are you sure it's autopano-sift-c?
Next to that: My autopano-sift-c (31 May) is the latest with regard to code changes. The only change has been on July 23rd (after Ippei's build during my holiday) only changing the version stamp from 2.4 to 2.5.

In the mean time try panomatic (with -o %o %i) instead of autopano-sift-c: It's much faster.
Enblend had the same issue with tif(f) and has been changed on 18-07-2008. Again, after Ippei's 3176 build.

I'll have a look at all my "helper" binaries and libraries to see what needs to be updated next to enblend and enfuse.

Harry

2008/8/17 grow <Geor...@gmail.com>

[li...@kxe.be]

Thanks for your work Harry.
Works great.

Does anybody else think that panomatic is not only faster, but also
produces better results? Control points have a much better
distribution in my opinion.

thanks again.

Maurice

On Sun, Aug 17, 2008 at 9:53 AM, Harry van der Wolf <hvd...@gmail.com> wrote:
...

> In the mean time try panomatic (with -o %o %i) instead of autopano-sift-c:
> It's much faster.

...

[Michael Galloway]

On Sun, Aug 17, 2008 at 12:00:40PM -0500, li...@kxe.be wrote:
>
> Thanks for your work Harry.
> Works great.
>
> Does anybody else think that panomatic is not only faster, but also
> produces better results? Control points have a much better
> distribution in my opinion.
>
> thanks again.
>
> Maurice
>
>

i find that panomatic works well for me and my pano's. both 'normal' and bracketed
hdr sets.

-- mcihael

>

[Harry van der Wolf]

Well, to add my 2 cents.

 

I use panomatic as my primary control point generator. My personal findings are:

- that it doesn't map as much sky and clouds as autopano-sift-c does. With autopano-sift-c I get a lot of points in clouds. If it's not windy it can be OK, if it is windy it's a big disturbance.

- panomatic doesn't find as much double (and sometimes triple) CP's. Autopano-sift-c has improved on that point somewhere in February (as I recall correctly) but it still finds more doubles that panomatic.

- panomatic does, in general, a better distribution of points than autopano-sift-c.

- panomatic is much faster. It is multi-threading using available cores in your (intel dual- or quad-core) Mac. On the other hand: with autopano-sift-c or matchpoint "working" I can still do something else whereas panomatic takes all processor power.

 

I also use matchpoint occasionally (matchpoint-complete-mac.sh in my bundles; see the DOCS in my bundle for basic explanation). I find it does a decent job too but it is much slower than panomatic. As I'm very impatient I tend to almost always use panomatic. I sometimes switch when I find that panomatic for whatever reason didn't do a good job.

 

My experiences are not at all scientifically funded. I still lack a lot of basic knowledge about "all" the mathematics behind this. I still could not find the courage to start reading about it (my years of study are long gone and I prefer to keep it that way).

I did read a post from Pablo to this mailing list, a few months ago,  discussing an article where those three CP generators were compared, that autopano-sift-c does a better job with fish-eye lenses. I only work with "normal" lenses so I can't say anything about that. Anyone else can? 
 

Harry

 

 

2008/8/18, Michael Galloway <m...@ornl.gov>:

[akse...@gmail.com]

Hello,

The autopano-sift-c error code 255 problem with RC2, and also going back to at least 3133, is that the autopano-sift-c is not Universal compiled. It runs fine on an Intel Mac but not on a PCC Mac. On a PCC you'll see a "bad processor code" error when you try to run the autopano-sift-c by itself from a command prompt.

On a different matter, I have noticed several problems in the control points interface. 3281 was basically unusable. In RC2, where I only was making a quick check to find gross problems, I am not able to move a control point.

Allan Seidel

[Steve Rigby]

On Aug 18, 2008, at 8:42 AM, akse...@gmail.com wrote:

> On a different matter, I have noticed several problems in the
> control points interface. 3281 was basically unusable. In RC2,
> where I only was making a quick check to find gross problems, I am
> not able to move a control point.

I have not experienced this anomaly of being unable to move or
relocate control points under OS 10.4.9 on a PPC machine.

I have noticed that with some images I'll get vastly different
panorama previews if I have used Panomatic to place the control
points as opposed to having placed them manually. Using manual CP
placement, I'll get a "normal" looking preview assuming a good
optimization routine having been run, but under Panomatic, the
preview displays something that I can only describe as being an image
that would be completely unusable, regardless of the projection
chosen. I think this tends to occur when the chosen images are not
optimum, i.e., one of them may be tilted or not straight. I do not
know why manual CP placement works under these circumstances when
automatic placement does not.

Steve

[Harry van der Wolf]

Hi Allan,

Autopano-sift-c IS universally compiled. If you do a "lipo -info autopano-sift-c" you'll get a "Architectures in the fat file: autopano-sift-c are: ppc970 i386".
I won't deny that you get the error, but I like to have some more info.

Can you mail what OSX on what ppc mac you're using?
Can you mail your "lipo -info autopano-sift-c"?

Harry

2008/8/18 akse...@gmail.com <akse...@gmail.com>

[akse...@gmail.com]

Hello Harry,

The PPC is an eMac PowerPC G4 (3.3) running 10.4.11.

Here are the lipo -info results for two versions that do not work. They report ppc970 i386.

[eMac01-Computer:~] seidelfa% lipo -info /Applications/Hugin/Hugin7.RC2/Hugin.app/Contents/Resources/autopano-sift-c 

Architectures in the fat file: /Applications/Hugin/Hugin7.RC2/Hugin.app/Contents/Resources/autopano-sift-c are: ppc970 i386

 

[eMac01-Computer:~] seidelfa% lipo -info /Applications/Hugin/Hugin7.3133/Hugin.app/Contents/Resources/autopano-sift-c 

Architectures in the fat file: /Applications/Hugin/Hugin7.3133/Hugin.app/Contents/Resources/autopano-sift-c are: ppc970 i386

Here is a lipo -info for a version that does work. It reports ppc i386.

[eMac01-Computer:~] seidelfa% lipo -info /Applications/Hugin/Hugin7.3022/Hugin.app/Contents/Resources/autopano-sift-c 

Architectures in the fat file: /Applications/Hugin/Hugin7.3022/Hugin.app/Contents/Resources/autopano-sift-c are: ppc i386

Here is a typical message, "Bad CPU type executable."

[eMac01-Computer:~] seidelfa% /Applications/Hugin/Hugin7.RC2/Hugin.app/Contents/Resources/autopano-sift-c 

tcsh: /Applications/Hugin/Hugin7.RC2/Hugin.app/Contents/Resources/autopano-sift-c: Bad CPU type in executable.

The RC2 matchpoint and panomatic do not generate the Bad CPU type. They report ppc i386.

The 3133 versions of matchpoint and panomatic do not generate the Bad CPU type. They report ppc750 i386 and ppc i386.

It appears that compiling for ppc970 is too much octane for this trusty eMac.

Allan

[Ippei UKAI]

PPC 970 is called "G5" in the market.
Similarly PPC 7400/7450: G4, PPC 750: G3.

On 2008-08-19, at 11:19, akse...@gmail.com wrote:

> Hello Harry,
>
> The PPC is an eMac PowerPC G4 (3.3) running 10.4.11.
>
> Here are the lipo -info results for two versions that do not work.
> They report ppc970 i386.
>
> [eMac01-Computer:~] seidelfa% lipo -info /Applications/Hugin/
> Hugin7.RC2/Hugin.app/Contents/Resources/autopano-sift-c
> Architectures in the fat file: /Applications/Hugin/Hugin7.RC2/
> Hugin.app/Contents/Resources/autopano-sift-c are: ppc970 i386
>
> [eMac01-Computer:~] seidelfa% lipo -info /Applications/Hugin/
> Hugin7.3133/Hugin.app/Contents/Resources/autopano-sift-c

> Architectures in the fat file: /Applications/Hugin/Hugin7.3133/

> Hugin.app/Contents/Resources/autopano-sift-c are: ppc970 i386
>
> Here is a lipo -info for a version that does work. It reports ppc
> i386.
>
> [eMac01-Computer:~] seidelfa% lipo -info /Applications/Hugin/
> Hugin7.3022/Hugin.app/Contents/Resources/autopano-sift-c

> Architectures in the fat file: /Applications/Hugin/Hugin7.3022/

--
->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
MSN & AIM: ippei...@mac.com Skype: ippei_ukai
Homepage: http://homepage.mac.com/ippei_ukai/

[Harry van der Wolf]

Hi Allen,

I have built an autopano-sift-c against an older ppc version 7400. I will send it directly to you. I mention it here for the correct follow-up of this mail thread. You obviously know how to copy it into the bundle. Please test.

Harry

2008/8/19 Ippei UKAI <ippei...@mac.com>

[akse...@gmail.com]

Thank you Harry. It worked. I would have expected the ppc version to work for maybe G3 and certainly G4 and up.

Allan  

[grow]

Harry,
I am starting back a few days at your reply to my message.

Well spotted! You are keeping better track of which versions I am
using than I am! :-)

I am still using Autopano-sift-C because I mostly start from fisheye
images. I tried Panomatic but it seemed to crash with an error
message sometimes and run sometimes If that is not its normal
behaviour with FishEye images let me know and I will go back to it in
a more controlled way and get you proper error numbers etc.

I noticed a few other odd things about this latest build.

1. There are problems with the Control Points window. A duplicate
copy of the right-hand image seems to sometimes get redrawn below
where it should be, obscuring the controls that would normally be
below the right-hand image. Stretching the window makes this image
move back to its normal place. Also selecting a control point on the
left-hand images seems almost impossible. However if I try to drag it
and then click Fine-Tune it seems to end up with the control point in
the right place - it is almost as if it is REALLY moving but the
screen animation for the movement is not being drawn ... if that makes
any sense.
While trying to get a clear understanding of the problem for this
message I moved a control point on a Right-hand image and then
selected undo and Hugin crashed.

2. When I start a stitch running Hugin now seems to launch another
separate process called HuginStitchProject ... maybe it has always
done that but I have certainly just started noticing it. The reason
that I am paying attention is that it now seems that Hugin carrying
out a stitch no longer seems to keep my Mac "awake". My habit has
been to get the control points ready, quit other programs, set the
stitch running and then walk away and let the computer get on with it
and come back in a few hours to a final stitched image. Now, if I do
that, when I come back a few hours later I find the Mac in "sleep"
mode and when I wake it up I find that it has created all
the ..."exposure_layer..." files and enblend restarts running at 98%
of a processor.

I am running on a Power Mac G5 (CPU Type: PowerPC 970(2.2) ) with 2
x 1.8 GHz processors under Mac OS X 10.4.11.

all the best

George

On Aug 17, 3:53 pm, "Harry van der Wolf" <hvdw...@gmail.com> wrote:
> Hi George,
>
> First of all: Thanks for your feedback.
>
> Now to your problems with tif(f). The 3176 build from Ippei comes without
> autopano-sift-c and also without other control point generators. My bundles
> come with extra binaries packaged in like autopano-sift-c, panomatic and
> matchpoint. You even mailed about the missing autopano-sift-c in 3176 and I
> replied (only a snippet):

> *"Still on holiday, but today with access to internet.

>
> to George:
> Ippei built the 3176 without autopano-sift-c, panomatic and matchpoint
> (which I always do). If you know how to "open" a package in Finder, you can
> copy autopano-sift-c from my 3133 version to Ippei's version. It is in

> Hugin.app/Contents/Resources. "*

>
> On my reply, your replied somewhat later (again only a snippet):

> *"Thanks Harry - yes that worked - but I'd guess that you knew it would!"*

>
> So, you used the autopano-sift-c from my build 3133 in Ippei's build 3176
> and now this RC2 build has exactly the same autopano-sift-c: that's weird if
> it behaves differently. Are you sure it's autopano-sift-c?
> Next to that: My autopano-sift-c (31 May) is the latest with regard to code
> changes. The only change has been on July 23rd (after Ippei's build during
> my holiday) only changing the version stamp from 2.4 to 2.5.
>
> In the mean time try panomatic (with -o %o %i) instead of autopano-sift-c:
> It's much faster.
> Enblend had the same issue with tif(f) and has been changed on 18-07-2008.
> Again, after Ippei's 3176 build.
>
> I'll have a look at all my "helper" binaries and libraries to see what needs
> to be updated next to enblend and enfuse.
>
> Harry
>

> 2008/8/17 grow <George...@gmail.com>

[akse...@gmail.com]

I see the very same when using RC2. The duplicate right hand copy is
similar to something that I've seen happen many versions ago when
resizing the control points window. I find selecting a point to move
impossible when zoomed in. I have seen points appear on one side when
placing them on the other side. The automatic find was in effect. I
guess the matching point was found and placed without placing the
original point. The Control Points window exhibits so many problems
that I figured there was no point mentioning it. Sooner or later it
will be fixed. I have been out of the loop for a couple or OS X
builds. Usually each build is an improvement. This RC2 is a couple of
steps backwards in the control points window section.

Allan Seidel

[Charlie Reiman]

I have complained about these bugs before. They are fallout from the
move to the latest wxWidgets as that's when I first saw them. I
suspect they won't get fixed unless we show them to the wxWidget guys.
The macport builds I've made exhibit the same (and a few other extra)
bugs, so it's definitely not Harry's fault.

Deep in my heart I'd really like to make a Cocoa version of hugin even
if it meant forking. This semi-portable UI widget stuff always only
semi-works.

[Harry van der Wolf]

I will probably build a new Hugin this weekend. Currently Ippei is making all kind of changes to the build so it's not stable right now. I'm not sure either whether I can adapt my build quick enough to Ippei's changes.
The new build will deactivate the new "improved" wxwidgets functionality and switch back to the old functionality. Next to that the boosts libs will be upgraded as the new 1.36 stable version is now released.

Harry

2008/8/21 Charlie Reiman <reima...@gmail.com>

[Harry van der Wolf]

And about:

"Deep in my heart I'd really like to make a Cocoa version of hugin even if it meant forking. This semi-portable UI widget stuff always only
semi-works."

Last year, or the year before that, Ippei worked on a QT version also for GSOC. In my eyes QT is a nicer cross-platform than WxWidgets, but I certainly don't have the knowledge to make it.

Harry

2008/8/21 Harry van der Wolf <hvd...@gmail.com>

[Harry van der Wolf]

2008/8/20 grow <Geor...@gmail.com>

I noticed a few other odd things about this latest build.

1. There are problems with the Control Points window.  A duplicate
copy of the right-hand image seems to sometimes get redrawn below
where it should be,  obscuring the controls that would normally be
below the right-hand image.   Stretching the window makes this image
move back to its normal place.   Also selecting a control point on the
left-hand images seems almost impossible.  However if I try to drag it
and then click Fine-Tune it seems to end up with the control point in
the right place - it is almost as if it is REALLY moving but the
screen animation for the movement is not being drawn ... if that makes
any sense.
While trying to get a clear understanding of the problem for this
message I moved a control point on a Right-hand image and then
selected undo and Hugin crashed.

Yes, you are right. We used the new "improved" functionality of wxwidgets but it is obvioulsy not completely mature yet. The next build will switch to the "old" functionality.
 

2.  When I start a stitch running Hugin now seems to launch another
separate process called HuginStitchProject ... maybe it has always
done that but I have certainly just started noticing it.  The reason
that I am paying attention is that it now seems that Hugin carrying
out a stitch no longer seems to keep my Mac "awake".  My habit has
been to get the control points ready, quit other programs, set the
stitch running and then walk away and let the computer get on with it
and come back in a few hours to a final stitched image.  Now, if I do
that,  when I come back a few hours later I find the Mac in "sleep"
mode and when I wake it up I find that it has created all
the ..."exposure_layer..." files and enblend restarts running at 98%
of a processor.

Yes, I know this happens. I did not find out yet why it happens in my scripted build and not for the XCode build. I think it has something to do with the Info.plist settings in the internal HuginStitchProject.app. I'm investigating it.
And about the "sleep" mode: that's new to me. I will have a look at it.

Harry

[Ippei UKAI]

On 2008-08-21, at 15:30, Harry van der Wolf wrote:
> I will probably build a new Hugin this weekend. Currently Ippei is
> making all kind of changes to the build so it's not stable right
> now. I'm not sure either whether I can adapt my build quick enough
> to Ippei's changes.

Just to be fair, I have no intention of making anything unstable at
this stage. Indeed I had to straighten up the autopano behaviour (so
to respect the 'custom autopano' option at the very least), but good
thing is that the new system is implemented in a proper way and now
working well for me at least.

The build process isn't changed much; just small adjustments towards
the release.

Ippei

[Harry van der Wolf]

Sorry Ippei,

I didn't mean it like that. I meant that as long as you were not ready with your changes and I didn't know where you were going,  I wasn't going to build a new bundle. It's hard to aim at a moving target.

Harry

2008/8/21 Ippei UKAI <ippei...@mac.com>