Posts Tagged ‘PTMac & Panotools’

PTMacとPanotoolsのチュートリアル作成中なのですが。。

実はなかなか難しい面に直面しています。
自分では理解していることでもヒトに説明するのはとても難しい。しかも、既存のチュートリアルや解説のほとんどが英語なので、まず用語の和訳(単語同士の対照の定義)から始めなければならない点が多数あります。

ベンダーの用意している英語版のチュートリアルが懇切丁寧で判り易いものであるので、かえってそれを和訳する時の労力が。。。ばかにならない。
んーむ。

Lensfix メモ

左糸巻き右タル。(謎)

FisheyeZoom+PTMacによる作例

あまりにも引っぱり過ぎるのもこんなちんけなネタでは変なのですこしUPしてみましょう。(笑)

まず最初に御見せするのはペンタの魚眼ズームレンズと*istDによるストレート画像です。
画質があれていますがそれは間違えてiso800相当で撮影してしまったためなのでここでは気にしないで下さい。RAWで撮影してC1proで画像化していますがそういうわけなので画質面では全く評価対象にはなり得ません。その点は差し引いてみて下さい。

CapturedFisjeyeImage.jpg

(続きを読む…)

Xpoints

何の気なしにPTMacのオフィシャルサイトを覗きにいったら新しいヘルパー?アプリのβ版が配布されていました。Xpointという名前のアプリです。登録ユーザ向けのベータ配布なのでリンクはしませんが正規ユーザの方は覗いてみると幸せになれるかもしれません。もちろんβ版ですから地獄とはいかないまでもどん底ぐらいまで落ちる可能性もありますが。。

未試用ですが、Xpointを利用することでControlPointの設定が自動で行なえるようです。うまく動作するようになれば特にノウハウや修練も積まずに正確なパノラマの書き出しができるようになるでしょう。
んーむ。だんだん俺のアドバンテージがなくなっていく。(爆)
G4およびG5とそれらのマルチプロセッシング対応のLibraryも公開されています。(これはBetaPhaseのV3.4向けではなく正式版のV3.3向けのリビジョンアップ版です)Altivecを利用したこのLibraryを使用すると処理がかなり高速になるそうです。反面、Altibecを利用しないプロセスで処理した場合と比較して若干ではありますが有為な精度の低下があるようです。その低下の度合いは「通常書き出される程度の大きさのパノラマ画像の解像度でおよそ1pixel以下」だそうです。私がいつもかいているような大型のものだと2ないしは3pixel程度乱れるということになるでしょうか。
んーむ。これもビミョーな。。。

BetaPhaseのV3.4もリビジョンアップしたビルドが公開されています。(って。。ここで書いていいものなのかよく判らない。。)

New version of PTMac

まだベータ版で正式公開はされていないのですが、新しいバージョンのPTMacを少し試してみました。

(続きを読む…)

PTMacアップデートされる(笑)

今回のアップデートはMacOSX向けのもので

  • メモリの扱い方を改善し、より大きなサイズの書き出しを可能にした
  • ファイルパスに2バイト文字が含まれていても正常に動作するようにした
  • メモリのハンドリングの変更に伴い相当以上に処理速度を向上させた

。。。ということのようです。
何やら俺が先週苦労していた事のすべてがこれで解決されてしまっているようで結構個人的にはちゃんちゃんなカンジなのですが。。 おそらくは日本のユーザからのフィードバックがあったのだと思います。何にせよ日本にもPTMacのアクティブユーザが増えるのはいい事だと思いますので、素直に喜びたいと思います。 自分ももう少し英語が堪能ならばフィードバックできる事は山ほどあるのですが。。。
もっとも日本語で書いていても意味不明な文章になっている面も否定は出来ないのですが。。(謎)

QTVRの生成時になぜステッチ画像を90度回転させなければならないか。。

この問題について以前パノラマ師匠のN君と飲んでいたときに話題が出て彼も疑問に思っているという事だったのだが、この間参考文献をwebで漁っていたときに英文のテキストの中にそのヒントになる記述があった。

(続きを読む…)

QTVRの解説

PTMacの使い方を含むQTVRの作法の解説記事を書こうと思って着手している。少し時間がかかるかもしれないけど毎日少しづつ書いて行こうと思っています。
まずは作例を挙げる事の方が先だろう。。と思いつつそちらのHTMLも少しづつ書いている。XHTML1.0とHTML4.0で頭の切り替えがうまくいかずにそれがストレスになっていたりもするけど。。ま。少しづつ。

16000pixel達成

とりあえず当初の目標だった表題のデータ解像度(というよりもデータサイズと言った方がこの場合は適切かも)を達成しました。 とはいうものの。一定の達成感はあるけど予想通り何の感動もない状態です。(意味不明ですが、ほんとにそんな感じ)
細かい方法についてはいずれ細かく書いた方がいいと思うけど、言葉で説明しただけだと多分伝わらないと思うので後に譲ります。

しかし。今日のこの涼しさでも処理中に熱でeMacのモニターがバッツンバッツンと怪しい音を立てて明滅したり(笑)なかなか厳しいものがあります。処理中にスワップがうまくいかなくなって急遽強制終了から再ログインしてデータをバックアップしたりするなどドラマトゥルギー横溢と言うべきか。。。
とりあえずこの方法で16000pixelは達成できたし応用すれば計算上は24000-30000pixel幅までは実メモリ1GBでも多分いけると思いますが、システムとハードウェアをぶっ壊しかねないので果たして公開してよいものかどうかちょっと悩ましい面もあります。

で。これだけ苦労して書き出した16000pixel幅のデータですが。。理屈でもそうなのですが12000pixel幅と較べて解像度は決して高くないです。photoshopで目伸ばししたものと後で比較してみたいと思いますが、大して差がないならphotoshopでやってしまった方が遥かに実際的という事になるかと思います。
とりあえずは達成のご報告まで。

16000pixelにチャレンジ中

いつまでも絵に描いた餅にし続けていても仕方がないので、いま16000pixel幅のVRの書き出しに実RAM1GBの環境でチャレンジしています。
半分は無事に終了したので、方法としては間違っていない事が確認できました。 最終的な結果が出るのは明日の朝くらいだと思いますが、まぁ問題ないと思います。この方法が正しい事が実地で検証されれば後は細かいチューニングで30000pixel程度まではいけるはずです。(かなり細かいチューニングが必要と思いますが)

ただ16000pixelでも既に元画像のデータ解像度を超えて「目伸ばし」状態になってしまうので果たして600万画素クラスのDSLRでそれ以上のサイズのものを書き出す事に意味があるのか。。。
まぁその辺の検証の意味も込めて今書き出しているわけです。単純にphotoshopなどで補完して拡大しているわけではないから意外と持つのかもしれないし。。その辺りはまだ一度も完成したものがないのだから未知数としか言えません。明日の夕方にはその辺りの事もある程度把握できるでしょう。

VRの適正サイズについて

まず。これはローカルに限っての話であってwebに上げてナローバンドも含めてアクセスする事などは考慮しないで考えた場合の事であるとお断りしておく。

以前桜の風景をVRに書き出したときにそのディテールとファイルサイズのバランスから幅4000pixelがいい頃合いと判断したけれども、ギャラリーの展示の場合は4000pixelと8000pixelと、二つのサイズの元画像から書き出したものを比較すると断然8000pixelのものの方がいい。というか。4000pixelからのものはディテールが見えなくてイライラする。

(続きを読む…)

VRでのプレゼンテーションの意外な。。?盲点

意外という事もないんだけど今まで全然気にしていませんでした。
この間会場のofficeのAptivaかなにかで開こうとしたときに、ディスクはマウントできたんですがファイルを開こうとしていきなりフリーズして仕方なくうちのぱわぶーで披露したのですが。今になってその理由を考えると、懸念としてですが、このサイズのVRを展開するためにはそもそもクライアントPCのメモリー空間が相当大きく確保されていないとまずいのではないか。。という問題があがってきています。

Winノートとかだと256MBとかそれくらいしか積んでいないと思われるので、その辺りの事も考慮に入れる必要があるのかもしれません。
。。でもどうやってテストすればいいのだろう? んーむ。

光ディスクドライブの読み出し速度は十分に高速化されていて問題ないレベルにまで達しているようです。

こんな低レベルな事でつまづいていて全くお恥ずかしい。。。

難しい。。

表現として考えるなら、エクスペリエンスの固定。。というかズーミングなどはさせない方がいい。そのかわりどのアスペクトレシオでどの視野角で見せるかを吟味しなければ意味が無い。
インタラクティビティ(死語)を重視するならぐりぐり動いた方がいい。

仕事であれば自分の表現に走ることは許されない?けど全く無味乾燥なものを求められるのなら自分に依頼が来る理由が無い。そんな仕事ならやめた方がいいだろう。
代理表現。。とでも言えばいいのだろうか。まぁそのためのツールの一つにしか過ぎない。

ギャラリーで撮ったVRを書き出したものを見ている

目の前に鎮座しているeMacのモニタには幅12000pixelで書き出したVRの元画像(合成した直後のpsdファイル)が展開されている。 当然全体を一覧はできないのだが今目の前に表示されている一部分がおおむね2:3のアスペクトレシオで考ると1800万画素のDSLRで撮影した画像に匹敵するデータ解像度がある。
正直なところ。もう見なれたのであまり感激はしないが確かにこれくらいデータ量があると見応えはある。如何せん元画像がうちのなまくらな*istDで撮影した600万画素のjpegなのであまり解像感が無いが、これでもしもpro14nとかで撮ったら凄いかなぁ。。とか思う面もある。

これくらいの解像度でVRに書き出せば気持ちいいと思うけど、このデータ量だとCD-Rでも読み出し速度的にきついのでHDDにデータ保存をすることが前提になるだろう。そうすると当然ディストリビューションを前提にしたビジネスには不向き。
んーむ。 売りにくいなぁ。。(笑)

(続きを読む…)

ControlPointの打ち方について

いつもよりも慎重に打ったことと、比較的絵柄が単純。。というか変なたとえだがjpegにするとファイルサイズが小さくて済むタイプの絵柄(つまり単純なグラデーションの面積が大きい)である事もあって、一発で十分なoptimizerの結果が出た。
AverageCotrolPointDistanceが約1.2pixel。最大値で3.1pixel。これなら下手にいじる必要はないのでそのままパノラマの書き出しに移行。 一応の経験値。。というか俺ルールとしてアベレージで2.0pixel以下(気分的には1.8pixel以下)になるまではoptimizerとCotrolPointの修正を繰り返す事にしている。

ControlPointは闇雲に打てばいいという事ではなく一応の原則はある。
秘密にしておきたい部分もあるけど少し書いてみたい。(もちろん書いたところでその通りにはなかなかできないと思うし、できるヒトは俺が書かないでも自分で工夫して同じ結論に達するはず)

(続きを読む…)

トラブル解決

再チャレンジの結果。また同じところでこけたので今度はリソースフォークを削除してトライしてみた。(いままでphotoshopで保存したそのまんまのjpegを読ませたことが無かったため) しかし結果は同じ。
optimizerを走らせるということはすなわちPTMacではなくPanoToolがファイルにアクセスするということ。はたと手を打ってファイルパスに含まれる2バイト文字を削除したところ正常に作動した。
というか。。 すっかり忘れていたけど既知の事項だった。(笑)ちょうど一年ほど前に何の資料も無くこのアプリケーションを触りはじめた頃に一番最初につまずいたのがこの問題だった。
忘却力の強化は順調に行なわれている。(謎)