Huginコミュのhugin 0.7β

ぺーさんこんばんは。おひさしぶりです。
hugin 、着々と進んでおられるところが聞けて、そのことがまずうれしいです（そして、ありがたいです）。

さて、ぼくのような、パノラマについてしろうとの立場からすると、いまの hugin でじゅうぶん楽しめているので特に思うところもないというのが、正直な今の感想なのですが、ただ想像を働かせてみると、ひとつ浮かんだ事がありました。

それは、いまのユーザーインタフェースは、コンピュータに馴染みの浅いひとにはちょっと敷居が高そうに見えなくないかな、と懸念されたところがあります。

たとえば設定画面でパラメータをセットするところです。ツールのオプションをコマンドライン・オプションのように渡すのではなくて、いわゆるネイティブアプリのように、チェックボックスとかが用意されていると、コマンドラインに馴染みのない方々にも安心して、より深く使っていただけたりするのではないでしょうか。と、想像しています。

具体的には Enblend のところでそう思ったのですが、品質にかかわる重要なところでありながらも、オプションの渡し方がいわゆるふつうのアプリケーションとは形を異にしているので、悩んでしまったり、そもそも気をかける事もなく済ましてしまって、結果、機能を十分発揮できていないことに、なりはしまいかと思ったのでした。

しょうしょうくどくどしくなってしまいましてスミマセンが、そういったところにある、いうなれば UNIX 臭さがも少し取れると、一般に普及させやすくもなることになるんではないかと思っています。

あとは、、、 HuginOSX での話になりますが、どうもバグらしき挙動に遭遇したので、別トピックにひとつ、（あとで）上げておきます :-p

hugin 0.6.1 リリース + 不具合報告
http://mixi.jp/view_bbs.pl?id=9704725&comm_id=898110

一昨日の晩、
早速インストールしようとterminalでmakeしてみたんですが、
出来ませんでした...なんで？（謎
ソースをコンパイルする前に、
他のいろんなものをインストールしないといけないんでしたっけ？

なので「QTVR Diary」で、
リリース告知しようと思ったんですが、止めました。
成功するのは、いつになるんやろう？

いろんなものがないとコンパイルできませんね。いまだにmacのバイナリ出せるの僕だけなのかも…　ま、最近はコマンドライン用のスクリプトも加わったようですが、DarwinPortsを前提にしているようです。自分はひとつひとつコンパイルしてます（スクリプトがmac/Notes/scriptsに入ってます）。

バイナリをsourceforgeに上げてあるのでどうぞ。

>ぺーさん江
クリスマスなのに徹夜仕事モードです。
で、現実逃避的にQTVR関連ソフトのサイトをぜーんぶ巡回してたついでにhuginのサイトも見ていたら、何とMacOS X版のバイナリを発見！速攻でダウンしました。
...ら、ペーさん上げてくれてたんですね！感謝×100倍です（笑

そして、今回からPanoToolsもAutopano-siftもEnblendもパッケージ内に収められたんですね。でも外部アプリを読み出そうとするのは、なんでなんやろ？

あと、相変わらずAutopano-Siftが動かないんですが、もしかして対象ファイルのパスってかなり制約がありますか？日本語名は御法度としても、ディレクトリ名に半角スペースがあってもダメだとか...どうでしょう？

PanoTools関係も、ちゃんと動いてくれないところを見ると、まだまだ改良点がありそうです。PTMacやPTGuiに“追いつけ追い越せ”には、まだまだ時間かかりそうですね。
HDRIによるスティッチが出来るアドバンテージはまだ揺るぎなさそうなので、今のうちにどんどん開発してって下さい！（笑

とりあえずQTVR Diaryで、0.7β1のリリースアナウンスをしときました。
ついでに、mixiのhuginコミュのことも宣伝しときました。
更に、へたなわさんのhPodの宣伝も、しときました！（笑

あけまして、おめでとうございます。

12/31にβ2のリリースが、そして1/1に何とβ3のリリースがあったようですね。いろんな部分でのバグフィックスがメインのアップデートのようですが。
今のところソースコードとWin版がアップされています。

なので...
>ぺーさん江
MacOSXバイナリーのアップ、お願いします！

こんばんは。
間が空いてしまいましてごめんなさい。あけましておめでとございます。

HuginOSX ですが、この週末に、β3 をビルドしてみようと魔が差してしまって、じつは今日までハマってました。

ものすごーくコンパイルに時間がかかるんですね... 。それからぺーさんおっしゃるとおり、いろんなものが必要でした。設定？を誤っては configure からやりなおして、夜ねるまえに make して、朝起きると Error... で停まってて、また夜に見直し、朝まで make 。そんなことを３日くらいくりかえしてようやく今朝、 make が終わった模様です。

かなり歯ごたえがあって、新しく覚えた事もあったので、それはそれで楽しかったです。

さて make が終わって気づきます。 hugin の実行形式はできあがったんですが、これ、 Mac 用の .app にするには、どしたらよいのかと... 。

Xcode のプロジェクトファイルが同梱されているので、そこでなにかするのだとは思ってるんですが、 Xcode は AppleScript Studio 程度でしか触った事がないので、怖れております :-p

そもそも make する前から Xcode で始めないといけないんでしょうか、そしてこのビルドした実行形式を実行すると、果たしてなにが起こるのでしょう... 、でもバイナリができあがったことで満足してしまっていることも否めません... ;-)

こんばんは。乗りかかった船なので Xcode 触ってみました。

パチパチといじっているうちになんとなーく判ったような、そうでないような感触なのですが、 Header path の位置を確認して、思い切って Build してみました。

でも、ターゲット all でどんな様子かなと見てみたらば：
gcc-3.3: (my_dir)/hugin-0.7_beta3/mac/../src/klt/convolve.c: No such file or directory
といったところで停まってしまいました。src の中に klt ディレクトリがごっそりないみたいで、そのせいかと思ったのですが、 klt も別途、入れて行かないといけないのでしょうか？　（ libklt って？？）

たぶん、そういったところを直し直し、ターゲット内の赤い文字になっているところが黒くなるように、準備を揃えて行けばよいのですね。

うっはー、大変ですねぇ＞ヘタナワさん

ボクは、さすがにXcodeまで手を出そうとは微塵にも思っていない輩なので、本当に本当に、頭が下がります。

アプリが出来る過程（というか苦労話）を聞いてしまうと、おいそれとクレームとか非難とかダメ出しとか、出来なくなってしまいます...（苦笑）

hugin のバイナリのタイムスタンプ 04:00 を見たら、このとき０時くらいから make を始めたので、ざっと４時間かかったんですね... （じぶんは眠っていますが）。うち G3 なので、もともと遅いんですけど。ちなみに、このバイナリは Bus error ってひとこと呟いて、おなくなりになりました... 。

こうしてもたもたしているうちに、次が出そうな気もしますね :-p
でもまあ、本来の目的は置いといて、プラクティスでやっています。 Xcode の使い方もそうですけど、そもそも gcc の使い方を知っていないとはじまらない、ということはわかってるんですが、なんせ深く広い世界ものなので、うわずみをさらりと啜っただけの知識ではなかなか捗りません... 。

ときに、さっき少し触れた「赤い文字」は存在しないファイルなんですね。ライブラリの場合は、それがなければそれを先にビルドすればよいのですが、ソースファイルの場合、それがそもそも見つけられないんですよね... さっき Google に訊いてみたんですけど、 klt とか、 hugin で使われているらしいことだけしか、わかりませんでした。

── hugin はオープンソースのプロジェクトですし、もちろん、デベロッパの方々はいわばボランティアで世に貢献していらっしゃるのですから、クレームとか避難とかダメ出しだなんてもってのほかです、少なくとも同じ土俵の上に立っていない限り。

すみません。CVSのXcodeファイルはちょっと古くなってます。いい加減更新しないとですね。よかったらmacフォルダ内の現状をコピーして送ります。ちなみに一旦動いてしまえばXcodeの方が簡単です。ちなみにプロジェクトファイルがアップデートされているのでXcodeはTigerの新しいやつじゃないとダメなはず。

それはさておきbuild_using_cmdlineというファイルはご覧になりましたか？これを使うとコマンドラインでもコンパイルできるらしいです。（僕はほぼノータッチだったのですが、他の開発者が作って開発に使ってるようです。）install2bundle.shというのを最後に実行してアプリのバンドルを作っているようです。ちなみに手動で古いバンドルの中のContents/MacOS/HuginOSXをできた実行ファイルで入れ替えるというのも奥の手です。

ま、よければCVSからコンパイルしたものを送ります。多少バグが取れてはいるようです

僕も ヘナタワさんのようにhuginをMacで使ってみたくてプログラミングをはじめたようなところがあるのですが、もうそれから２年半です。

ぺーさんこんばんは。

なるほど。プロファイル内に記載された hugin のバージョンのところが、 0.61 とあったんで、書き換え忘れか、もしや古いのかと思った事もありました。ソースが配布の中にないのもそのせいかしらん、って。

build_using_cmdline.* は見ました。これ、上のほうのコメントでおっしゃっているように darwin port （パッケージングシステムの一種？？）が基盤になっているようですね。ぼくはパッケージシステムに頼りたくなかったので、使おうとは思いませんでした。ときにさっきちょっと調べてみたら、その port は hugin 0.6 がターゲットのようにも、見受けられました。 txt に書かれていた URL のひとつも NOT FOUND だったりしました。

ということもあり、できるだけ自力でビルドまで突き進んで行こうと決心して、知りもしないライブラリたちをたくさん入れていったのはいいのですが、でも、最終的に頼りにしていたプロジェクトファイルは駄目なのですか（ははは... ）

プロジェクトファイルは自作できそうもないので（ ADC の英語の資料を十分に理解できる程の語学力がないので）、ひとつ、頂戴したいところなのですが、 Tiger 専用となると、残念ながらぼくのところでは用をなし得ないようです。ちなみにうちの Xcode は 1.5 でした。

という状況ですので、じぶんのプラクティスはそれはそれとして、最終的なビルド（アプリケーション）は、いち一般ユーザとして、リリースをお待ちしております。

ただお話から想像するに、いま手元の赤い文字がたとえみんな黒くなっても、完成にはこぎつけられそうもなさそうですね。でしたらば、練習するんだったら、最新のではなくて、まえのリリースのソースを元にやったほうがよさそうですかネ。

ちなみにいま enblend の make でハマってます。ライブラリの依存の関係で？ hugin の先に入れておかないといけなさそうだったのですが、最新の enblend を持って来たら make でエラーが。ぺーさんのノートを見ましたが、パッチ充ててますね。そのへんを見ながらちょっとやってみます。でもどうしようもなくなってしまったら、そのときはちょっと助けてください。

ぺーさんは hugin からプログラミングを始めたんですか。それも Mac で。とはいってもじつは Mac って、プログラミングとか、開発環境がすばらしく整っていますよね。といっても、じぶんはコンパイル言語は使えないのですけども、それでも。ただマック信仰とか言われてからかわれたりしかねないので、あまりわいわい褒めないように気を使いますが... ;-)

つづけさまですが、進展があったので、行きがかり上ご報告です。

#7 のコメントのところで作ったと言った「 UNIX 実行形式」のそれを使って、ビルドできました。驚くべき事は、ビルドしたその HuginOSX.app が、ちゃんと起動できたのです :-)

ペーさんの install2bundle.sh をつかってごにょごにょ... というところに閃きを得て、その内容を確認したうえ（少し改造して）、「バンドル」を作ってみたら、それがつまり HuginOSX.app なのでした。

ぼくは Mac OS X のアプリケーションの開発手順に明るくないがためにつまづいていましたが（バンドルがどうの？こうの？とか）、こういうことなんですね。──あ、体験的に知ったという事で、理解は今後の課題ということで。

起動できた事は、ほんとうに驚きでした。そして嬉しかったです。まさか起動してすぐに落ちるオチじゃないかしらと、はらはらしましたが、オチなかったのでまた驚きました ;-)　これ、できてしまえば、できてしまったのですよね？

... もっとも肝心なのは、ベータ版を試用してみることなのでしょうから、大きな横道はこれにて終わりにして（お付き合い頂きましてありがとございました）、本題である（であろう）ベータ版をこれから使ってみたいと思います。

Xcode1.5用のプロジェクトファイルはずーっと昔のやつなのでいろいろ更新してやらないと動かないと思います。

まあ、最新版のテストだけなら次からCVSをUpdateしてmake で一晩ですね。

いろいろご意見お待ちしてます。

こんにちは。 0.7 の目玉はウィザードになるでしょうか。早速試してみました（ HuginOSX です）。

まず第一印象で気になったところ：

ファイルの選択ダイアログの中で、複数のファイルを選ばなければいけない場面になりますが、シフト＋クリックで複数選ばせるところが気づきにくいです。あまり見かけないインタフェースなので。ドラッグ＆ドロップできるといいなと思いました。

ファイルを選択して OK したら、 SIFT が動き出しました。そのとき、リリース版を使っていた時の設定が読み込まれていたので、外部プログラムの Autopano-SIFT が動き出したのですが、デフォルトの設定に直して再度試行してみたら、 SIFT が見つからない状態になってエラーでした。これはぼくのビルドの仕方に問題があるのでしょうか（ソースがなかったような気がします）。

Autopano-SIFT が終わったらプレビューウィンドウが開きました。ここの動作がいちじるしく不安でした。投影法を変更してもプレヴューの状態が変わりませんです（リロードボタンをクリックしても）。変わる時もありましたが、再現性を掴めていません。ちなみに自動更新ボタンのアイコンが消えていました。
また、プレビューウィンドウの背後になっているメインのウィンドウの描画もおかしくなったりします。ウィンドウをアクティブにすると正常に戻ります。

デフォルトの設定でスティッチで書き出ししてみたとき、 TIFF ファイルが書き出されませんでした。これは、 enblend が存在しなかったためで、リリース版のバンドル内にあったそれを、じぶんのビルドの中にコピーしたら OK でしたので、これもじぶんのビルドがいけなかったんです。ただ、 SIFT のことと併せて、使えない機能があるときは、実行できないように、インタフェースのほうで実行をブロックしてくれるといいなと思いました。

──ウィザードは、手動で作業する時の流れとは違った流れなので、メインのウィンドウに並んでいるタブが、離れている方がいいなと思いました。手動の時は、タブを左から順に開いて作業して行くので、その流れの中で第一番目がウィザードですと違和感がありました。

プロジェクトをセーブしたら拡張子が ".pto.mk" となりました。 mk ？

0.6 のときに、作業のあと、新規にもうひとつやろうとして、ファイルを登録したとき、クラッシュする問題はおきませんでした :-)

それから手動でもやってみましたが、たびたび落ちたり、画面描画がおかしくなったりと、そういった不安定なところはベータ版ということですし、そういうものかと受けていますが、全体的に反応が鈍くなっている感触でしたので、非力なマシンにとってはつらいところでございます。

ウィンドウのレイアウトは 0.6 と比べてかっちりした感じがしていいですね。

と、とりあえず第一印象でした。

ちなみに昨日ぼくのブログに HuginOSX についてコメントがついたのですが、その方は Mac OS X （ Panther ）のインストールオプションを変えてインストールし直したあと、それまで動いていた HuginOSX が動かなくなったということでした。詳細は不明ですが、たぶん BSD システムのチェックを外してカスタムインストールしたんでしょう。ただ、そのへんの依存するシステムの説明書きが必要に思いました。ほかにも以前から Autopano-SIFT が動かないと言った報告も何件か頂戴しており、もしかしたらその方々も、基盤となる Mac OS X のインストールの仕方が違っている（何か欠いている）のかもしれませんね。

こんばんは。ウィザードではなくて「アシスタント」でしたね。

でもアシスタントは Autopano-SIFT がセットアップされていないと、駄目なようでした。ぼくのところではうまくセットアップできているので、問題なかったですが、そうでない方もいらっしゃるので、その点が気になりました。

ただ、一方で、以前少し触れられていた Autopano-SIFT の C への移植版が、 autopano-sift-C としてリポジトリに上がっていたのですね。これに気がついて、ビルドして、使ってみました。

レポートはブログに書きましたので興味ある方がおられれば、覗いてみてください：
http://hwat.sakura.ne.jp/hpod/200701/19-220000/

これは、将来的には、いまある Mono フレームワーク上のそれと置き換わるものなのでしょうか？　だとしたら、アシスタントもそのまま使えるようになるでしょうし、処理速度も向上するので、とても期待されるものとなると思います。

こんにちは。

autopano-sift-C の続きなのですが、これまでは手動でコマンドラインで動かしていたのですが、 hugin のインタフェースから使えるように、こまごましたところを調整しました。というか調整が必要でした。

ぼくは C は使えないのですが、入門程度の知識はあって、その少しの知識でも直せるところがありましたので、ご報告したいと思います。（ついにソースを眺め始めてしまいました... ）

ポイントは二箇所あって、ソース AutoPano.c の中になります。

(1) AutoPano.c の中で、コマンドラインを parse する最中で、 sscanf の使い方が間違っている箇所がありました。２箇所。第一引数と、第二引数が、あべこべでした。これを書き換えました。

誤
554: if (sscanf("%d", argv[optionN + 1], &maxMatches) != 1) {
正
554: if (sscanf(argv[optionN + 1], "%d", &maxMatches) != 1) {

誤
582: if (sscanf("%d", argv[optionN + 1], &generateHorizon) != 1) {
正
582: if (sscanf(argv[optionN + 1], "%d", &generateHorizon) != 1) {


(2) それから同ファイルの WritePTOFile 関数の中で、画像ファイルのパスを得るところがあるのですが、そこで用いられている Utils.c の FileNameToFullPath 関数と、 FullPathToFileName 関数がアヤシイです。ここのブロックでは、コマンドラインオプション --absolute-pathnames の値によってどちらかの関数にかけて、画像のパスをどうにかしようとしているのですが、しかし一見した限りでは、このブロックは不要な感じがしたので、コメントアウトしました。

char* imageFile = kx->imageFile;
/* コメントアウト
if (useAbsolutePathnames)
imageFile = FileNameToFullPath (imageFile);
else
imageFile = FullPathToFileName (imageFile);
*/

と、それだけなんですが、 Mono 版の autopano-complete.sh と同じようにして使うためには必要な修正だと思われました。これをしないと HuginOSX のインタフェースから動かせません。

以上を書き換えてコンパイルしたら autopano-complete.sh を Mono を使わないようにして書き換えて、そしてそれを HuginOSX の環境設定から指定してあげたら、オプションもそのままの状態でも、期待どおりに動きました。

autopano-sift-C にはとても期待していますので、ぺーさん、よろしくおねがいします！

あ、あと generatekeys コマンドで key ファイルを gz したものは autopano コマンドが受け付けてくれませんでした（そこは深く追っていません）。
そのかわりに autopano-complete.sh のなかで、 generatekeys で gz しないように、書き換えています。

MLから、β4がリリースされたことを知りました。

===

Hugin 0.7 beta 4 has just been released.
This release supports all new projections in libpano13. The
windows package contains the latest panotools build as
well as Enblend 3.0.

Source code and windows executables can be downloaded from:
http://hugin.sourceforge.net/download

Newsworthy changes in hugin 0.7 beta 4
-------------------------
* update panotools to latest version
* Albers equal area conic and Miller cylindrical projection
* Support for straight line control points
* Fixed running of Autopano-SIFT integration on windows
* (linux) work around bugs in wxWidgets (fixes double deletion
of control points when pressing the Del key)
* Force even values for width for 360 degree equirectangular
panoramas.

Enblend 3.0 is *MUCH FASTER* than Enblend 2.5, and chooses
the seams to hide mismatches and parallax errors.
While testing it on my 64bit linux machine, it was faster
than the latest version of Smartblend.

===

Win版にはEnblend3がいよいよバンドルされたんですね。
2.5よりSmartblendも断然速いって言ってますね。ワクワクするなぁ。
MacOSX版...ぺーさん、お願いしますね。

とりあえず上げておきました。ついでにCVSのMac関連のファイルを全部更新。

enblendはこちらに変更したソースも。OpenGL関連のヘッダーが面倒くさいのでPPCも10.4u SDKでビルド。Pantherで動かないかも。
http://homepage.mac.com/ippei_ukai/software/hugin/enblend-3.0_mac.zip

こんにちは。ためしにぺーさんのそれをダウンロードしてみましたが、 Panther ではうごきませんでした。（案の定？ "expected to be defined in OpenGL" とのことです。）

この機会にお願いです、
リリース版では、どうか Panther を見捨てないでください... 。

ま、面倒くさかっただけなのですが。GLEWとリンクするとライセンスがややこしそうで。まだよくわかってないのですが、SGIとGLXはバイナリで使う分には問題なさそうですね。

http://homepage.mac.com/ippei_ukai/software/hugin/enblend-3.0_mac-2.zip

ぺー さん＞
ごめんどうをおかけします :)

おかげさまで、動きました。動かしてみた様子は enblend のトピックに書きましたが、早くなりますですね。それだけでもとても有難いです。


ところで beta 4 のビルドを試みたんですが、 beta 3 と同じ手順をちゃんと踏んだんですが駄目でした。

どう駄目なのかと説明するのも、門外漢にはなかなか難しいのですが、直ぐに判る事でしたら（それも判断しかねるのですが）、ちょっと教えてほしいのです。

boost::thread_group のシンボルが見つからない、と言われます：

...
...
/bin/sh ../../libtool --mode=link g++ -g -O2 -L/usr/local/lib -ljpeg -L/usr/local/lib -ltiff -L/usr/local/lib -lpano12 -lboost_thread-gcc-1_33_1 -lexpat -o nona nona.o ../../src/Panorama/libpanorama.la ../../src/common/libcommon.la ../../src/foreign/vigra_impex/libvigra_impex.la ../../src/jhead/libjhead.la ../../src/vigra_ext/libvigra_ext.la
g++ -g -O2 -o nona nona.o -Wl,-bind_at_load -L/usr/local/lib -lboost_thread-gcc-1_33_1 ../../src/Panorama/.libs/libpanorama.a /usr/local/lib/libpano12.dylib ../../src/common/.libs/libcommon.a ../../src/foreign/vigra_impex/.libs/libvigra_impex.a /usr/local/lib/libpng.3.0.0.dylib /usr/local/lib/libtiff.dylib /usr/local/lib/libjpeg.62.0.0.dylib -lz -lc ../../src/jhead/.libs/libjhead.a ../../src/vigra_ext/.libs/libvigra_ext.a /usr/local/lib/libexpat.dylib
ld: Undefined symbols:
boost::thread_group::create_thread(boost::function0<void, std::allocator<boost::function_base> > const&)
boost::thread_group::join_all()
boost::thread_group::thread_group()
boost::thread_group::~thread_group()
make[1]: *** [nona] Error 1
make: *** [all-recursive] Error 1
$

configure の結果：
BOOST_THREAD_LIB = -lboost_thread-gcc-1_33_1

で、このファイル libboost_thread-gcc-1_33_1.a はあります。 nm で中を見てみて create_thread らしい文字は見えたんですが... 解りませんです :-(

ちなみにそのまま同じ（シェルの）環境で beta3 のディレクトリに移って、同じように configure したものは、最後まで行けました（ひと晩明かしましたが）。

──こちらの環境のことでもありますし、調査していただくには及びませんので、込みいったことになりそうでしたらスルーしていただいて構わないのですが、ただすぐに気がつくような問題でしたら、そういう問題だという事を、ちょっと教えてほしいのです。

boost threadのコンパイルし直しですかねえ…
boostのコンパイルが面倒くさくてvigra_extの一部としてxcodeで一緒にコンパイルしてたりするので、ちょっとパスですね。

ぺーさん＞
コメントありがとございます。

vigra_ext が何だかはしらないのですが、それを頼りにして、ディレクトリ vigra_ext の中を覗いてみたら、べつにソースも変わらず、オブジェクトファイルのサイズも変わらず、でも libvigra_ext.la だけが、 beta3 と比べて 1 バイト少なかったのが薄気味悪かったですが、それは長い余談で、 Makefile を見てみたら、 boost 関係のところで、 boost への include パスがセットされていませんでした。

ただ、そこにセットして vigra_ext をつくり直しても駄目で、次に nona が入っている tools の中の Makefile を見たら、ここでも boost への include パスが欠けていたように見えました。

でも、たぶん、それらではなくて、変数 nona_LDADD にセットしているいくつかのライブラリのリストの中に、 $(BOOST_THREAD_LIB) が欠けていたのが原因のようでした。

./configure したときに記述されなかったのでしょうか？　どこが何がいけないのか、判らないのですが、これを付け加えたら make の続きが始まりました。

今週はこれに毎晩悩んでいたので、便秘に通じがあったように... いえちょっと下品でしたので言い改めると、長年の溜飲が下る思い、いやそれは大袈裟ですね、つまりノドのコボネが取れたように、すっきりしました。ありがとございます。

完成は夜明けごろの予定？？です :-)

Macの方、よかったらどうぞ。
http://homepage.mac.com/ippei_ukai/software/hugin/autopano-sift-c_mac-cvs20070320.zip

Mac版のSVN snap、更新しました。
http://homepage.mac.com/ippei_ukai/software/

ついにβ状態を脱したようですね、0.7。OSX版のバイナリがアップロードされていて感動しました。ペーさんへのトリビュートも忘れられていません。


http://panorama.dyndns.org/index.php?lang=en&subject=Hugin&texttag=Hugin


さて、暇を見付けて使い倒してみよう。

どっちかというと去年の時点でα版に戻ってたような…　随分前からナンバー付けてリリースするのを止めてNightly的なビルドをテスト用に配布する体制に移ってます。

卒論で忙しくなってからはHarryがビルドを配布してくれてます。こまめにアップデートして下さっていて本当に感謝です。最近ほとんど追ってなかったのですが、そろそろもう一度みてますかな。まだまだ細かなところを修正していかなきゃならない状況じゃないかと思います。0.5から0.61にかけてとかなりシステムの構成が変わっちゃってますからねえ。

http://hugin.sourceforge.net/

ここによると：

----
hugin has now reached stable state: the software is recommended for general use.

A current pre-release version with all the new features can be downloaded for Windows and for OSX or built for Linux.

The outdated previous stable version is 0.7 beta 4, it can be downloaded for Linux, OS X and Windows, but it is no longer supported.
-----

とのことなので、少なくとも一般でいう RC 状態になったということじゃないんですか？

今年の２月ぐらいから、Harryさんがずっとリリースし続けてくれてますね。
ついでにEnblend／Enfuseも面倒みてくれてるので、
ボクらのような、ノンプログラマなマカーにとっては、とっても有り難いです。

一応、ウチでも全部ダウンロードし続けてますが、
最後の保存の時にオチるのは、未だ解消してないです...が、たぶん、ウチだけだと思います。
一応、AptopanoSift-Cがきちんと動いてくれるのが、とっても有り難いです。
あとは保存時にEnblendが動いてくれれば...。
なので未だに、AppleStore心斎橋のオフラインセミナーで、hugin特集ができず、
結局はPTGui特集をしてしまいました（苦笑

↑私は全然、保存大丈夫ですよ。0.7系は6/17のビルドしか使ったことがありませんが。

一度、初期設定ファイルなどを消去してみてはいかがでしょう？


私はお遊びで最近パノラマを始めたばかりのどしろーとですが、感想としては PTGui 7.2よりは大分優秀な気がします（最新のautopano-SIFT-C と enblend だからというだけ？）。コントロールポイント指定の GUI がちょっとバギーですが。元画像がしっかりしていれば、かなり作業が早くなりそうです。そのためには DSLR とまともな魚眼が欲しいところですが ( ´Д｀;)

"hugin has now reached stable state ..." は0.5リリースのことじゃないでしょうか。それまで安定版がなかったですから。

＞最後の保存の時にオチる／AptopanoSift-Cが／保存時にEnblendが
まだまだですねえ。僕も最近は0.61で大半を仕上げた後、明るさの調整に0.7系使ってenblendは手動なんて感じですかね。開発版はツールがパスの通ってるところにインストールされてないと動かないのかも知れないです。

私は以前から定期的にこのページを確認していて、0.7 beta 4 の Mac版に関してはバイナリがないから自分でビルドしてくれ、と、ソースへのリンクしか貼られていなかったのが、この間見たらこういう書き方になっていて Harry さん（？）のページにリンクが貼られていたのでそう判断したわけです。あと

>>The outdated previous stable version is 0.7 beta 4

以前までの安定バージョンが 0.7 beta 4 だ、と言っているから、やっぱり 0.7 の話だと思うんですけどねぇ。

まぁ、ある意味どうでもいいことなんですが（笑）

個人的に大事なのは、自分でビルドする気力もスキルもなかった 0.7 が、一応使える状態になったということでして。