利用者:Nova replet laetitia/sandbox/技術・情報/レンダリングエンジン

ここはNova replet laetitiaさんの利用者サンドボックスです。編集を試したり下書きを置いておいたりするための場所であり、百科事典の記事ではありません。ただし、公開の場ですので、許諾されていない文章の転載はご遠慮ください。

記事がある程度できあがったら、編集方針を確認して、新規ページを作成しましょう。

レンダリングエンジン (rendering engine) とは、レンダリングを行うソフトウェア部品。情報（データ）を読み込んで、特定のルールにしたがい適切な表現に変換する役割を担う。レイアウトエンジン (layout engine)、レンダラー (renderer) ともいう。記号学においては情報の「再生」にあたる。

デジタル情報のレンダリングエンジン

情報がデジタルデータの場合、適切にレンダリングを行うためには、レンダラーの書式（フォーマット）に従って保存されていることが必要となる。一般的には、データの名前やデータ中のヘッダーと呼ばれる部分に使用されるレンダラーへの利用や設定条件が記録されており、これがデータとともにレンダラーに渡される。

単機能機やスタンドアロンで使用など、利用が限定される場合はアプリケーション・ソフトウェア内部に組み込まれていることもある。しかしデータを共用したり共有することが一般的になっている、汎用性をもたせるために独立したライブラリとして提供されたり、ソフトウェアどうしの連携によって外部から利用されることもある。さらに、もともと異なるフォーマットで保存されたデータであっても対応できるよう、ある程度の互換性を備えるレンダラーもあるが、処理が大きくなることから消極的な実装にとどまったり、あるいはベンダーロックインを狙って実装されないこともある。

ファイラーの例

コンピュータにおいて、記憶装置中に格納されたある領域に羅列するデータ列が、書式に従ってデータの名前、形式、データの始まり、データの終わり、エラー訂正のための冗長情報などが書かれていれば、これを適切なレンダラーが読み込むことで、「ファイル」として認識することができる。この場合の書式はファイルシステムが定義しており、「ファイラー」がレンダリングエンジンとして機能している。

文字の例

データ列を人間が認識して文字として扱う場合もレンダリングが行われるが、主に　１）データ列の区切りを文字コードに置き換える　２）得られた文字列をフォントに対応させて表示可能な型式にする　というそれぞれの処理をレンダラーが行っている。

エンジンに実装されている文字コードの変換テーブルの違いによって、想定していた文字とは異なる文字として扱われてしまい、表示デバイスで意味不明の文字列が並んでしまうことがある。これは文字化けとして知られるが、ソフトウェア言語によっては制御文字として認識され、システムに影響を与えることが少なくない。これを悪用してHTMLコードやスクリプト言語のレンダラーに認識させて予期せぬ動作を引き起こすコンピュータウイルスが存在する。

画像の例

記号学における情報の再生では、文字は信号や記号などと同様に圧縮された視覚情報にあたる。圧縮がどのような規則によって行われているか、文字がどの発声やなんの語彙か表す知識が言語であるので、この規則を知らない（＝言語を知らない）者にとっての文字は画像としてしか認識されず、情報量として膨大になる。

画像をデータ列で扱う場合、膨大な情報は取扱にコストがかかるため、一般的には画像圧縮をかける。レンダラーにはこの圧縮方式への対応が実装される。

→「画像ファイルフォーマットの比較」を参照

一方で表示デバイスでは、データのさらに表示形式へのレンダリングが行われる。モニターの例では、データをグラフィックエンジンが画面に走査されるRGB要素で構成される表示用データに置き換える。この段階で、文字なども表示用データとして同等に扱われて区別がなくなる。置き換えられた表示用データからは、特殊な処理を行わない限り文字列データや画像データを取り出すことはできない。文字認識や画像認識は、この「特殊な処理」にあたる。

表示用データの準備を逐次的に行う処理が動画処理にあたる。また、逐次データを「視覚へのレンダリング」である「表示」ではなく「聴覚へのレンダリング」である「音響」に使うデータとする場合、これは音声処理にあたる。動画や音声などの逐次処理データは画像データ以上にさらに膨大なデータを高速で処理する必要があり、圧縮や展開、表示方法を含めて様々なレンダラーが存在し、高速処理の一部はハードウェアで実装するものが一般的である。

→「文字コード」を参照

印刷の例

データを人間の視覚へレンダリングする手段として、表示デバイスを用いる他に紙などの媒体へ印刷する方法がある。このとき、文字列の印刷だけであれば、文字や言語といった「圧縮された情報」を表示するだけであり処理や実現手段もそれほど複雑にはならない。しかし画像データとなると、圧縮されない膨大な情報を再生しなくてはならず、さらにWYSIWYGのように、まったく異なった手段でありながら、表示デバイスによる再生と印刷による再生は、視覚では全く同等であることが求められる。

解像度、色プロファイル、質感

仮想現実

脳内の人間の五感処理は視覚でほとんどを占める。したがって心理的影響が大きい。

五感へのレンダリング

視覚・聴覚以外に、嗅覚、味覚、触覚へのレンダリングの実装が試みられ一部は製品化もされている。しかしこれらの実現には電気的処理以外のシステム構築が必須となり（嗅覚・味覚では揮発性の化学的なレンダーが必要、触覚では接触刺激を再生する特殊なレンダーが必要になる）、製品化はほどとおい。

通信データの例

もともとデータを共用する目的の通信分野では、送信側と受信側にデータの不一致が起きないよう通信プロトコルが予め定められ、こちらは専用のハードウェアや通信ソフトウェアで実装される。デジタルデータの場合、レンダラーに渡すまでの基盤データを準備するシステムに相当するが、量子化されたデータの一部の変化や欠損のために、データ全体が意味消失にならないように冗長性をもたせたり誤り検出訂正を行った上でレンダラーにデータの渡して共有が行われる。一方で秘匿目的のためあえてデータを「一定の条件（暗号など）」のもとで撹乱（スクランブル）し、「一定の条件」を共有したレンダラーのみで使えるようにし、他のレンダラーで利用できないデータにすることも行われる。もともとソフトウェアで行われたこの種の実装は、リバースエンジニアリングを防ぐため独立したハードウェアで実装したり、これらを組み合わせた複雑な実装も行われる。後にはシステム機器どうしの通信にとどまらず、システム機器内部のデバイス間通信においても行われ、こうした機能の一部がレンダラーに実装されることがある（TPMなど）。このような多層化された通信では、レンダリングした結果の異常によって初めてようやく人間が障害の発生を認識できるため、障害原因の特定を難しくしている。

レンダラーの相互利用

多くのコンピューターで、レンダラーの出力をさらに別のレンダラーが連携で読み込み利用している。上記の例では「ファイラー」が出力した「ファイル」として認識されたデータをさらに別のレンダラーが利用する連携構造をとっている。