してログ

ボール紙のような厚紙にインクジェットプリンタで印刷したくて、ネットで調べてみたのですが確証が得られず、いろいろと試行錯誤をしました。 印刷できるかどうかは、厚さの問題と、インクの定着具合の二点をクリアーする必要があります。 このうち、厚さについて Canon製プリンタは個別の仕様に記載が無く、Q&Aの中で「インクジェットプリンタで使用できる普通紙の坪量」に記載があるのみです。 ただし、坪量(重さ)の単位なので実際何mm程度までなのかはっきりしません。 この点、エプソン製プリンタでは仕様に厚さ(mm)での記載があり、EP-978A3 などは 0.6mm のかなり厚めの用紙も大丈夫なようです。 なので、このためにプリンタを用意できるのなら、エプソン製プリンタで仕様を確認して購入するのが良いと思います。

残念ながら、私の所有しているのは Canon iX6530 というプリンタですのでやってみないと分かりません。 背面の手差し給紙しか無い機種なので、割と厚めのボール紙でもいけるだろうとは思いましたが、結果 350g/m2 ぐらいまでが限界のようです。 それより厚い 400g/m2 は印刷可能ではあるものの、スタックして給紙させると稀に紙詰まりになることがありました(1枚ずつ手作業で給紙させれば詰まらない)。 従って複数枚の厚さから逆算すると、約 0.4~0.5mm 程度までが、このプリンタで印刷可能な限界値だと思われます。

インクの定着については、残念ながらインクジェット用のボール紙は無く、特に光沢のあるタイプはまったく向きません。 どのボール紙でもインクが乾くのが遅く、乾いた後でも擦ればインクが伸びて汚れてしまいますが、光沢の無いタイプは割とマシだと思います。 いずれにしても、定着や発色の悪さ、退色の心配がありますので、フィキサチフなどを塗布した方が良いかも知れません。

それと給紙位置ですが、紙が厚くなっていくと少しずつズレてくるようです。 試したプリンタでは、3mm 程度印刷開始位置が早くなりました。 同じ紙であれば一定のようでしたので、元のデータを微調整して対応しました。


インターステラー

前知識なしで鑑賞しましたが、近年にしては珍しい「2001年宇宙の旅」のようなハードSF作品でした。 この手の作品が好きなので2時間半という長編作品でも、最後までどっぷりその世界観に浸ることができました。 地球の終焉を救うミッションに旅立つ父親と、それを理解できずにすれ違い空いた娘との溝、それを天文学的な距離と相対論的な時間の遅れが容赦なく引き裂いていきます。 果たして、地球の危機を救うことができるのか、娘との再会の約束は守れるのか、超大な宇宙のスケールの中で描かれる人間ドラマの結末は...。

天文学や物理学に基づいた映像表現

後で調べた情報によると、理論物理学者の協力でブラックホール等の映像は、物理計算によって作られているそうです。 本編中でもブラックホールや宇宙空間での無音表現などの天文知識、ワームホールといった実際に研究されている理論などを基に丁寧に作られているなと感じられました。 そういった光る点がある一方、残念な部分も少なからずあり、一流のハードSFかというと自分の中では多少落ちるかなという印象です。 他のレビューでは絶賛の声が多いので、ここではあえて変だなと思った点を書いていきます。 とはいっても、SF映画として大変面白かったので、些細な事だと思います。

地球存亡の危機なのに切迫感が無い

これはきちんと設定して欲しかったと思います。 物語上では、食糧危機の発生としか分からない地球存亡の危機ですが、どのような理由で発生してどういう状況に置かれているのかが語られていません。 また、どうしてそれを救うミッションへ父親が参加しなければならないのかも適当にされています。 正直に言うと、地下組織化したNASAに潜入して、あのロボットが出てきた時点で「あ~あ、B級SFかよ」って思ったくらいです。 ご都合主義的なチープなSFが展開されるのかと思って冒頭部分を観ていたので、見終わってから損したなと思いました。 ここら辺が丁寧に描かれていれば、最初から作品の世界に引き込まれていったのに、とても残念です。

地球からは多段ロケット、他の星からはあれれ?

地球からの打ち上げは、多段式ロケットを使って軌道上の宇宙船まで向かいます。 しかし、移住先の惑星からは着陸船だけで軌道上の宇宙船まで上昇できてしまいます。 大気も無く重力も1/6の月とは違い、訪れた惑星は大気もあり1Gに近いように見えますので、そうであれば多段式ロケットの推力が必要なはずです。 もし、あの着陸船だけでそれができるのだったら、なぜ地球から離脱するときも使わないのでしょうか?

土星を見せたいだけのご都合設定

まあ、ワームホール自体が理論的予測に過ぎないので、どう描いてもいい対象ではあるのですが、もう少しうまく描いて欲しかった。 私だったら太陽系外か外縁部に置いて、土星はスイングバイの中継点として使いますね。 というか、SF作品で他の惑星に行くための軌道をまともに描いたものが皆無です。 たいてい直線的に向かっているように描かれていますが、本来であればスイングバイなどを使って軌道旋回速度を増すことで外惑星に向かうように描かなければ変です。

ワームホール先の探査ミッションがあり得ない

クーパーのミッションの前に、ワームホールを使った人類移住先を探す複数のミッションがあったという設定なのですが、クーパーらは地球の科学技術に毛が生えた程度の技術で恒星系を渡り歩いているように見えます。 いったん土星に戻って、ワームホールを使うような描写も見られないから、向こうで別の恒星系に移動するのに地球のテクノロジーしか無い訳です。 もし、恒星間航行が可能なテクノロジーがあるのならワームホールは要らないことになります。 ブラックホールを軌道旋回する複数の恒星系があるとか、恒星サイズのブラックホールとの連星系の中の惑星だったとか、理解しようとしましたが無理でした。

移住先惑星での津波が唐突過ぎる

あの津波はどういう理由で発生したのでしょうか? あまりにも唐突過ぎて説明も何もなく、科学考証をウリにしているなら無くてよいシーンでした。 百歩譲って巨大津波があったとしても、あれだけの高さの津波が押し寄せてくるのであれば、強力な引き波が発生するはずです。 降り立った水深20cmしかない大海原も違和感ありまくりですが、そんな水深しか無いなら海底が露出するほどの表現が無ければ変です。

ブラックホールは必要だったか

物語上ブラックホールの必要性がありません。 そもそも移住可能な惑星を探すのであれば、ブラックホールのような未知の恒星系は避けるはずです。 ワームホールを維持するのにブラックホールが必要で、そこしか行けないというような必然性が必要でした。 ただ、物理計算によるブラックホールのイメージを見せたいだけだったのでしょう。

それと、ブラックホールを直接軌道旋回する複数の惑星が探査対象だったのでしょうか? ブラックホールの影響があるのは最初の水の惑星だけ、というような表現だったと思いますし、そうであればどの惑星もブラックホールの影響下にあるはずなので辻褄が合いません。 ここら辺の世界観が想像できないのが最も残念な点であり、タイトルにインターステラーと付けるくらいですから、丁寧に描いて欲しかったです。

強い重力場での時間の遅れ

最初の惑星はブラックホールの影響下にあり、時間の流れが遅くなるということです。 おかしいのは、その惑星の軌道上の宇宙船と着陸船の間でそれが顕著に表れるということです。 どちらもブラックホールの影響下にあるはずなので、時間の遅れはその惑星の重力による影響しか差が無いはずです。 どうせ描くのだったら、終盤のブラックホールを使った重力ターンのところで、この軌道を取ると時間のずれが何万年にもなり今生の別れになる、みたいなスケールでお願いしたかったです。

プランAとB、重力理論の関係が良くわからない

現在の地球人を移民させるプランA、遺伝情報を使って文明再生をさせるプランB、プランAは重力理論の解決が絡んでたような話だったと思うが忘れてしまった。 探査前にはプランAとBが計画され、元々プランBしか実現性が無いと分かっており、プランAは重力理論の解が不可能だと分かってて他の人類に希望を持たせるだけに計画された、というような内容だったと思います。 後に高次元空間から届いたブラックホールの特異点の観測データを使って、重力理論の別解が分かりプランAが実行可能だと判明した、と無理やり理解しましたがどうでしょう。

あと、最後のシーンに出てくるスペースコロニーは、あれ何なんでしょうね。 移民船には見えなくて、コロニーで解決するんだったら、重力理論の下りもいらないように思うし、移民計画も必要無さそうに思うのです。 それに、クーパーにアメリアの元に行くように言うということは、あれは移民船で無いと言うことだと思います。 うーん。 整理すると、プランAは重力理論の解決が障害だったけど、それを解決しときながらコロニーを建設して太陽系に留まることにした、クーパーはアメリアと合流してプランBを実行するようにした、というのが結末という理解で良いのでしょうか。 ちょっとすっきりしませんね。

取って付けたような人間ドラマ

基本的な主軸は、父と娘の絆の物語であるのは良いのですが、そうであれば最後にアメリアの元へという部分は要らないと思います。 そもそもアメリアとクーパー(父)がロマンスがあったのか無かったのかも分からないくらい、印象に残った絡みがありませんでした。 もし描くのなら、父と娘が相対論的時間に引き裂かれるのに対し、アメリアとは天文学的な距離で引き裂かれる、とかにしたら面白かったでしょう。 まあ、マーフと再会したところでジ・エンドというのが綺麗だったと思います。

チープなロボット

キャラクターとしては魅力あると思いますが、ターズやケースといったロボットがB級SFっぽさを出しています。 ゴールドライタンのような箱、中に人が入ってるような動き、不器用で実用性が無さそうな腕、チープなディスプレイ、どうしてこうなったんでしょう。 AI的なコンピュータは出てきてもいいですが、動かなくていいと思います。

ワームホールと異次元人

どういう理由でワームホールが出来たのか、まったく説明が無かったと思います。 すべての設定を説明しなくても良いとは思いますが、物語の根幹部分については何らかの説明は付けて欲しかったです。 ワープ中に接触してきたのが異次元人だと思ってたら、結局クーパー自信だったし、高次元空間のシーンでも異次元人の存在を匂わせて無かったと思います。 あと、マーフの部屋の超常現象はクーパーの仕業だったまでは良くて、異次元人=クーパーだったというのは上手いなと思いました。 そうだとすると、余計ワームホールを作ったのは誰か、クーパーを戻したのは誰か、気になってしまいます。 やはり異次元人はいて、我々とはコミュニケーションを取ることが出来なかったのだと解釈しておくことにします。

総合評価:★★★★☆

このレビューはあえてダメな点を書くという趣向ですので酷評しているように見えますが、総合評価は納得の高得点です。 久しぶりに重厚なSF映画を観させていただきました、ありがとうございます、というのが感想です。 ちょっと長いのですぐは無理ですが、もう一度観なおしたいと思いました。

Windows10 の共有フォルダに、WindowsXP から接続できない場合がありました。共有できているフォルダもあり、設定を見る限り違いはまったくありません。共有しようとするHDDが4TBなのが原因じゃないかとか、128ビットの暗号化を下げてみたりしましたが、見当違いだったようです。詳しい症状は下記の通り。

  • 共有フォルダにアクセスしようとすると、しばらく砂時計で待たされた後に「\\****\**** にアクセスできません。このネットワーク リソースを使用するアクセス許可がない可能性があります。アクセス許可があるかどうかこのサーバーの管理者に問い合わせてください。このコマンドを処理するのに必要な記憶域をサーバーで確保できません。」と表示される。
  • フルコントロール権限を Everyone に付けても改善しない。
  • Cドライブ等のSATAハードディスクに共有フォルダがあればアクセスできる。アクセスできないのは、外付けのUSBHDDの共有フォルダのようである。
  • ハードディスクの容量には関係がない。
  • コントロール パネル「ネットワークとインターネット\ネットワークと共有センター\共有の詳細設定」の「ファイル共有接続」を、40ビットまたは56ビット暗号化、に設定しても改善しない。

ネット検索に少し苦労しましたが、原因はスタックサイズが不足している、ということでレジストリを変更することで対応可能だと分かりました。これが原因の場合、アクセスに失敗した際、イベントビューアーの「Windowsログ>システム」にイベントID=2011のエラーが出ているようです。設定方法はこちらにありましたので、引用しておきます。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に「regedit」と入力し、[OK] をクリックします。
  2. 次のレジストリ サブキーを見つけてクリックします。
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
  3. [編集] メニューの [新規] をポイントし、[DWORD 値] をクリックします。
  4. 「IRPStackSize」と入力し、Enter キーを押します。
  5. [編集] メニューの [変更] または [修正] をクリックします。
  6. [値のデータ] ボックスに、ネットワークに適した値(デフォルトが15で、11~50までの範囲)を入力し、[OK] をクリックします。
  7. Windows を再起動します。

久しぶりに VMware Player の環境を起動したら、ゲストOSからブリッジ接続できなくなっていました。 先だって、VMware Player のアップデートをしたのが原因かと思って、見当違いの試行錯誤をしてしまいました。 似たような症状で困っている人がいると悪いので、メモを残しておきます。

仮想マシンのネットワーク設定がブリッジになっているとか、そういう基本的な設定は出来ているすれば、ホスト側のネットワークアダプタを確認しましょう。 物理ネットワークアダプタ以外に、仮想ネットワークアダプタがインストールされている場合があります。 特に、他の仮想化ソフトウェア(Virtual BOX など)がインストールされていると、そういう状態になっています。 この場合、物理ネットワークアダプタ以外(要はインターネットに出れるアダプタ以外)のプロパティを開き、「VMware Bridge Protocol」のチェックを外してください。 これでゲストOSから、インターネットに出ていけるようになると思います。

あと、関係ないけど VMware Tools のアイコンが、通知エリアやプログラムメニューにも無いんですが、何かおかしいでしょうか。 とりあえず、使えているので問題は無いのですが、今まであったものが無くなると、何となく気になる。

Windows10 1511 のアップデートだけど、Windows Update のステータスで「エラー」と表示されていて、ずっとインストールされない状態でした。 エラーとだけ表示されていて、リンクになっているからクリックしてみるんだけど、その表示内容からエラーの詳細や解決方法は示されませんでした。 結論から言うと、これずっと放っておくとそのうちインストールが始まるみたいです。 エラーの内容も分からない、対処方法も分からない、いつの間にかアップデートされる、かなり時間を要するにも関わらず勝手に開始、とな。

BootCamp 上の Windows7 を Windows10 にアップグレードしたら、入力モードの切り替えができない、USB機器が使えない、BlueTooth もダメだ。 というような具合になってしまったが、それほど使用頻度も高く無いので放っておいた。 でも、やっぱり不便だし、Mac 持って出かける用事もあるので、直そうとあれこれ試してみたのですが、なかなかどうして勝手が違うものだなと思いました。

まず、Boot Camp 5.0 をアップデートすればいいんだと思い、Apple Software Update を試したんだけど「最新です」と言われてしまう。 ネットで調べると 6.0 が最新らしいのですが、なぜか出てこないし、手動でダウンロードもできないようです。 検索して見つけたのは 5.1.5769 で、これをダウンロードしてインストールしてみても「サポートされていないハードウェア」と蹴られてしまった。 MacOS 側でアップデートを全て適用してもダメだし、まったく以って訳わからん。

最初っからインストールしなおそうかと諦めて、Boot Camp アシスタントを開いたら「最新の Windows サポートソフトウェアを Apple からダウンロード」という項目があるのに気付きました。 USB フラッシュドライブを用意して、ディスクユーティリティーを使って消去(実は Mac をあまり使わないので、どこでフォーマットするのかも知らなかった)、ダウンロードと保存は結構時間が掛かったが無事終了。 後は、Windows10 でブートしなおして、USB メモリから SETUP.EXE を実行、終了後に再起動でアップデート終了。 ようやく、まともに使える Windows10 になったようです。

それにしても、使い慣れない Mac は何をやるにしても時間が掛かります。 無理してメインで使う気が無いので仕方ない面もあるが、Apple Software Update で Boot Camp 5.0 → 6.0 に上げられないのは不親切過ぎると思います。 手動でダウンロードしてきてインストールする手段が無いのも酷い話しだ。 中途半端は一番いけないと思うぞ。

EXIFでは少数を表すのに、RATIONAL型という分数を使います。 PHPのEXIF関数で取り出し可能ですが、正しく取り出せない場合があるので注意が必要です。 RATIONAL型は、分子と分母で2つの符号なし32bit整数だということですが、PHPのEXIF関数では符号付き32bit整数で取り出してしまうようです。 通常は符号のありなしが、問題になるような桁が出てくるのは稀で、単に分数として計算すれば良いはずです。 しかし、稀にGPSの緯度経度情報でマイナス値が取得されることがあり、対策をしておいた方が良いようです。 (符号なし整数の大きな値は、符号あり整数ではマイナス値となります)

ちなみにPHPの整数値は、環境に依存しており PHP_INT_SIZE で取得(バイト数)できます。 しかし、64bit OS(PHP_INT_SIZE=8 の環境)でもEXIF関数はマイナス値を返しました。 マニュアルを見ると「PHP 7 より前のバージョンにおける Windows は例外で、Windows で PHP 7 より前のバージョンを使う場合はは常に 32 ビットとなります」とあり、それなら 64bit Linux はどうかと試してみましたが、やっぱりだめでした。 この件は、EXIF関数のバグだと思われます。

原因が特定できたので、対策は割りと簡単にできます。 4バイト符号付きを符号なしに読み替えれば良いので、まず16進数に直してから、下位4バイトを残せばいいだけなので、下記のようになります。

hexdec( substr( dechex( $v ), -8 ) );

このコードですが、不思議な事に 32bit 環境でもうまく行きます。 理由は、hexdex 関数のマニュアルに「この関数は、プラットフォームの integer 型に収まらない大きな数も変換できます。 その場合、結果は float で返します。」とあり納得しました。 というか型付けができないので、dechex('FFFFFFFFFFFFFFFF') としても -1 にならず、大きな浮動小数点数に変換されます。

話をEXIFに戻すと、気をつけなければならないのは、LONG型とRATIONAL型です。 LONG型は符号なし32bit整数であり、RATIONAL型はLONG型のペアで表される分数です。 従って、これらの数値にマイナスが入ることは無く、その場合のみ前述の読み替えをすれば良いのです。 これとは別に、SIGNED LONG型とSIGNED RATIONAL型もあるので注意が必要です。 言うまでもなく、これらの型は符号ありなため、負数を許容しています。

これらを踏まえて、LONG型、RATIONAL型、及び緯度経度を正しい値で読み込む関数を作成しました。 実際は、レンズの焦点距離(RATIONAL型)や画像幅(LONG型)では問題になることは無く、そのまま使用して差し支えないと思います。 しかし、緯度経度では実際にそのようなデータを確認したことがあるため、対策をしておいた方が良いでしょう。

// LONG型を修正
function exif_long($v) {
	if ($v<0) {
		return hexdec(substr(dechex($v),-8));
	} else {
		return $v;
	}
}

// RATIONAL型を修正
function exif_rational($v) {
	list($num,$den) = explode('/', $v);
	$num = exif_long($num);
	$den = exif_long($den);
	return $num/$den;
}

// GPS緯度経度を十進に変換(西経と南緯の場合は負数にする処理が必要)
function exif_dms($dms) {
	$d = 0;
	for ($i=0;$i<3;$i++) {
		$v = $dms[$i];
		$d += exif_rational($v)/pow(60,$i);
	}
	return $d;
}

IEでは meta の viewport 指定が効きませんが、CSS に書いても無視されるので何でかなと思っていました。 検索しても特にそんな報告は見当たらないし、みんな同じことしか書いてないので八方塞がりになっていました。 試行錯誤の結果、分かったことは「width=device-width」という書き方で問題なく、「width=1280」のような書き方では無視されるということ。 でも何となく「width=1280px」のように単位を入れてみたら、IE でちゃんと認識してくれました。 画面のサイズを指定するということで「入るのはピクセル単位だけ」という思い込みが、なかなかその考えに至らなかったということになります。

IE では下記のように書いても無視される
<meta name="viewport" content="width=device-width">
有効なCSSの記述例
@-ms-viewport {
  width: device-width;
}
無効なCSSの記述例
@-ms-viewport {
  width: 1280;
}
有効なCSSの記述例(単位pxが必要なだけ)
@-ms-viewport {
  width: 1280px;
}

この機体のブルーを見たかったですね。翼端から伸びているのはヴェイパーですが、スモーク炊いてるみたいにクッキリしていました。ここ3枚ほどJPG素材ですが、さすがに辛いので打ち止めにしようかと思います。残念ながら、F-2はすべてJPG撮りなんですよね。

さて、小松基地航空祭も、残るは救難展示とブルーインパルス、あと地上展示ですが、最近忙し過ぎるので毎日更新は無理かも知れません。下手すると、また冬眠するかも。

09/21 石川県小松市 航空自衛隊小松基地
Canon EOS Kiss X4 / EF70-300mm F4-5.6L IS USM
JPG×1→Photomatix / Topaz Adjust / Topaz Simplify / Photoshop
Tags #乗り物 #飛行機 #航空祭 #小松基地 #XF-2A
※この記事は「Yahoo!ブログ - HDRp」からの転載です

低速操縦性能を実演してみせるF-2です。ランディングギアを格納する前に撮りたかったが、目前まで来るのを粘った結果、ドアが僅かに開いた中途半端なショットになってしまった。

09/21 石川県小松市 航空自衛隊小松基地
Canon EOS Kiss X4 / EF70-300mm F4-5.6L IS USM
JPG×1→Photomatix / Topaz Adjust / Topaz Simplify / Photoshop
Tags #乗り物 #飛行機 #航空祭 #小松基地 #XF-2A
※この記事は「Yahoo!ブログ - HDRp」からの転載です