WEB上でドット絵を拡大表示する

目次

設定方法

CSSJavascript

CSS の記述方法について

optimizeSpeedoptimize-contrastcrisp-edgesそして姿を消したpixelated復活

JavaScript について

設置方法技術解説ライセンス


optimize-contrast

2番目の勧告候補は 2011年2月。

ここで、公開文書としてははじめて、image-rendering プロパティが提示されました。


指定できる値は auto と optimize-contrast の2つです。

optimize-contrast は、「シャープなラインを維持し、色をスムージングしない」ように求めています。その主な利用目的として、ドット絵の表示も挙げられています。

シャープなラインを維持し…というのは微妙な言い回しですが、つまり EPX や 類似アルゴリズムを使用することを想定しているようです。


先に書いたように、optimizeSpeed と optimizeQuality は非推奨の値と明記されました。

おそらくは、「速度優先」と「品質優先」という言葉では、処理内容が不明瞭で非互換性につながるためでしょう。

実際、GPU を使用して高速に拡大を行うと、補間を伴う高品質でしか行えません。ドット絵のために低品質の拡大を行うと、CPU を使うことになり低速になります。


Safari の古いバージョンでは、 -webkit-optimize-contrast という設定を行いました。

この記述の根拠は、この公開文書にあるようです。


crisp-edges

さて、3番目の勧告候補は、5か月後の2011年7月。

image-rendering の取る値は auto と crisp-edges に変わりました。


説明も少し変わり、「画像のエッジを維持し、色をスムージングしない」となっています。

値の名前の変更も含め、重要なのは「コントラスト」(つまり、色をスムージングしない)ではなく、エッジを維持することだ、と明示したかったのでしょう。


ここで、「画像のエッジを維持し」と明記されたのは、ドット絵をドット絵のまま拡大する、ということを想定していたように思えます。

つまり、EPX などのアルゴリズムを使わず、あえて低品質な画像拡大を行え、ということ。


しかし、エッジを維持する、という言葉は受け取る人によって異なるでしょう。元のドット絵の形が変わってはならない、と考えることもできますし、斜めに連続したドットを斜め線だと類推し、「はっきりとエッジを出した」画像を表示しようとする…つまり、EPX アルゴリズムを使用するほうがよい、と考えることもできます。


ここでも、optimizeSpeed と optimizeQuality は廃止で、auto と同じとなる、と明示されています。

しかし、optimize-contrast をどのように扱うかは示されていません。



FireFox が使用する -moz-crisp-edges や、Safari が使用する -webkit-crisp-edges はここに由来します。

また、古い Opera でも、 -o-crisp-edges を使いました。


そして姿を消した

4番目のバージョンは、3番目からわずか2か月後の 2011年 9月です。ここで、image-rendering プロパティは忽然と姿を消しました。

いったい、この2か月の間に何があったのでしょう? 草案から消えてしまった、ということは、image-rendering プロパティを使用するのは不適切である、と言う意味になります。


4年たった 2015年 11月 12日時点でもまだ、勧告候補には image-rendering は入っていません。

もっとも、勧告候補の日付は 2012年 4月 17日。3年間新しい勧告候補は出ていない、ということになります。

この勧告候補は7番目に当たり、十分議論が尽くされてこれ以上の案が出ないのかもしれません。


古い Chrome では、勧告候補から消えたことを受けて、image-rendering のサポートをやめました。(それ以前は -webkit-crsp-edges が使えた)

また、Opera も Chrome のエンジンを利用するようになった時から、サポートしなくなりましたし、さらに後でマイクロソフトが作った新ブラウザ、Edge でもサポートしていません。


pixelated

image-rendering 自体が姿を消してからほぼ1年後、CSS4 草案の最初のバージョンが発表されました。そして、image-rendering はここで再び姿をあらわしました。

CSS4 に移行になった、ということは、議論が明らかに不足しており、互換性を保ったまま各ブラウザが実装することはできない、と判断されたことを意味します。

(ここまでに書いたことを読んでいただければ、ドット絵の扱いのややこしさが理解していただけるでしょう。)


CSS3 すらまだ勧告に至らない状態で、CSS4 は実装しないように求められています。

実際、chrome や safari が使用している webkit ライブラリでは、image-rendering は CSS4 向けの機能として、特別な方法でコンパイルしなくては使えないように変更されています。


さて、CSS4 の image-rendering では、auto と crisp-edges に加え、「pixealted」が指定できるようになっています。

crisp-edges との違いは2つ。明示的に「ニアレストネイバー法か、それに類するアルゴリズムを使用する」と書かれたこと、縮小時には auto と同じ動作とする、と明記されたことです。

縮小時! そうです。今までの議論はすべて「ドット絵の拡大」で、縮小のことが全く考慮されていませんでした。

複数ドットを混ぜた色で表現すれば、「コントラストの維持」ではなくなります。かといって、ドットを間引けば「エッジの維持」ではなくなります。crisp-edges で、いったいどうやって縮小しろと言うのでしょう?

ここら辺の議論不足も、CSS3 から姿を消した理由のようです。


「ドット絵を拡大したい」と言う用途では、pixelated 指定が本命であるように思います。


復活

その後も「草案」は更新され続けました。


現在、一度は CSS4 に、と持ち越された image-rendering が、草案の上では復活します。

どうやら、2014年 9月 26日版から復活を遂げたようです。


内容としては、先に CSS4 の草案として書いた、 auto / crisp-edges / pixelated の3つが定められています。


しかし、その後も草案の域を出ず、なかなか勧告候補は作られません。

前回の勧告候補から、実に 7年半…やっと、2019年10月10日に、8番目の勧告候補が出されます。


扱える値としては auto / crisp-edges / pixelated で、草案のままです。

それぞれがどのような処理を行うのか、文面だけでなく図でも示され、間違った解釈が行われないように気を使っています。




7年半前は、勧告候補からドット絵の表示方法が消えただけでなく、ブラウザが乱立していて激しく混乱していました。

しかし現在は、ブラウザのシェアが大きく変わっています。


シェアが5割を超えていた IE は、Microsoft が「使わないように」と勧告する存在になりました。

後継として作っていた Edge ブラウザも、冒頭に書いたように、Chrome と同じ内部プログラムを使うように変更されました。

独自ブラウザだった Opera も Chrome と同じになった一方、同じプログラムを共有していた Safari と Chrome は、現在では違う道を進んでいます。とはいえ、双子の兄弟のようなものです。


このため、現在は「いまだに使われている」IE と、唯一独自の道を進んでいた FireFox だけが、「Chrome と違う」状態。冒頭にあげた CSS も、対応するために3行書かれています。

CSS3 は、まだ「勧告候補」にすぎず、標準ではありません。そのため、FireFox が他と違っていることに問題はありません。

しかし、遠くないうちに FireFox も勧告候補に従った対応を行うのではないかと思います。統一は目前です。

次ページ: JavaScript について


前ページ 1 2 3 次ページ

(ページ作成 2013-06-09)
(最終更新 2020-02-03)
第3版 …他の版 初版 2版

戻る
トップページへ

-- share --

6000

-- follow --




- Reverse Link -