ブログ › iPhoneの写真がパソコンで開けない理由
iPhoneで撮った写真をパソコンに移したら拡張子が .HEIC で開けない。メールに添付しても相手が見られず、Webサイトのアップロード画面ではそもそも選択できません。よくある反応は「またAppleが変なことをした」ですが、事情は少し違います。
HEICは2つが組み合わさった名前です。外側のコンテナはHEIF、中でピクセルを圧縮するコーデックはHEVC(H.265)です。HEVCはもともと4K動画のために作られたコーデックですが、動画の1フレームをうまく圧縮する技術は写真1枚にもそのまま通用します。
結果は明確です。目で区別しにくい画質でJPEGの半分ほどの容量に収まります。128GBのiPhoneに写真を倍入れられるということです。Appleが2017年のiOS 11から標準フォーマットに切り替えた理由がこれです。
容量だけではありません。JPEGは色をチャンネルあたり8ビットでしか保存できませんが、HEICは10ビットを収められるので、空のグラデーションに階調の段差が出にくくなります。透明度にも対応し、1つのファイルに複数枚を入れられるのでLive Photosや深度情報もここに入ります。1992年に生まれたJPEGにはできないことです。
技術的に難しいからではありません。HEVCに特許料がかかるからです。
JPEGは関連特許がとうに失効しており、誰でも自由に実装できます。一方HEVCは複数の企業が分け持つ特許の塊で、しかも特許プールが1つに統合されてもいません。デコーダーを製品に入れるには複数の権利者と個別に交渉する必要があります。
ブラウザにとってこれは飲みにくい条件です。ChromeやFirefoxは世界中に無料で配布されており、利用者数に比例して特許料を払うとなると計算が合いません。オープンソースとして配布するのも難しくなります。そのため技術ではなくライセンスを理由に、対応しない道を選びました。
まとめると、Appleは自社のエコシステムの中では対価を払って問題を解決しましたが、写真がその外に出た瞬間、対価を払っていない世界と出会います。利用者の目には単に「iPhoneの写真が開けない」と映るだけです。
ChromeがHEICを知らないなら、デコーダーを持ち込めばいい。C言語で書かれたHEIFデコーダーをWebAssemblyにコンパイルし、ブラウザ内で実行する方式です。ブラウザがコーデックを知らなくても、ページがコーデックそのものを連れてくれば済みます。
ただしこのデコーダーは圧縮しても1MBほどあります。すべての訪問者に前もってこれをダウンロードさせるのは無駄です。10人中9人はページを眺めて去っていくのですから。そこで順序をこう組みました。
写真自体はどこにも送信されません。デコードからJPEGへの保存まですべてブラウザ内で完結します。人物写真や書類の撮影データを他人のサーバーに置かなくて済むということです。
使っているデコーダー libheif は LGPL-3.0 ライセンスです。GPLほど強くはありませんが、条件が1つ付きます — 利用者がこのライブラリを自分で改変した版に差し替えられなければならないという点です。
バンドラーをそのまま回すとこの条件が崩れます。ライブラリのコードがアプリのコードと混ざって1つのファイルに圧縮されると、その中からlibheifだけを選んで差し替える方法がなくなるからです。そのためこのファイルだけはバンドルに入れず、原本のまま別の場所に置いて実行時に読み込みます。最小化も名前の変更もしません。
意図せず混ざり込むのを防ぐため、ビルド後の検査も入れてあります。アプリのチャンクの中にlibheifの内部関数名が現れたら失敗とみなします。ライセンス遵守は一度守って終わりではなく、確認し続ける類のことなのだと分かりました。
できます。iPhoneの設定 → カメラ → フォーマットで「互換性優先」を選べば、それ以降はJPEGで保存されます。撮った写真をすぐ他人に送ることが多いなら、こちらのほうが気楽です。
その代わり保存容量は倍かかります。どちらが良いかは使い方次第です。普段はHEICのままにしておき、人に送るときだけ変換する方法が、容量と互換性のあいだで最も損の少ない折衷案です。
今あるHEIC写真を変換するなら
アップロードなしで端末内でJPG・PNG・WebPに変換します。