PTMacで流れてくるヒトがいまだに多いのだけど、IntelMacないしはWindowsのマシンで使うならば、PTguiの方が全然速くて高機能なのでそちらを勧めます。にのみやさん[Link]が日本語マニュアル（まちょっと）の整備に取りかかっていらっしゃるようですし．．．と他力モードで。PPC MacだとPTMacしか適当なアプリがないんだけど、俺の知る限りではPTMacでマージした元画像をQTVRに書き出すためにはQuicktimeVR Authoring StudioとQuicktime Make Panorama2 が最低限必要でこれらはOS9.xまでしか動かないのでOS9起動できるMacintoshかClasic環境が必要だし、もはやApple自身が半分これらのツールのサポートを投げている始末なのでいまから始めるヒトがこれにこだわる理由はまったくないだろう。

APS-Cサイズの素子を持つDSLRに適用した場合最短焦点距離の10ミリにおいて対角線画角180度をカバーする対角線魚眼レンズとして機能し、ズーミングする事で魚眼レンズ独特の歪曲を残したままより高い倍率（望遠寄り）の画角に変移する。
どちらかというとパノラマコミュニティ向けのネタレンズ（笑）だけど LensFix & Panorama Tools Plugin にこのレンズのパラメータが収録されるようになればPhotoshopで歪曲と色収差が補正可能になるので、周辺の描写に厳しい要求がある場合の超広角までカバーするズームとしてSIGMAの12-24の強力なライバルになる事はまず間違いないだろう。

旧来の魚眼ズームはKマウントオンリーだったので使いたい場合はペンタのボディを買うしかなかったけど今回の新レンズはトキナーとの共同開発/生産らしいことから他のメーカーのマウントのモデルも登場するのではないかというような噂がささやかれているけれども、もし実現すればあるいは12-24クラスのズームレンズを建築の分野からは駆逐するかも。

先日まで缶詰めになっていたところの思い出深い、某「初台の大箱」のバックヤードのたこ部屋のVRです。（笑）
ADSL以上の高速回線の方は高画質バージョン(4.9MB)でご覧下さい。
低速回線の方は高圧縮バージョン(480KB)が無難です。

出展されている作品数がとんでもなく多かったことと巡回展ということで搬入にかかるパッケージや予備部品まで持ち込まれているためにバックヤードがパニックだったのですが、あまりにパニックだったために普段の部屋ではなく別の部屋があてがわれていたのでかなりきれいに写ってはいます。ほんとはもう少し悲惨なことになっているはずなのですが。
まぁでもどんなギャラリーでもコンベンションでもあるいはホテルのバックヤードでもだいたいこんなもんです。

基本的にここでは機械製品も単なる一台分の部品セットでしかなくMacとかも装置に組み込むために基板単位に分解されて特製のケーシングに入れることは日常茶飯事。熱のために起動しなくなったHDDを分解してサーボ回転に達するだけの駆動力が無くなったモーターを指で回して「行け！行くんだ」。。とかいいながらデータを吸い出したりとか。
まぁそんなもんでしょう。機械なんて。（謎）

残り100shot強まで来てるのであと二時間以内には画像化は完了する見込みでその後はVRで撮影した分の処理でPTMac/ PhotoshopCSの世界。せっかくCS2にしたしPTMacも16bitでの処理に対応しているので16bitでやってもいいのだけれども、eMacの実RAM1024MBの壁があるので大サイズのパノラマを処理する時には16bitだと二回に分けて出力しなければならない。（というような気がする）大した手間ではないのだけれども実際問題Photoshopに移してからあとに16bitの優位性が高いような作業をするわけでもないので8bitでもいいのかな。。とかいろいろ考えている。まぁ最高画質を目指すならQTVRmakePanorama2の直前まで（リサイズまで）16bitで行くにこした事はないのだけれども。

可能な範囲をすべて16bitで処理してさらにリサイズの前にガウスをかけてから縮小。。という山田さんのところで話題になっていたtipsをも利用した場合にどれくらい結果が向上するか。。という事はいずれ検証しなければならないと思っている。VRの見え方自体はタイルイメージデータからオンサイト？でQuicktimePlayerが生成しているものだと思うのでそこにシャープをかける事はできないから如何にしてそこまで「ボケのない劣化の少ないpixelデータ」を渡すかということにかかっているわけだから。

でもそれでは例えば塀の上からの視角とかそういう捉え方ができないんで理想をいえば、フツーの上面にある目盛りのほかに雲台の回転部側に角度目盛りを切って、三脚に固定するベース側にフリー回転できるリングをつけてそこに指標を刻んでおけば、手の届く範囲の高さであれば頭よりも高いところからVR撮影ができることになります。
まぁ。。フツーの三脚の雲台座に自分で目盛りを描いてもいいんですがあまりカッコヨクはないのでそういうものをどこかで製品化してくれないかと思ってます。
よろしく。（謎）

出先ですし写真もないんで口で説明しますけど、俺の使ってるのはベルボンのマクロスライダーとストロボをバイカメラマウント刷るためのL型のステーです。（笑）要はカメラを縦位置に保持したまま三脚座とモーダルポイントの間のX軸Y軸のオフセットをシフトできさえすれば何でもいいんです。それで最低限の支持剛性があれば。
マクロスライダーは高校一年のときに買った骨董品ですし、Lブラケットも部屋の隅に転がっていたスクラップから剥がしたもんです。その程度のものでもまぁ理屈さえ理解していれば何とかなるもんです。もう少しきちんとできたそれなりの機材が欲しいのも事実なんですがね。特にマクロスライダーが重すぎるし。

元気があったらそのうち写真付きで紹介しようかと思います。

今まではパノラマを撮影する日には古いタムロンの17ミリ（アダプトールマウントの奴）を持ち出していたけど、シグマのこのズームがなんとかうちのパノラマ機材のシフト幅で間に合う事に気がついたのでこちらに移行しようとしている次第。もともと建築などで超広角の画角が求められるときのためのレンズなので、これに加えて水準器とパノラマ用の機材をカメラバッグに追加して持っていくだけでビューカメラでも撮れないような広角やパノラマが撮れるようになればまさに渡りに船。果たしてうまく行きますかどうか。

コントロールポイントが打てない例として「空」とか「海」があるけど、この辺りはもうどうしようもないので空の場合であれば雲が動かないうちにババッと全周を撮りきってしまうしか無い。函館山の奴はその方法で撮ってピッチを補正パラメータに含まないようなセッティングにして下半分だけのコントロールポイントを使って処理しています。山の稜線とかは使っているけど。海は。。もうどうしようもないだろうと思います。撮ったこと無いですけど。もしも砂浜などが手前に無いのであれば専用ヘッドを使って正確な角度で撮っていき数値入力で合成するか、あるいはプレビュー画面で数値を手入力しながらつながり具合を見て適正値を割り出していくか。。の二択になります。波は絶対に動くので。

2004年の6/30日に断定バーで行なわれた名和晃平によるLiveDrawingの記録のVRです。
ADSL以上の高速回線の方は高画質バージョン(10MB)でご覧下さい。
低速回線の方は高圧縮バージョン(729KB)が無難です。

このときは全然VR撮るつもりなしで行って突然やったので、水準器もなく撮影もISO1600設定で撮っているんでちょっと画質が荒く、ノイズが多いことが原因でデータサイズも大きくなってしまっています。（VRの圧縮方式にPhoto-JPEG圧縮を選択しているためだと思う）

しばらく前から Vertical Panoramic Photo 。。というか要するに水平パンではなく垂直パンのパノラマが撮りたいと思っており、そのためにはノーダルポイントを水平軸に載せてパンできる機材が必要。。ということでマンフロにはないしカイダンの奴は高すぎるし。。と逡巡していた次第。そこへ持って来てコレを見て興味津々というわけ。

分解してコンパクトに収納できる点と必要以上のデタントなどがなさそうなのはいいかもしれない。逆にLプレートが折畳式ではなくて組み立て式なのはどうかとも思うけど。
Vertical Panoramic が撮れるようになれば撮影位置を確保できれば4×5でも撮れないような歪みのない高層ビルの写真とかが撮れるようになるし、同様にとんでもなく横長で一望できないような構造物も撮れるようになるのでインダストリアルや建築の分野で仕事するヒトにとってはそれなり以上の意味があるはず。

パノラマ技法の応用はこのサイトでもちらっと触れられているようにデジタルカメラとPCの組み合わせが普及してフィルム時代に較べて格段に進歩した。バブルの頃だったらうちのeMacで処理しているくらいの演算をやるために一晩のリース料が100万円。。とかそういうマシンが必要だったけどいまはホントにちょろいマシンでも（メモリさえ積めば）何とかなるし撮影からデジタルだからスキャンフィーも要らなければ時間も取られない。
ビジネスとして考えた場合には実は問題もあって、それは端的に言うと、「パノラマ技法を使えば簡単に撮れる被写体/表現」=「通常の写真技法では絶対不可能な被写体/表現」なのでそれを客先が求めていたとしても写真屋には発注が来ない。。っていうこと。（笑）てーか、まず相談も来ない。
オンラインで公開されているQuicktimeVRは回線速度の問題もありあまり高解像のデータのものがないからそれを目にした人たちはVR技術っていうのはあまり細かいところまでは表現できないweb向けに限定した技術なんだ。。という風に先入観を持ってしまってキワモノ扱いになってしまっているという側面もあると思う。まぁ実際にグリグリ回してみるのは紙媒体とかでは不可能でPC前提ではあるけど、それにしたって回線速度も上がっているから、PCの能力をある程度要求はするけど元画像のサイズで言って16000から24000pixel幅とかそれぐらいのものから書き出せば訴求力のある表現は充分にできるはず。

まぁ「啓蒙」というつもりは更々ないんだけど、そういう意味でともかくまずQuicktimeVRとかパノラマ技法とかそういうものを知ってもらおうと思ってこのweblogでも何回か紹介しましたし、コレからも継続していろいろなところを撮って行こうと思っています。
併せて、先に述べたようにまずは「写真屋に頼めばこういうものが撮れる」っていうことを客先も含め多くのヒトに知ってもらわないとビジネスとして成立しないんで、より多くの写真屋がこの技術をある程度習得することが肝要と思っています。もしも興味のある方がいらっしゃれば基本的な撮り方やソフトウェアの使い方は俺の出来得る範囲でよければ教えることは出来るので、コンタクトしてみて下さい。
俺自身もコレに手を染めたのはとある必要があって検索して調べ泥縄でものにしたに過ぎず、その後あまり突き詰めていないのであまり上手ではないですがとりあえず始めるのにどの程度の道具でどこを押さえればいいかとかそういうことはむしろ本格派でない分把握しているかもしれません。（謎）

まぁ。よろしければ遠慮なく。

例によってより大きなデータは下のリンクに置いてあります。
ADSL以上の高速回線の方は幅12000pixelのパノラマ画像を元にした高画質バージョン(5.3MB)がヨサゲだと思われます。
ISDNやモデムなどの方は幅3000pixelのパノラマ画像を元により圧縮率を高くした高圧縮バージョン(436KB)のほうが軽いので無難でしょう。
前回のBarHBの奴と同じ圧縮設定なんですがなぜかサイズが倍近くなってますので気合いがはいると思います。（謎）まじめな話。回線速度だけの問題ではなくてメモリが少ない環境とかだとシステムが不安定になるなどの障害が出るかもしれません。ご注意ください。（正直不安です。。）

例によってQuicktimeの説明ですが、操作はムービー上にポインタを持って来てプレスダウン(マウスをクリックしてそのままホールド)したままで視線を移動したい方向にマウスを動かして下さい。（少しでいいです）controlキーを押すとズームアウトし、shiftキーでズームインします。

半島部の真ん中に見えるひときわ巨大なレンガ色の真四角のビルディングが函館市役所なんですが。このビル、取材に行ったときは正面の函館駅（左側プラットフォームの屋根が複数あるところ）から歩いても至近でさすがに便利な場所にある。。と感心したんですけどいまこうやってみると背中にしょっている反対側の海岸のほうが近いんですね。（笑）さすがに一番近いところで海と海の間が900メートルしかないというだけのことはあります。
取材班が宿泊したホテルもしっかり判別できて当事者としては結構感慨深いものがあります。

インターフェースがずいぶん変わっているために普段いじらない設定項目もいろいろ操作しているので気分的には二年ほど前に最初にいじった頃に近い感動（というか苦闘？）がある。
せっかくなので以下覚え書き。

• コントロールポイントが飛び跳ねる問題はPrefの壊れた結果らしい。捨てて再起動すると戻ると思う。原因はコントロールポイントを打ったあとでソートオーダーを変更したりソースイメージを変更したりしてパラメータの関連付けがおかしくなるような操作をしたことによる。
• Optimaizerを走らせた結果イメージがとてつもなく変形して場合によっては逆立ちしてしまうような場合にはFOVの換算がむちゃくちゃになっていることが多い。Focal Lengthの設定をチェックすべし。
• Ver3.0ではプレビューも最終書出しパノラマと同じサイズで行なわれるようになったので少し時間がかかる。処理自体が高速化しているのでまぁ決定的な不都合はないけど善し悪しではある。プレビューの精度は上がっているので相殺というところか。
  うそでした。いままでのインターフェースは廃止されてかわりにスライダーでプレビューの大きさを設定するようになっています。これなら納得。

ひとまず。

より大きなデータは下のリンクに置いてあります。
ADSL以上の高速回線の方は幅12000pixelのパノラマ画像を元にした高画質バージョン(3.6MB)がヨサゲだと思われます。
ISDNやモデムなどの方は幅3000pixelのパノラマ画像を元により圧縮率を高くした高圧縮バージョン(308KB)のほうが軽いので無難でしょう

QuicktimePlayerの操作はムービー上にポインタを持って来てプレスダウンしたままで視線を移動したい方向にマウスを動かして下さい。（少しでいいです）controlキーを押すとズームアウトし、shiftキーでズームインします。

屋外風景のように上半分（水平線より上）にコントロールポイントを打つことができる標的が少ないパノラマ撮影では、場合によりoptimizerを走らせるとpitch（カメラの前後への傾きのパラメータ）が大きく変化するような補正がかかってしまい、撮影時に水平を取っているにもかかわらず画面が大きく波打ってしまうことがある。これを防ぐにはあらかじめPanoramaEditerでSourceFileを開きpitchを補正して水平線を一致させておいてから、Optimizerを走らせる時にpitchの補正を行なわない設定にしておく。（pitchを保持する）
そうすると。大きく波打った変なパノラマができるのを回避できる。

撮影時にどんなに正確にモーダルポイントを設定してカメラの水平垂直に気を配ったとしてもこれを知らないとPanotool系のアプリではこの現象を回避できないので一応まめ知識として書いておく。

撮影種目としてはわりと要求頻度が高そうなものではあるからきちんとデータを持っておいた方がよさそうだ。今度やってみよう。

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

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

この画像を元画像として使いPTMacで処理して魚眼特有の歪みと水平垂直の傾き、垂直方向のパースペクティブを修正したのが下の画像です。

水平垂直のパースの殺し方についてはPTMacの公式サイトにチュートリアルがあるのでそれを読めば（英語ですが。。）大体理解できると思います。
この方法の難点はホントにパースペクティブ0のド平行に補正されてしまうことでしょうか。。

このイカトンビみたいな出力画像そのままを使うのはさすがにフツーはあり得ないので周辺をトリミングします。

トリミングするとだいぶ横長になってしまいます。。
実際問題としてこの程度の元画像のパースだと普通の広角レンズで撮影しても許容範囲といえばそれまでなので作例としてあげるにはあまり適当なものではないです。（笑） あと、ホントにド平行なので逆に違和感があると思います。4×5″で建築を撮る場合にもあえて若干のパースを残した方が出来上がりとして自然に見えるので水準器で完全な垂直にはあわせないのが一つのこつというくらいですから、このままの出力ファイルを使うのではなく、LensefixないしはPhotoshop自体の変形機能を使って若干のパースがついて見えるように修正する方がいいでしょう。

魚眼画像からの変形/補正はPTMacがなくともLensfix単体をPhotoshopのプラグインとしてインストールすれば行なえるのでVR向けの360度画像の生成などに興味がなければLensfixのみを手に入れればいいとおもいます。Phopshopプラグイン互換のアプリならPhotoshop以外でも動くようです。（たとえばGraphicConverterなど）
注意すべきはPTMac/LensfixともにKekusDigitalのパッケージは2バイト言語環境のシステムではLibrary間でのパスが通らずにうまく動作しないことがあります。 そのようなトラブルに遭遇したら、アプリはReadmeに書いてある順番でlibraryを探すのでその中でどこか2バイト文字が含まれないパスが通る場所を探してインストールする必要があります。具体的には日本語システムだとインストールマニュアルに指定されている
Applications/Adobe Photoshop/Plug-Ins/Adobe Photoshop Only/Filters/ というディレクトリの"Plug-Ins"の部分が"プラグイン"になっていたりします。
ここにプラグインを置くとPhotoshopには読み込まれるし一見動作はしているように見えるのですがPanoTools Libraryまでのパスが通らないために実際には処理できないようです。自分の環境では推奨されているApplications/Adobe Photoshop/Plug-Ins/Adobe Photoshop Only以下のディレクトリではなくApplications/Adobe Photoshop/Plug-InsにLensfixを含むPanotoolsPluginを置く事で動作するようになりました。
（日本語MacOSXではファインダーの当てるラベルがこの種の2バイト文字を考慮していないツールのインストールの障害になる事がままあります。）

PTMacによる出力とPTMacを使わずPhotoshopとPanotoolsPluginによる出力で一番違うのは、PTMacの方だと水平ないしは垂直が完全に補正された出力以外は決して吐かれない。。ということでしょう。翻っていえば水平垂直がかなりいい加減な手持ち撮影の画像からでも完璧な平行をとった絵を吐く事ができます。（もちろん水平垂直共に完璧に補正する事も楽勝です。この事は別の応用の可能性も示していますが。。）
Photoshop+PanotoolsPluginの機能だとPhotoshop本来のGUI操作系アプリとしての得失をPanotoolの自動演算系の特性が補完してかなり使い易いものになります。PhotoshopのGUIによるマニュピレート系だと微妙な調整のときにむしろ悩んでしまう事もあり得ますし、単純な光学的パースや軸の傾きを補正するために使うためのものとして評価すれば、操作部が多すぎますし動作も重いと言わざるを得ないでしょう。そこでPanotoolの機能を利用すれば単純な補正で「変形」のお世話になる必要もなく、パラメータを変えて何回か吐いてみればいいだけの事ですからだいぶ楽です。
あと。Lensfixの、変形以外の目玉機能として倍率色収差の除去（ま。ちょっとね）があります。
これについてもいずれまたちゃんと書いてみたい。。（いつの事やら）

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

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

改良点は先のポストで書きましたが、実際に使ってみてもかなり処理が軽くなっているのが判ります。
実RAM1GBのうちの環境で、特に何の工夫もなく16000pixel幅の書き出しが可能になりました。20000pixelはさすがに無理でしたが、前回使った方法との併用で30000pixelまでは行けそうです。（えらい時間を食うことが判っているので試してませんが。。。）100ppiで使うと2×8m弱の大きさ。。

たぶんオーバースペックですね。これ以上は。

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

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

QuicktimeVRAuthoringStudioが発表される以前の開発段階においてはQTVRMakePanorama2を使ってパノラマ生成するのが唯一の手段であったらしいのだけれども、QTVRMakePanorama2の正体はハイパーカードスタックであるらしい。
で。ハイパーカードの枠組みの中で大きな画像を扱うため。。ということと、とてつもなく長いフォーマットを扱うために元画像の長さ方向を（つまりパノラマの水平方向を）画面のスクロール方向に合わせるようにしたために、そこでステッチの段階で横倒しになったりステッチした後で横倒しにしたりするようになったのではないか。

この話には疑問もある。別にAppleがパノラマVR技術そのものを開発したわけでもないと思われるし、それ以前からUNIXワークステーションで演算処理して作成した例はあったと考えるのが自然だからだ。とすると、ハイパーカード云々ではなくて以前から存在するプラットフォームでその横倒しに関する仕様は決定されていたはずでAppleがそれをハイパーカードに置き換えたと考えるの自然だろう。
まぁいずれにせよ横倒しにした方がスクロールの方向にマッチするという考え自体は何となく納得はできるのではないかと思う。

あくまでもわたしの直感なので間違っている可能性も高いです。念のため。

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

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

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

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

記録する対象がどの程度のディテールを要求するかによって、書き出しサイズをどこまで引き上げればいいかは当然変化してくる。それに先に書いたようなハードウェア／システム上の制約も加味して適正サイズを決定する必要があるだろう。
8000pixelのVRを開いている状態でQuicktimePlayerが確保しているメモリサイズは約88MBであるらしい。（アクティビティモニタの表示値） OSX上では主に仮想メモリ上に展開されているように見える。（他には仮想メモリを消費するプロセスが稼働中ではない状態でほぼ同じ仮想メモリ空間が固定されている事からの推測）
今これを書いているぱわぶーはOS10.3.4で実メモリ1GBの環境だけれども、仮想メモリは4.82GB確保されている。領域はOSとは別に6.5GB弱の別パーテーションを指定している。

細々小技は習得しているのでやる気になればこの環境でも30000pixel幅くらいはいける自信がついてきているんだけど、ファイルサイズが5-6倍になると思うので、そんなものを出す事にはほとんど意味がない。 もしもそれが求められる用途が存在するとしたらビルボードのようなものを作るときくらいだろうか。
巨大出力用のファイルは100ppiもあればよいとすれば40×150インチの出力と考えておおむね16000pixel幅。実メモリが4GB搭載できる環境なら何の工夫もなく出力できるサイズだけれどもやはりこの辺りが一つの目標点か。。

んーむ。なんか前に書いたときとほとんど代わり映えのしない結論に達しているところが歯がゆい。
自分的にはほとんどその目標に手が掛かりかけてはいるわけで進歩はしているんだけど。

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

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

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

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

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

とはいえ。エンターテイメントではなくテレプレゼンス（笑）。。というかバーチャルショールーム的な使い方ならCD-RでもあるいはDVD-Rでも行けるという気もする。その辺のHTMLのコーディングも含めてやっていけば何かしら面白いものもできるかもしれない。
そういえばIMAもテクニカルな面ではこれに類することをやっていたわけだし。（残念なことにビュアーはともかく課金系の面でうまく動作せずにつまづいてしまったようだけど）

課金の問題さえクリアすれば結構今の技術でも表現力自体は十分という面は確かにある。極端なはなしWinnyのような環境にのせてしまえばサーバの負荷すら問題にならないし。
あれだって某所でいわれているように「検閲不可能なメディアの登場を喜ばしからぬこととする勢力」以外にとっては、正当な環境の進化な訳だし。要は課金の問題でしょう。CCCDにしろなんにしろ。
個人的には。コピーしてまでも手に入れたくなるくらいのものを発表してからコピープロテクトをかけろ。。という気がする。 パブリシティに何千万も投入しなければ売れないようなものばかり商品化しているからコピープロテクトをかける必要があるのであって、本当にいいものならばコピーで試聴してからでもちゃんと正規のディストリビューションを買うよ。まともな神経なら。

あぁ。また暴言を。。。
スマソ