....... [ <: prev (編集後記)] [here: memo (編集後記の編集後記)] [フレーム解除]
2008年7月27日(日)、18:30 頃、 筆者は埼玉県朝霞市(川越街道沿いの某所)にいた…。
ちょうど夕立がやんだところだった。ふと空を見上げると――西の空には黄金の夕焼け、そして東の空には巨大な虹が視界いっぱいに広がっていた。しかも、東〜南〜西〜北…と、360度の天球上には、微妙なグラデーションの光の文様がエンドレスにつながっていた。自然が描き出すスケールの大きな芸術に、筆者は圧倒された…。
地球上で一番美しい空が見られる時間帯は、1日に 2回ある。それは、夜明けと日暮れの時間帯だ。洋の東西を問わず、この時間帯を表す単語や熟語は数知れない。トワイライト、マジックアワー、黄昏、宵、暁、曙、黎明、等々…。この時間帯は、明けの明星、宵の明星という言葉でも知られているように、金星のショータイムでもある。先日、埼玉県で見た夕焼けでは、雨上がりだったので星を見ることはできなかったが、代わりに虹を見ることができた。雨上がりの夕暮れも良いものだと思った。
夜明け、日暮れの時間帯は、刻々と景観が変化して、どの一瞬を切り取って見ても、捨てがたい美しさに満ちている。一瞬一瞬が 2度と巡り合えない光景の連続として過ぎてゆく。
忙しい現代人にとっては、その『金星のショータイム』に空を眺める余裕は、なかなか持てないのが実情だ。現実の美しい空は一瞬の光景だが、この編集後記では『4時〜7時』『16時〜19時』のそれぞれ 3時間を、早朝、夕方として見栄えが変わるように設定した。このぐらいの幅を持たせておかないと、ライフサイクルによっては、全く見ることができない人もでてきてしまう可能性があるためだ。何よりも、作者自身がたまにしか見られない状況になりそうだったので…。
時間帯によって挙動を変えるのは、CGI ではよく使われるテクニックだと思うが、実際にそういう CGI を作ってみると、動作チェックをするのが結構面倒だった。特に、早朝と夕方の画像をブラウザでモニターしたい時などは、しばしば内蔵時計を進ませたり遅らせたりする必要があった。そんなことを繰り返しているうちに、今現在の本当の時刻が分からなくなってきて、軽い時差ボケ状態に陥ることもあった。普段なら、パソコンでの作業中は、タスクバーの時計をちらっと見て時刻を確認すれば良かったが、今回は、たまに目覚まし時計も見なければならなかった。そうしないと、気が付けば寝る時間がなくなっていた…そんな危険もあったので。時計の針を、頻繁に遅らせたり進ませたりする…たったこれだけの単純な行為が、人のバイオリズムを滅茶苦茶にする、ということを今回の作業で思い知った。皆さんも気を付けた方がいいよ。
2008.08.02 Sat 14:25
今回、一番苦労したのは CGIスクリプト…ではなくて、背景画像の制作だった。今回の『編集後記』で作成した画像は、正直なところ失敗だと思っている。ぼかしたり、グラデーションを加えたりして、中途半端にリアルになってしまった。もっと単純にパターン化し、デフォルメした方が、デザイン的に洗練されたものになったと思う。
今回は試しに、ということで、様々なグラフィックソフトを使ってみた。それが失敗の元だった。使ったソフトは――
どれも古いバージョンばかりなのが、ちょっと悲しいところだが、要は『使えれば良い』ので、筆者は特に困ってはいない。バージョンアップの度に操作方法が変わってしまうのも鬱陶しいし…。本当は、CorelDRAW に付属のフォトレタッチソフトがお気に入りだったのだが、Windows XP にアップデートした時に使えなくなってしまった。Gimp と Pixia は、ずいぶん前にインストールしたが、ほとんど使ったことがなかったので、色々と試してみた。フォトレタッチ系のソフトは、使ってみると、どれもが確かに面白い。微妙なトーンの表現が可能だ。だが、それが仇となって、中途半端にリアルな画像が出来てしまう…。ある意味、24ビットRGBカラーは使わず、8ビットカラー(256色)で編集した方が、その制約が逆にプラスに働くかもしれないと思った。今度、機会があれば、JPEG ではなく、意図的に GIF(パレットカラー) を使ってみようと考えている。ただし、8ビットカラーに対応したフィルタはとても少ないので、そこがネックになりそうだ。
単純化したパターンを生成するなら、ビットマップ系のグラフィックエディタを使うのが一番良いのだが、これがなかなか…作者のニーズに合った画像を簡単に生成できるソフトは意外と少ない。筆者としては、MSX 用のグラフサウルス辺りが一番使い易かったような気がしている(15年以上も昔のソフトなんだけどねぇ)。
架空の自然画像を作る場合、抽象的なパターンを複合的に組み合わせて合成することになる。そこに自動化の余地がたくさん残っている。が、現状のグラフィックソフトは、作者の感性によってドットの1点1点を自分で決めることを強いられる。極論としては、そうなる。それがグラフィックソフトの基本スタンスであり、つまり、スペシャリスト用のソフトだ。
多くのビットマップエディタは、Adobe Photoshop のインターフェイスの影響を受けすぎている。もっと違ったインターフェイスがあってもいいと、筆者は思っている…。MSX BASIC で簡単に出来ていたことが、なぜ最新版のソフトでは複雑な手順を踏まなければならないのか…筆者は苛立ちを隠せない。
筆者は Perl を覚えたことで、テキスト処理に関して言えば、ある程度の自動化が実現できたと思っている。それによってアプリケーションのインターフェイスに振り回されることから開放された。しかし、画像処理の自動化については未だ手付かずのままで、相変わらず、グラフィックソフトのインターフェイスに振り回されながら四苦八苦している。グラフィックソフトの使い方を覚えるのは、もうこの辺でやめて、そろそろ GD や Image::Magick 等のグラフィック系の Perl モジュールの使い方を覚えた方が、精神衛生上は良いのかもしれない…と、そんな風に思いはじめている。ただ、GD と Image::Magick は、インストール作業が難しそうだからなぁ(Windows 版は無さそうだし)。
2010/06/21 (月) 11:12
現在、foussin は Firefox 3.6 ブラウザを使っている。が、念のため、Internet Explorer 8.0 と Google chrome 5.0 でも動作確認してみた。結果は、やはり微妙にレイアウトが崩れている部分があった。でもまあ、許容範囲…というか、妥協できるレベルの違いなので、これ以上の修正は行わないことにした。
同じ Firefox でも、Linux 版と Windows 版では『デフォルトのフォント』が違うため、やはり、全く同じ画面を再現することはできなかった。モニタの解像度が変わるだけでも見栄えは一変するので、誰が閲覧しても同じ画面なんて絶対に再現できないだろう。
それにしても、Google chrome は速い。でも、html(dtd) の解釈では Firefox が一番綺麗なレイアウトが可能みたいだ。たぶん、dtd を忠実に再現していると思う。IE は…ダイナミックhtml 等の独自路線が充実? ま、どれも一長一短だね。
2010年現在では、筆者は Paint.NET という画像ソフトをよく使っている。
次回の編集後記でも、ちょっと面白い仕掛けを紹介するつもり。お楽しみに。