川村渇真の「知性の泉」

画像データを適切かつ効率的に利用する属性のあり方とは?


今回は、画像データが持つ属性について解説していくことにする。多くの画像データを扱うような場合、目的に合ったものを探すのはけっこう苦労するものだ。こうした作業を効率的にするには、画像データに属性を持たせておくのがよいだろう。こうすると、あとあと便利だ。画像の種類だけでなく、物体の方向(後述)なども属性に含めておく。また、画像を自由に組み合わせる機能や、すべての画像に加工処理できる機能も必要だ。画像データがどのように属性を持つのがベストなのか、そしてそのうまい利用の仕方をここで提案していこう。


画像データはより詳細で容易な扱いが可能
従来とは異なるデータの部品と組み合わせ

 最近のコンピュータは、画像データを扱う機能をもつのが当たり前になった。画像データは、ユーザーが描いたイラスト、カメラから取り込んだ写真画像、CADソフトで描いた部品図など様々だ。これらを統合的に扱うためには、いろいろな属性を持たせてやる必要がある。だが、それを模索する前に現状の仕組みを見てみよう。
 既存OSでは、どんなデータでもファイルとして保存するため、画像データもファイル単位で扱うことになる。どんな形式のデータなのかは、ファイルのタイプとして示される。たとえばPICTやTIFFなどの標準化された形式もあるし、Adobe Photoshopのようにアプリケーション独自の形式もある。
 ファイル形式を分けるか1つのやり方として、ドロー系とペイント系と分類する方法がある。しかし、ドロー内の1オブジェクトとしてペイントも含められるため、適切な分け方とはいえない。この部分がポイントになるのだが、ドローは素材であるオブジェクトの部品データと、それらを統合する組み合わせデータの両方を含んでいる。一方、ペイントは素材で、部品データしか持たない。ファイルという仕組み自体が、統一された分け方になっていない。改良するためには、部品データと組み合わせデータを分ける必要がある。これは、情報中心の考え方とも一致する。
 情報中心システムでは、画像データも、より細かな単位で扱うのが基本だ。単純に考えると、部品データと組み合せデータだが、『組み合せデータを組み合わせる』使い方も必要である。階層的な組み合わせ方をサポートすれば、画像データをより細かな単位で保存するようになるからだ。
 画像データの保存場所は、既存OSのファイルのように単独ではない。ほかの項目と一緒に構造体データの中に入れておく(図1)。たとえば、顔写真なら人物という構造体データの1項目となる。このような方式をとるので、ほかのデータと関連を持ったまま、総合的に管理できる。

図1、画像データも、数値やテキストと同じように、対象となる構造体データの一部として入れる。右側は画像データ自体の構造で、形式や色数などの属性を持つ

図1

 ベジェ曲線によるドロー表現やカラーのビットマップ画像といった区別は、画像データのタイプとして持つ。表示内容を生成するときは、データのタイプを参照して、対応する展開ドライバ(注1)にデータを渡してやる。

注1:専用のドライバを用意するのは、画像の展開機能だけではない。データのタイプごとに、編集や保存の機能も必要

表1、OSの種類ごとに、画像データ関連の機能を比較した結果。情報中心システムでは、ファイル形式を意識せずに使えるうえに、利用の自由度も高い

               OSの進歩 =================>

表1

「画像が『あとで便利な』属性を持てば   
  もっと扱いやすく、用途も広がるのに!」

画像の加工や組み合わせはより自由に
組み合わせの設定を保存

 画像を組み合わせる機能では、すべての画像データに対応していなければならない。これは、内部でビットマップ画像へ変換する方法で実現する。その際、最終的な表示サイズから逆算して、必要なドット数を求める。画質を重視する設定(注2)では、2倍のドット数で処理し、最後に半分の大きさに変換すると、見た目がきれいに仕上がる。内部処理をビットマップで統一しておくと、ドロー系の画像データにも、ビットマップ化させて、そこにぼかしなどの画像の加工を施せる。加工処理には、既存ソフトのフィルタや画質補正に加え、拡大縮小や変形も含まれる。
 組み合わせ機能では、マスク、重ね合わせ効果、レイヤーなどを持たせる。この機能をユーザー側から見ると、現在のドローソフトに近い形と、処理の流れ図の2つになるだろう。この両方式を一緒に表示しながら作業するので、使い勝手を損なわずに、処理の流れの把握を実現できる。
 画像加工や組み合わせの設定内容は、元データへリンクする形で保存しておく。こうしておくと、表示する画像は必要なときに生成し、処理時間が長い場合にだけ生成結果を残しておく。このような仕組みなので、加工や組み合わせをあとからでも変更することが可能だ。
 画像処理と組み合わせの設定内容それ自身についても、1つのデータとして保存する(図2)。この設定からさらに生成するものも画像データなので、システム内では画像データとして扱う。それをたとえば会社のロゴとして使う場合には、会社の構造体データ内のロゴ項目の値として、設定内容を保存する。この場合には、あらかじめロゴ項目が画像データとして定義されていなければならない。

図2、組み合わせと画像加工を一緒に設定して、1つの完成画像をつくる。組み合わせ後の画像に加工処理を加えることもでき、何段階もの組合せも可能。途中段階を分けて保存すれば、別な組合せ設定でも使える

図2

注2:複数のモードが必要かは、CPUの処理能力に関係する。十分に高速なら、高画質モードだけで十分。複数のモードを持つ場合には、作業ステージごとに設定する

画像データは2種類に分けられる
奥行きが表現されているとかえって邪魔

 工業デザインなど、個々の画像を組み合わせて、なにかをつくりだすような環境では、画像の組み合わせも重要な情報だ。これを実現するために、画像データを2つに分類する。特定の物体だけを含んでいる「素材画像データ」(注3)と、それ以外のすべての画像データである「非素材画像データ」だ。
 素材画像データは、描いてある内容が形のある物体で、写真(注4)と描いた絵の2種類を含む。基本的には1つの物体を描いたものだが、複数の物体を組み合わせた状態でもかまわない(注5)。2次元画像として組み合わせるのが目的なので、奥行きを持たないのが理想だ。写真であれば、斜め前から撮影するのではなく、真正面から前面パネルだけを撮るようにつくる。少しでも斜めから撮影すると、前面パネルがゆがむのに加え、側面が少し写ってしまう。イラストも同様で、できるだけ側面なしの状態で描く。側面が必要なら、側面を正面にして撮影した画像を用意する。
 このように作成するのは、奥行きがあると組み合わせが難しくなるからだ。たとえば、ある画像は右側面が少し写っていて、別な画像は左側面が少し写っているようなとき、この2つを簡単に重ねるわけにはいかない。奥行きは立体感を表現し、複数の物体を組み合わせたときに、奥行きの方向が一致していないと、仕上りの立体感に矛盾が生じるからだ。そうならないためには、奥行きのない画像が基本となる。
 素材画像データの特殊な例として、地図が挙げられる。これもよく考えると、地球という物体を抽象化して描いたもので、素材画像データの定義にあてはまる。ただし、地図のもととなる地球は球体であり、その表面の地形を描いている。大きな範囲を描くと平面とは見なせないので、いろいろな図法が考案されている。地図の画像データでは、図法の種類をデータ属性として加える必要がある。また、一部の場所を描くことが多いので、どの部分を描いているのか、範囲を示す値も加える(注6)

注3:この名称は気に入っていないが、ほかに良い名前を思いつかなかった
注4:撮影した写真を素材画像データとして用いる場合には、周囲の背景を削除する必要がある。実際には、被写体以外の部分をマスク機能で隠す方法を用いる
注5:2つ以上の物体を組み合わせた画像は、それぞれの素材画像を組み合わせてつくれる。それが不可能なときだけ、組み合わせた画像を別に用意する
注6:緯度と経度の値で範囲を示す

物体の方向という属性がなぜ重要か
「視点」と「正面」がキーポイントとなる

 素材画像データの組み合わせでは、「物体の方向」という条件が重要となる。たとえば、部屋の間取り図があって、その上に家具を配置する場合を考えてみよう。それぞれの家具を画像データとして用意するが、どんな場合でも上から見て描いた画像でなければならない。別な例を挙げれば、商品陳列棚の配置を決めるような際には、個々の商品の画像データは、正面を向いたものが必要だ。
 以上のように、使用する目的によって、物体の方向が決まってくる。データがこうした部分を属性として持てば、目的に合った画像だけを組み合わせの候補として表示できる。もっと詳しく見ると、2つの属性が必要である。どの方向から見た画像であるかという「視点方向」属性と、どちらが正面かという「正面方向」属性だ。自動車を上から見た絵には、前面が上を向いている状態や、右を向いている状態がありうる。複数の自動車を同じ方向で並べる必要があるときには、各画像ごとに、前がどちらかを知らなければならない。
 厳密さを求めるなら、細かな数値で方向を表現すべきだろう。しかし、実際には90度単位で使うことが多く、上から見た画像と前から見た画像がほとんどを占める。その点を考慮して、属性値には90度単位の方向値を採用する(図3)。取りうる値は、上下左右と前後の6種類だ。

図3、画像に描かれた内容によって、2種類の方向属性を設定する。正面方向属性がない物体では、値を設定しない

図3

 より細かな角度が求められることもあるので、第2レベルの属性値として、6種類の角度からのズレを、角度の数値として加える(注7)。少し奥行きのある画像データには、この細かな値を設定することになる。

注7:基準となる方向からのズレとして表現する。上下方向で何度、左右方向で何度という2つの数値が必要

「意外に気がつかない『物体』の方向    
  これを統一しておき有効活用するには?」

物体の大きさや縮尺も属性に加える
自動的にマシン側が計算してくれてラク

 複数の物体を組み合わせるときは、それぞれの大きさも考慮すべきだ。イラストでも写真でも、物体には大きさがある。それらを無視して組み合わせると、アンバランスな画像ができ上がる。これを実現するには、物体の大きさを属性として持ち、拡大縮小の処理を自動化するのが一番だ。画像の大きさを調整する作業なんて、人間にやらせるべきではない。属性の内容についてだが、ドロー形式の画像では物体の大きさを指定し、ビットマップ画像では1ドットの大きさを縮尺として指定してやるようにする。
 ドロー形式の画像データなら、拡大縮小でも画質が低下しないが、写真などのビットマップ画像では、拡大縮小で画質が低下する。しかし、美しさを求めるなら、ドロー形式より、等倍のビットマップ画像のほうが上だ。とくに少ないドット数で描く小さな絵は、ビットマップ画像でないと使いものにならない(注8)
 以上を考慮して、ビットマップ画像を有効に活用するルールを整えたい。画像データの属性として、推奨縮尺を規定する。何種類かの縮尺を用意し、それに合わせてビットマップ画像をつくる。できるだけキリのよい数値がベストなので、1ドットが1cmや1mとする。これだと間が10倍と開きすぎるので、1cm→2cm→5cm→10cm→20cmと続く数値にする(注9)。上限や下限は設けず、1と2と5が基数ならどの桁でも認める。ドロー形式との併用も考慮すると、サイズの小さい範囲では何種類かの縮尺でビットマップ画像を用意し、ある程度以上の大きさはドロー形式ですませるというつくり方がベストだ(注10)。基準の縮尺が決められると、画面上の表示でも、とくに理由がない限り、この縮尺を用いる機会が増える。物体の大きさが必要かどうかは、使用する表現方法によって決まる。大きさの属性が必要な表現においてだけ、この属性値を使うことになる。
 既存のビットマップ画像では、物体の大きさではなく、解像度という属性を持っている。これは印刷で必要なプリンタの解像度に合わせて用意したもので、情報中心で考えた場合には、ほとんど意味がない。

注8:この考え方はフォントと同じだ。サイズが小さい範囲では、ビットマップフォントのほうがはるかに美しい
注9:キリのよい数字でありながら、約2倍ごとに増える組合せを求めると、これらの数値になる
注10:この併用方法もフォントと同じで、効率と美しさのバランスを考えた結果

撮影の日付なども案外重要なデータとなる
表示倍率の設定がされていれば完璧

 ほかにも必要な属性はある。写真の場合は、撮影した日付と時刻だ。たとえば、顔写真を撮った場合、いつのデータかも重要だ。人物データの中に複数の写真を入れ、顔写真項目の履歴データとして保存する。このとき、各写真には撮影日付を設定する必要がある。ほかの写真でも、撮影した日付が役立つことは意外に多いはずだ。
 撮影日は、作成日と異なる点にも注意したい。スキャナで画像を取り込んだ場合、取り込んだ日付が作成日となり、撮影日とは異なる。情報中心の観点では、写真データにとって、作成日はあまり意味がなく、撮影日のほうが重要だ。同様にイラストでも、描いた対象が実在する場合には、対象の存在した日付が撮影日に相当し(注11)、作成日はあまり重要でない。  もう1つの属性として作者がある。イラストならイラストレーター、写真では撮影者が該当する。誰がつくったデータなのかを情報として持つためだ。
 このほか、表示に関した属性として、推奨表示倍率を用意する。ビットマップ画像を意識した属性で、極端な拡大や縮小での表示を防止するのが目的だ。画像データの1ドットが画面上の1ドットになるときに等倍とし、比率のデータとして表現する。上限と下限の2つの数値をも位置、範囲の形で指定する。画面表示の際には、範囲に該当するデータを優先し、なかったときにだけ範囲外での倍率で表示する。

注11:イラストも写真も画像データなので、項目名はできるだけ同じほうがよい。その意味から、撮影日は適切な項目名ではない。作成日は、別な意味になるので使えない。存在日というのも違和感があり、採用しなかった。けっきょく、適切な名前を思いつかなかった

風景写真向けの属性も規定する
デジタルカメラ普及をにらんでの機能

 ここまでは素材画像データについての話をしてきた。しかし、非素材画像データについても属性が必要だ。とくに風景を撮影した写真画像データには、いくつかの属性を用意しておく。撮影時の明るさ、撮影場所、撮影レンズの画角、などだ。
 撮影時の明るさは、被写体の明るさを示す数値で、カメラ用の露出計でEV値(注12)に相当するものを用いる(注13)。写真を撮影するとき、フィルムに達する光量を調整するために、自動露出が働く。その結果、同じ明るさの風景が仕上がる(図4)ものの、実際の明るさとはちがうものだ。複数の画像で明るさを比べるとき(図5)に役立つ。

図4、自動露出により、実際の明るさに関係なく、同じような明るさの写真に仕上がる

図4

図5、被写体の明るさ情報を持つと、どれかの写真を基準にして、撮影時の明るさで表示できる

図5

 撮影レンズの画角は、レンズの種類ごとの画角情報である。上下、左右、対角での角度を数値として持っておく。画像解析のための情報として用いる。
 以上の属性は、特殊な目的で役立つだけで、通常の用途では使わない。あえて規定するのは、今後デジタルカメラがもっと普及するだろうし、そのテクノロジーの進歩によって自動的に入力できるからだ。

注12:外界の明るさを示すための数値で、明るさが2倍になると値が1増える。シャッター速度や絞りの値が2倍単位に増減するので、計算しやすいように「2倍で1を加算」 としたもの
注13:実際には、露出計で測定した値ではなく、撮影時のシャッター速度と絞りから求めた値を採用する。露出計での測定値は、被写体の反射率(色や濃度)によって変わり、明るさとは異なるからだ

こんな進化したデジカメがあればいい
マスク処理だけばやっぱり手作業か?

 これまで述べてきたように、画像データが属性を持っていることが当たり前になると、デジタルカメラも対応する製品が登場してくるだろう。撮影日は、時計を内蔵することで簡単に取り込めるし、撮影時の明るさは、自動露出の機能を利用すればいい。レンズ画角は、ズームレンズなら少し面倒だが、困難なことではない。これらの値は、自動的に入力することが可能だ(注14)
 オートフォーカス機能を持っていれば、主要被写体までの距離を測定でき、その数値から1ドット分の長さを計算できる。この値は、素材画像データとして取り込むときに用いる。
 素材画像と非素材画像のどちらにするかは、撮影時点でなく、コンピュータに取り込む時点で選ぶ。その選択によって、必要な属性をカメラから取り込む。撮影場所や撮影者のように自動入力できない属性は、取り込むときにまとめて入力する。
 物を撮影した写真を素材画像として使うためには、物体の周りを削除するために、マスク情報を追加する必要がある。多くの場合、これは手動で設定するしかないだろう。

注14:既存OS上で画像を扱う場合でも、これらの情報は役立つ。とくに撮影日と時刻は、画像管理用の情報として自動入力してほしい

「デジタルカメラもきっと進化して     
  撮影前段階から属性のオプションを用意」

3次元の世界でも属性が必要
アイデアがこなれるのはもう少し先

 素材画像データと非素材画像データを区別し各種属性を持たせるのは、作業の自動化を助けるのが目的である。そのため、こうした属性などは、組み合わせ候補を表示するときの条件として使う。もし、条件を手動で変更すれば、すべての画像が組み合わせの対象となる。非素材画像データでも、背景として貼り付けることがあるからだ。
 動画は、静止画を連続したものと考えられる。動画にも、静止画と同じ属性を持たせることが可能だ。ただし、フレームごとに画像が変化するので、フレーム単位または特定範囲での属性値となる。
 今回は2次元の平面画像を取りあげたが、3次元の物体を扱う3Dの世界にも、同じような考え方の標準化が必要だ。これについては、まだ筆者自身分析を完了していないので、現時点では提案するほどのレベルに達していない。シミュレーション機能との連動など、考慮すべき点がかなり多く、2次元の場合ほど簡単ではないからだ。そのうちに詳しく分析して、提案したいと考えている。
 以上のように、画像データの属性と組み合わせ機能は、多くの画像を適切に使うために役立つ。画像データの数が増えるほど、効果を発揮するはずだ。
 次回は、情報中心システムの重要な機能を解説する。その中で、画像データの属性を利用するため、今回取りあげた。


下の飾り