グラフィックス画像圧縮技術

連載 :

2011年8月9日(火)

エンジニアリングクラウドを支える技術

第1回では、富士通が発表した次世代ものづくり環境「エンジニアリングクラウド」についてお話ししました。エンジニアリングクラウドを実現するために富士通研究所が開発した仮想デスクトップ高速表示技術が「RVEC（レベック）」です。RVECは、画面の中で更新の多い領域を動画化し、それ以外の画面更新の差分を静止画として圧縮して送信するというハイブリッド方式を採用しています。このうち動画化の部分については第1回ですでにお話ししました。

第2回ではRVECのうち静止画圧縮の部分について詳しくご説明いたします。

静止画圧縮の２つの方法～ロスレスとロッシー

静止画圧縮の技術はすでに数多く存在しています。皆さまもJPEGやZIP等の圧縮フォーマットはご存じと思います。それでは、なぜ、これらの技術を使ってエンジニアリングクラウドの画面転送がうまくいかなかったのでしょうか。

この点に触れる前に、ロスレス圧縮（可逆圧縮）とロッシー圧縮（非可逆圧縮）の違いを確認しておきましょう。

ロスレス圧縮は元のデータを完全に復元できる圧縮です。通常使われているZIPやLZHなどは基本的にロスレス圧縮です。このロスレス圧縮は、データ出現の法則性を見つけ出して、その法則性をもとに圧縮するという方法を採っています。従って法則性のないデータはロスレス圧縮ではほとんど圧縮できません。また、法則性を探すための処理に時間がかかることも大きな問題です。

一方、ロッシーな圧縮は人の見た目で分からない部分は捨ててしまうというアイデアで圧縮を行います。そして、人の視覚にとって重要な情報のみ残しますので、すべてのデータを均等に処理するロスレス圧縮に比べて圧縮率は、通常、はるかに高くなります。

それではまずロッシー圧縮ではなぜうまくいかないか説明しましょう。下の図1を見てください。

図1：圧縮結果の比較。左：ロスレス圧縮、右：ロッシー圧縮（クリックで拡大）

左側はロスレス圧縮、右側はロッシー圧縮です。右側では全体にぼやけが発生してエッジがつぶれてしまっているのが分かると思います。この結果、配線先の端子がどこにあるかという最も重要な情報さえ確認が容易ではありません。このような画面ではエンジニアは設計業務を遂行できないでしょう。

このようなわけで、エンジニアリングクラウドで扱うグラフィックス画像の圧縮には従来のロッシー圧縮技術は適さなかったのです。

エンジニアリングクラウドのために必要な画像圧縮～高速性

ここまでの説明で、エンジニアリングクラウドではロスレス圧縮が必要なことがお分かりいただけたと思います。ところで、今回の圧縮技術でもう１つ重要な点があります。それは高速であるということです。

高速な方がいいということは当たり前と感じるかも知れません。しかしデスクトップ画像転送で使う圧縮は通常のファイル圧縮よりはるかに短い処理時間が要求されます。

例えば、ファイルを圧縮してメールをするような場合、1～2秒であれば普通の人は違和感なく操作すると思います。もちろんファイルサイズにもよりますが、普通のファイル圧縮は数秒で終われば問題ありません。

しかし、エンジニアリングクラウドでは画面が切り替わるたびに画像を圧縮する必要があります。もちろん、画面の変更領域がわずかであれば問題ないのですが、ユーザーが画面スクロールや3Dモデルの回転・ズーム等の操作を行っている場合は画面の大部分が更新されます。人間の視覚では画面のフレームレートが30フレーム/秒以下になるとストレスを感じるようになるといわれていますので、おおざっぱにいって1/30(秒)=約33(ミリ秒)以内で圧縮処理を完了する必要があります。

それでは33ミリ秒程度で圧縮が完了すれば十分かというと、そうではありません。仮に33ミリ秒の圧縮処理が1秒間に30回実行されると圧縮処理だけで1CPUをフルに消費してしまいます。もちろんこのようなことが起きないように、RVECでは更新が連続して発生するときは動画圧縮も組み合わせているのですが、静止画としても時間短縮は大きな問題です。しかも我々がめざしているのは「エンジニアリング」クラウドです。エンジニアリング系のアプリケーションはオフィス系のアプリケーションと異なりCPUを大量に消費することがしばしばあります。このためエンジニアリングクラウドにおける画像圧縮はなお一層の高速化を求められるわけです。

ところが、従来のファイル圧縮などに使われているロスレス圧縮技術はかなりの処理時間を要します。最初に述べたとおり、ロスレス圧縮はデータ出現の法則性を見つけ出そうとします。一般にはデータを最初から見てゆき、パターンを探索しながら辞書のようなものを作って、パターンを辞書で置き換えて圧縮します。ある程度の圧縮率を実現するためには探索を深くする必要がありますが、その分時間がかかってしまい、インタラクティブなデスクトップ転送は難しくなってしまうのです。

このため、従来の画像転送では主にHextile^※1と呼ばれる簡易型の圧縮技術を使っていました。これは画像を16X16の小タイルに分割して、その中で画像を単色の矩形の張り合わせとしてとらえるものです。いわばパターンを単色矩形に限定したようなものです。このことにより圧縮にかかる時間は大幅に短縮できますが、CADのような複雑な線が多い画像では途端に圧縮率が悪くなってしまいます。

つまり、エンジニアリングクラウドは、エッジがつぶれないロスレス圧縮で、圧縮率が高くかつ極めて高速な圧縮技術を必要としているのです（図2）。

図2：エンジニアリングクラウドが求める圧縮技術（クリックで拡大）

[※1] Hextile: VNCで用いられているロスレス画像圧縮方式

グラフィックス画像圧縮技術

このように、画像転送向けのロスレス圧縮は圧縮率を上げようとすると圧縮時間が増えてしまい、圧縮時間の短いシンプルなものでは圧縮率が悪いため多くの帯域を消費するというジレンマがあります。そこで富士通研究所が開発したのがグラフィックス画像圧縮技術です。これは画面を単色のベクトルパターンに分割する方法を採っています（図3）。

図3：グラフィックス画像圧縮方式（クリックで拡大）

この方法は従来の単色の矩形のみを基本パターンとするよりも高圧縮です。なぜならば、従来手法の単色矩形も1種のベクトルですのでグラフィックス画像圧縮のマッチパターンの1種と見ることができますし、これ以外の斜め線にもパターンがマッチするためです。この効果は特にエンジニアリング系のCADアプリでは非常に大きくなります。しかもベクトル的な特徴を探索するだけであれば、ZIPなどのように探索に時間がかかり、処理時間が極端に遅くなることはありません。

さて、ベクトルをパターンとするだけでは確かに効果はあるのですが、それでもまだ実用に耐える十分な圧縮率は得られませんでした。なぜならば、CADではデータ座標を浮動小数点で管理しているのですが、実際に描画するときには当然ピクセルで離散化された情報になります。ですから傾きにしても完全に一様ではなく、ところどころで若干変化してしまうことがあります。

また、線が交差しているところはどちらか一方が切れたような画面になります。そのようなケースでは別のベクトルとしなくてはならず、データ量が増えてしまいます。かといって純粋なベクトルに変換してしまっては部分的に情報が欠落してしまい、JPEGの場合と同様、設計者にとって好ましくない不正確な画面になってしまいます。

そこで、我々はベクトル画面をベクトルそのものとその差分に分割して圧縮する手法を開発しました。ベクトルの差はあるとしても1～2ドット以内に収まる僅少な情報です。この差分とベクトル情報の組み合わせ方法を工夫することにより一層圧縮率を向上することに成功しました。富士通研究所で実験に使用したグラフィックス画像では、従来の画面転送で使われているロスレス圧縮手法と比較し、処理時間は同じであるにもかかわらず圧縮率が3倍向上しています。

グラフィックス画像圧縮方式も万能ではない

今まで説明してきたグラフィックス画像圧縮方式ですが、残念ながら万能ではありません。例えば、エンジニアリング系のアプリでも光沢感まで考慮したデザインレビューなどが行われることがあります（図4）。このような場合、グラデーションが非常に多い画像が現れます。このような美感を重んじる場合ではロスレスで画面を確認したいところですが、グラフィックス画像圧縮も含めて従来のロスレス圧縮では圧縮率は高くありません。グラデーションの多い画像については将来の課題としてこれからも研究していきたいと考えています。

図4：光沢感まで考慮したデザインレビュー画面

しかし、エンジニアが使用するデスクトップ画面はグラフィックス画像圧縮が得意なケースが大部分です。グラフィックス画像圧縮によって、エンジニアは従来よりもはるかに快適にCAD等のグラフィックアプリを遠隔地から操作することができます。あるいは従来では十分でなかったネットワーク帯域の環境からでも仮想デスクトップサービスが使えるようになります。

以上が、エンジニアリングクラウドで用いられているグラフィックス画像圧縮技術の概要です。最終回となる次回では、ネットワーク遅延に対する対応などについてお話しする予定です。