Photoshop のウェブへの移行

Photoshop のような複雑なソフトウェアをブラウザ内で直接実行するという考えは、ほんの数年前には想像もつかなかったでしょう。しかし現在、Adobe では、さまざまな新しいウェブ テクノロジーを活用することで、Photoshop のベータ版をウェブに導入しています。

Nabeel Al-Shamma
Nabeel Al-Shamma
Thomas Nattestad
Thomas Nattestad

Chrome はこの 3 年間、ブラウザの限界を押し広げようとするウェブ アプリケーションの強化に取り組んできました。そうしたウェブ アプリケーションの 1 つに Photoshop があります。Photoshop のような複雑なソフトウェアをブラウザ内で直接実行するという考えは、ほんの数年前には想像もつかなかったでしょう。しかし現在、Adobe では、さまざまな新しいウェブ テクノロジーを活用することで、Photoshop のベータ版をウェブに導入しています。

(動画ではなく、こちらで読む場合は、この記事を動画でご覧ください)。

ブラウザで実行されている Photoshop ウェブアプリ。キャンバスにゾウの画像が表示され、[選択ツール] メニュー項目が開いている。

この投稿では、このコラボレーションによる Photoshop のウェブへの拡張について、初めて詳しくお伝えします。Adobe で使用されているすべての API やその他の API をご自分のアプリで使用することもできます。ウェブ機能に関するブログ投稿からアイデアを得て、API トラッカーで Google が取り組んでいる最新の優れた API トラッカーをご覧ください。

Photoshop がウェブに進んだ理由

ウェブが進化しても変わらない点が 1 つあります。それは、ウェブサイトとウェブアプリがプラットフォーム固有のアプリケーションよりも優れているということです。これらの利点には、リンク可能、一時的なもの、普遍的であるなど、多くの独自機能が含まれますが、結局のところ、シンプルなアクセス、簡単な共有、優れたコラボレーションが実現します。

URL のシンプルな利点は、誰でもクリックしてすぐにアクセスできることです。ブラウザさえあればよい時代になったのです。アプリケーションをインストールする必要はありません。また、実行環境を気にする必要はありません。ウェブ アプリケーションの場合、ユーザーはアプリケーションやドキュメント、コメントにアクセスできます。そのため、ウェブは理想的なコラボレーション プラットフォームとなっており、クリエイティブ チームとマーケティング チームにとって、ますます不可欠なものとなっています。

Google ドキュメントは、このようなシンプルなアクセスの先駆者であり、ドキュメントを開始して他のユーザーにリンクを送信すると、アプリケーションだけでなく、特定のドキュメントやコメントにもすぐに移動することがいかに簡単か、ご存じのとおりです。それ以来、過去に紹介したアプリケーションなど、数多くの素晴らしいアプリケーションがこのモデルを採用し、このたび Photoshop にもメリットがもたらされるようになりました。

Photoshop がウェブに登場した経緯

ウェブは、当初はドキュメントのみに適したプラットフォームとしてスタートしましたが、その歴史の中で劇的に成長しました。Gmail のような初期のアプリでは、少なくとも、より複雑なインタラクティビティやアプリケーションが可能でした。それ以来、私たちは素晴らしい共同開発を目の当たりにしてきました。ウェブアプリが可能性の限界を押し広げ、ブラウザ ベンダーがウェブ機能をさらに拡張することで対応してきました。この好ましいループの最新のイテレーションにより、Web で Photoshop が使用可能になりました。

Adobe は以前、ウェブに SparkLightroom を導入し、Photoshop をウェブに導入することに長年関心を寄せていました。しかし、JavaScript のパフォーマンス上の制限、コードの適切なコンパイル ターゲットの欠如、ウェブ機能の欠如により、開発はブロックされました。では、こうした問題を解決するために Chrome に組み込まれた Chrome の機能について説明します。

Emscripten を使用した WebAssembly の移植

WebAssembly とその C++ ツールチェーンの Emscripten は、Photoshop をウェブに導入するための鍵となりました。これは、Adobe をゼロから構築する必要がなく、既存の Photoshop コードベースを活用できることを意味します。WebAssembly は、プログラミング言語のコンパイルターゲットとして設計された、すべてのブラウザに搭載されている移植可能なバイナリ命令セットです。つまり、C++ で記述された Photoshop などのアプリケーションを、JavaScript で書き換えることなく直接ウェブに移植できます。ご自身で移行を開始するには、Emscripten のドキュメント全体をご確認いただくか、ライブラリの移行方法に関するガイド付きの例をご覧ください。

Emscripten はフル機能のツールチェーンで、C++ を Wasm にコンパイルできるだけでなく、POSIX API 呼び出しをウェブ API 呼び出しに変換し、OpenGL を WebGL に変換する変換レイヤを提供します。たとえば、ローカル ファイル システムを参照するアプリを移植すると、機能を維持するために Emscripten がエミュレートされたファイル システムを提供できます。

Emscripten は以前から Photoshop のほとんどの部分をウェブに導入してきましたが、必ずしも十分な速度ではありませんでした。Google は継続的に Adobe と協力して、ボトルネックの場所を特定し、Emscripten を改善してきました。Photoshop はマルチスレッド処理に依存しています。WebAssembly に動的なマルチスレッド処理を導入することが重要な要件でした。

また、例外ベースのエラー処理は C++ では一般的ですが、Emscripten と WebAssembly では十分にサポートされていませんでした。Google は、W3C の WebAssembly コミュニティ グループと協力して、WebAssembly 標準とそれに関連するツールを改善し、WebAssembly に C++ 例外を導入しました。

Emscripten は大規模なアプリケーションだけでなく、ライブラリや小規模なプロジェクトを移植できます。たとえば、Emscripten を使用してウェブに一般的な OpenCV ライブラリをコンパイルする方法をご覧ください。

最後に、WebAssembly は、ウェブアプリのパフォーマンスを劇的に改善する SIMD 命令などの高度なパフォーマンス プリミティブを提供します。たとえば、Halide は Adobe のパフォーマンスに不可欠ですが、SIMD は平均で 3 ~ 4 倍の高速化を実現し、場合によっては 80 ~ 160 倍の高速化を実現しています。

WebAssembly のデバッグ

大規模なプロジェクトを成功させるためには、ジョブに適したツールが必要です。Chrome チームはこうした理由から、充実した WebAssembly デバッグ サポートを開発しました。ソースコードのステップ実行、ブレークポイントの設定、例外での一時停止、豊富な型サポートによる変数検査、さらには DevTools コンソールでの評価の基本もサポートされています。

DevTools での WebAssembly デバッグで、コード内にブレークポイントを表示してステップ実行できるようにする。

WebAssembly デバッグの利用に関する公式ガイドをご確認ください。

ハイ パフォーマンス ストレージ

Photoshop ドキュメントのサイズを考えると、ユーザーの移動に合わせてディスク上のデータをメモリ内へ動的に移動する機能が Photoshop に不可欠なものとなっています。他のプラットフォームでは、通常、mmap によるメモリ マッピングを介してこれを実現できますが、ウェブではパフォーマンスの高い方法がありませんでした。つまり、オリジンのプライベート ファイル システム アクセス ハンドルが開発され、オリジン トライアルとして実装されるまででした。この新しい API の活用方法については、こちらのドキュメントをご覧ください。

キャンバスの P3 色空間

従来、ウェブの色は sRGB 色空間で指定されてきました。sRGB は 90 年代半ばの標準であり、陰極線モニターの性能に基づいています。カメラとモニターは、この四半世紀の間に大きな進化を遂げ、より大規模で高性能な色空間が標準化されてきました。最新の色空間で最もよく使われているのは、Display P3 です。Photoshop では Display P3 Canvas を使用して、ブラウザ内でより正確に画像を表示します。特に、明るい白、明るい色、シャドウの細部を含む画像は、Display P3 データをサポートする最新のディスプレイで可能な限り最高の状態で表示されます。Display P3 Canvas API は、ハイ ダイナミック レンジ表示を可能にするために、さらに構築中です。

ウェブ コンポーネントと Lit

Photoshop は大規模で機能豊富なアプリケーションで有名なアプリケーションで、多数のワークフローをサポートする数百の UI 要素があります。このアプリは、複数のチームがさまざまなツールと開発手法を使用して構築していますが、さまざまな部分がまとまって、パフォーマンスの高い全体を構成する必要があります。

この課題を解決するため、Adobe は Web ComponentsLit ライブラリを採用しました。Photoshop の UI 要素は、Adobe の Spectrum Web Components ライブラリから取得されます。Spectrum Web Components は、Adobe デザイン システムの軽量かつ高パフォーマンスの実装であり、あらゆるフレームワークに対応するか、フレームワークを一切使用しません。

さらに、Photoshop アプリ全体が Lit ベースの Web Components を使用して構築されています。ブラウザの組み込みコンポーネント モデルと Shadow DOM のカプセル化により、チームは他の Adobe チームが提供する React コードの「アイランド」を簡単に統合できることがわかりました。

Workbox を使用した Service Worker のキャッシュ保存

Service Worker はプログラム可能なローカル プロキシとして機能し、ネットワーク リクエストをインターセプトし、ネットワークからのデータ、長期保存キャッシュ、またはその両方で応答します。

V8 チームによるパフォーマンス向上の取り組みの一環として、Service Worker がキャッシュに保存された WebAssembly レスポンスで初めて応答すると、Chrome は最適化されたバージョンのコードを生成して保存します。これは Photoshop コードベースで一般的な数メガバイトの WebAssembly スクリプトの場合も同様です。Service Worker の install ステップJavaScript がキャッシュに保存された場合にも、同様のプリコンパイルが行われます。どちらの場合も、Chrome では、実行時のオーバーヘッドを最小限に抑えながら、キャッシュに保存されたスクリプトの最適化されたバージョンを読み込んで実行できます。

Photoshop on web では、この機能を利用するために、JavaScript や WebAssembly のスクリプトの多くを事前キャッシュする Service Worker がデプロイされます。これらのスクリプトの URL はビルド時に生成され、またキャッシュを最新の状態に保つロジックは複雑になる場合があるため、同社はビルドプロセスの一環として Service Worker を生成するために、Google が管理する一連のライブラリ Workbox を利用することにしました。

Workbox ベースの Service Worker と V8 エンジンのスクリプト キャッシュにより、パフォーマンスは目に見えて向上しました。具体的な数値はコードを実行するデバイスによって異なりますが、チームはこれらの最適化により、コードの初期化に要する時間を 75% 削減したと推定しています。

ウェブ版 Adobe の今後の対応

Photoshop ベータ版のリリースはリリースの始まりにすぎません。現在、Photoshop のパフォーマンスや機能の改善を進めており、ベータ版後の正式リリースに向けてすでに準備を進めています。Adobe は Photoshop にとどまらず、Creative Cloud をウェブに積極的に展開し、クリエイティブ コンテンツ制作とコラボレーションの両方のための主要プラットフォームにする予定です。これにより、初めて動画を制作する何百万人ものクリエイターが自分のストーリーを伝え、ウェブ上の革新的なワークフローからメリットを享受できるようになります。

Adobe が可能性の限界に挑み続けるなか、Chrome チームは協力を継続し、Adobe と活気に満ちたウェブ デベロッパー エコシステム全般のウェブを推進していきます。こうした最新のブラウザ機能は他のブラウザにも追い付いており、Adobe も同社製品を利用できるようにすることを期待しています。今後もウェブをさらに進化させていくため、今後の最新情報にご期待ください。

ウェブ(ベータ版)で Photoshop にアクセスする方法について詳しくは、Adobe ヘルプセンターをご覧ください。