ハクソク

世界を動かす技術を、日本語で。

なぜJPEGが今もウェブを支配しているのか (2024)

342日前原文(spectrum.ieee.org)

概要

JPEGは30年以上にわたりWebの主要画像フォーマット。 GIFに取って代わった理由は、標準化と劣化特性。 JPEGの標準化は多くの企業の協力によるもの。 DCT圧縮による高効率と柔軟性が特徴。 特許問題もあったが、最終的に広く普及した経緯。

JPEGがWeb標準となった理由

  • JPEG は約30年間、Webの主流画像フォーマットとして利用され続けてきた歴史。
  • 最初のグラフィカルWebブラウザ NCSA Mosaic は、当初JPEGをサポートせず、 GIF を主に使用。
  • JPEG はGIFよりも画像の劣化が緩やかで、拡大縮小や高品質保持に優れる特性。
  • アニメーション非対応ながらも、 プロフェッショナル写真 にも十分な品質を実現。
  • インターネット普及初期、 画像の劣化特性 が特に重要視された背景。

GIFとJPEGの標準化の違い

  • GIF は 事実上の標準（デファクトスタンダード） であり、個人主導で開発。
  • JPEG は 公式な国際標準 として、多数の関係者による合意形成で策定。
  • GIFの開発者 Steve Wilhite の発音論争（"JIF" vs "GIF"）が話題となった逸話。
  • GIFは簡単な仕様文書で普及したが、 JPEGは600ページ超の詳細な標準書 が存在。
  • 標準化による相互運用性と普及の違い。

JPEG標準策定の経緯

  • Joint Photographic Experts Group が多様な企業・団体と協力し開発。
  • IBM、AT&T、Canon などが各自の用途（印刷、データ通信、写真）を持ち寄り、標準化を推進。
  • 初期のJPEG対応は OS/2 （IBM製OS）で実現。
  • 標準化により、 高品質画像の共有と普及 が加速。

JPEGの圧縮技術と特徴

  • JPEGの特徴は 離散コサイン変換（DCT） による 不可逆圧縮。
  • DCTは1970年代に開発され、画像の細部を削除しつつ全体像を維持する技術。
  • 圧縮率を上げても 写真らしさを保ちやすい 特性。
  • JPEG標準は 複数の圧縮モード を提供：
    • 順次DCT ：画像を上から順に表示
    • プログレッシブDCT ：低解像度から徐々に詳細追加
    • 順次ロスレス ：圧縮せずに画像を表示
    • 階層モード ：複数モードの組み合わせ
  • テクスチャや複雑な領域 では圧縮の劣化が目立ちにくいが、 単色や急な色変化 ではノイズが出やすい。

他フォーマットとの比較と用途

  • PNG は 非可逆圧縮 で、テキストや図に強み。
  • PNGの圧縮技術 DEFLATE は Phil Katz による開発で、特許問題回避のため採用。
  • JPEG は写真共有に最適だが、すべての用途に万能ではない点に注意。

JPEGと特許問題

  • 1990年代、 Unisys がGIFの特許使用料請求を開始し、 JPEGやPNG が普及。
  • JPEGも特許問題に直面し、 Compression Labs の特許を Forgent Networks が取得し訴訟を展開。
  • 100億円以上 のライセンス収入を得るも、2007年に特許失効。
  • 特許訴訟の影響はあったが、 JPEGの普及には大きな障害とならなかった。

まとめ

  • JPEG は標準化と技術的優位性によりWeb画像の主役となった歴史。
  • 多様な企業の協力と標準化プロセスが、 長期的な普及と信頼性 を支えた要因。
  • 特許問題 を乗り越え、今もなお幅広く使われる画像フォーマットとして定着。

Hackerたちの意見

記事では本当の問題が軽く触れられてるだけだね。ブラウザ以外での.webpファイルのサポートは、めっちゃ低いから。だからJPEGがまだまだ王様で、これからも長い間そうだと思うよ。

└

webpをダウンロードしてファイルを見るためには、変換しないといけないんだよね。モバイル以外の基本的な画像ギャラリーではほとんど機能しないし。

└

WebPは結構広くサポートされてると思うよ。少なくともWindowsでは、エクスプローラーがサムネイルを表示してくれるし、ペイントでも開けるし、Paint.NETみたいな他のエディターもサポートしてる…しばらくWebPをサポートしてないソフトウェアには出会ってないな。

└

人気のブラウザには新しいJPEG XLフォーマットのサポートが欠けてるね。

└

例えば、DaVinci Resolve。YouTubeやTikTok用の動画を作る人たちにすごく人気だけど、2025年になってもwebpには対応してないんだ。トレンドの話題についてコンテンツを作る時、マーケティングサイトが画像にwebpを使うことが多いから、これが問題になるんだよね。

圧縮もすごいけど、JPEGは実装がうまくいけば超速いんだよね。60fps以上で1080pを単一のCPUコアでエンコードできる画像フォーマットは他に知らない。これを実現するには軽いSIMDの使用だけで済むし、専用ハードウェアがあればエンコード/デコードのコストはすぐにゼロに近づく。ネットワークがどんどん速くなってる中で、他のロスィ画像フォーマットの正当性を理解するのが難しい。計算の観点から見ると、JPEGに勝るものは本当に難しいよ。今やスマホで100Mbpsの速度が出る日常の中で、ブロック内空間予測みたいな余計なステップが本当に価値があるのか疑問だね。

└

https://news.ycombinator.com/item?id=44298656 あなたのスマホが100Mbps出てるかもしれないけど、アメリカの中でも多くの人がその四分の一にも達するのに苦労してるよ。

└

その通り！ホバークラフトがあるのに、どうしてまだ車輪を使ってるのかって聞いてるようなもんだよね。もし人類が千年後も生き残ってたら、JPEGを使ってるだろうし、その千年後も使い続けてると思う。うまくいくものは、なかなか消えない傾向があるよね。

└

だから、LLMが思ったほど変わらないって自信を持って言えるんだ。20年以上も検索エンジンがあるのに、今でも簡単な検索すらしない人がいるからね。（それか、ただの釣りかも。どっちか決められないけど。）だから、あと20年待っても、日常の質問にLLMを使わない人はいると思うよ。君の（間違った？）質問に答えると、利点はたくさんあるけど、HDRとストレージ効率が特に大きいと思う。特にストレージ効率はすごいよ、大きな画像の場合は特にね。

└

透明性？HDR？ロスレスの適切なサポート？JPEGには足りないものがたくさんあるよね。

└

ネットワークがどんどん速くなってるのに、他のロスのある画像フォーマットの正当性が理解できない。GoogleのPageSpeedやLighthouseはWebPを使うように言ってるし、多くの開発者はSERPの順位を上げるためにGoogleの言うことを何でもやるんだよね。 - https://web.dev/articles/serve-images-webp - https://developer.chrome.com/docs/lighthouse/performance/use...

記事は好きだけど、一つ大事なポイントを見落としてるね。JPEGフォーマットは固定されてるけど、エンコーダーはまだ進化してるんだ！ よりスマートな量子化や、より良い知覚モデル、高精度の数学の進歩によって、どこでもサポートされているフォーマットを維持しながら、より高い圧縮率を達成できるようになってる :)

└

あなたが考えてるのはjpegliのことかな？これが実際にどれだけの違いを生むか、知ってる？

└

それは本当だけど、限界もあるよね。DEFLATみたいなもんだ。確かに、Zopfiのような非常に高度な圧縮ツールがあって、もっと良い圧縮率を得られるけど、Zstdもあって、そっちの方が圧縮率と速度が簡単に良くなるんだよね。

今の人たちはどうやって画像や写真を保存してるんだろう？ 動画には明確な勝者 - av1 - がいるけど、画像のエンコーディングに関しては「これが未来だ！」っていうものが見当たらない。JPEGは…古いし、それが目立つよね。ファイルサイズがちょっと膨れがちだけど、現代のストレージではそれほど大きな問題じゃない。けど、品質はあまり良くない。JPEG-XLは次の論理的なステップだと思ったけど、Googleがそのサポートを持ちながらも潰しちゃったから、実質的に死んじゃったね（独占企業が決定を下すのって本当に嫌だよね？）HEICはいいけど、Appleのエコシステムから絶対に出ないって約束しないといけない。要するにHEICは最悪。AVIFは計算コストが高いし、サポートもバラバラだね。8bitのyuv420は動くかもしれないけど、10bやyuv444はよく動かない。Windows 10もこれにはかなり苦しむし。WebPみたいな代替はブラウザにはいいかもしれないけど、デスクトップではほとんど使えないし、サポートも不安定。PNGは安いしサポートも広いけど、ファイルサイズがすぐに膨れ上がる。じゃあ、残された選択肢は？ .HEICの写真がたくさんあるけど、それを含むフォルダを開くとWindowsエクスプローラーが数分間フリーズしないでほしい。JPEGはまだ唯一の良い選択肢なの？ それとも、JPEG-XLやAVIFでエンコードして、未来が良くなることを祈るのが合理的な賭けなのかな？

└

今の人たちはどうやって画像や写真を保存してるんだろう？まあ、JPEGでしょ？なんでダメなの？Photoshopや他のソフトで品質スライダーをいじらなければ、品質は十分だよ。「もっと」必要なら、ロスレスのカメラRAWフォーマットやPSDみたいな大きな画像フォーマットもあるし、JPEGで全然問題ないよ。

└

普通の人はJPEGを使うよ。それで十分だし、DVDにとってのMPEG-2みたいなもんだ。互換性は常にストレージ効率よりも優先される。写真好きな人たちは、触らないRAW画像を宗教的に保存してるけど、それはコンプライアンス記録みたいなもんだよ。

└

動画には明確な勝者がいるように - av1 - 画像のエンコードに関しては「これは明らかに未来だ、少なくとも数年間は」っていうものがないみたいだね。何言ってるの？インターネットをランダムにスキャンすれば、av1よりもMP4やH.264形式の動画が圧倒的に多いことがわかるよ。ストリーミングサービスが切り替えたかもしれないけど、普通の消費者が映画を作ったり保存したりする時には、そういうのはあまり使われてないよ。

└

見た感じ、WebPがJPEGの代わりとして一番強い候補だと思う。例えば、インディーゲームのシーンでは、JPEGのゲームをWebPに再エンコードして、画像品質を向上させたり、インストーラーのサイズをかなり（25％以上）節約したりするのが普通だよ。サポートは少しずつ進んでるけど、まだ遅いかな。Ubuntu 22では結構ひどかったけど、Ubuntu 24ではいくつかのアプリがサポートを追加したみたい。Windows 11でもPhotosやPaintでWebPがサポートされてるよ。

└

今の人たちはどうやって画像や写真を保存してるんだろう？僕は高解像度のグラフィック作品をTIFF（BMP + LZW）で持ってたんだけど、スペースを節約するためにJPEG-2000（ロスレスモード）を使ってアーカイブしたんだ。J2k Photoshopプラグイン（https://www.fnord.com/）を使ってね。かなりのGBを節約できたよ。マルチプラットフォームで広くサポートされていて、アーカイブフォーマットとしても認識されてるから、デジタルプラットフォームでの寿命もある程度保証されてると思う。最近はHEIFやJPEG-XLも試してみたけど、これらのフォーマットはCMYKカラーモードにうまく対応してないんだよね。

└

JPEG-XLは次の論理的なステップに見えたけど、GoogleがそのサポートをChromeに持っていたのに、結局それを潰しちゃったから、実質的に死んじゃったよね（独占企業が決定を下すのって本当に嫌だよね？）FirefoxはJPEG-XLを採用する意向があるみたいだけど[1]、rustの実装[2]が成熟すればすぐにでも対応するって。で、そのrust実装はC++のリファレンスから直接移植されたもの[3]なんだ。Mac OSとSafariはすでにJPEG-XLをサポートしてるし[4]、最近WindowsもJPEG-XLのサポートを追加したよ。今のところのブロッカーはFirefox、Chromium、Androidだけ。もしFirefoxがJPEG-XLを採用すれば、Googleもそれに続く可能性が高いと思う。だから、JPEG-XLが採用されるのを見たいなら、rustの実装[2]にエンジニアリングの時間を投資して、リファレンス実装と同じ機能を持たせる手助けをしてみて。 ----- 1. https://github.com/mozilla/standards-positions/pull/1064 2. https://github.com/libjxl/jxl-rs 3. https://github.com/libjxl/libjxl 4. https://www.theregister.com/2023/06/07/apple_safari_jpeg_xl/ 5. https://www.windowslatest.com/2025/03/05/turn-on-jpeg-xl-jxl...

└

HEICはいいけど、Appleのエコシステムから絶対に出ないって約束するならね。つまり、HEICは微妙。HEICはMPEGの人たちが開発したもので、ISOの標準だよ、ISO/IEC 23008-12:2022: * https://www.iso.org/standard/83650.html * https://en.wikipedia.org/wiki/High_Efficiency_Image_File_For... HEIC画像は一般的にITU-T H.265†（HEVC）の静止画だよ: * https://www.geeky-gadgets.com/heif-avc-h-264-h-265-heic-and-... OSのサポートにはWindows 10 v1083、Android 10以上、Ubuntu 20.04、Debian 10、Fedora 36が含まれてる。多くのカメラやスマホも対応してるし、Apple特有のものじゃないよ。AppleはH.265のライセンスを取得したから、HEICを「無料」で手に入れて、JPEGよりもHDRや>8ビットカラーをサポートするからデフォルトの画像フォーマットとして使ってるんだよ。†WebPがVP8動画の画像/フレームに似てるみたいに。

└

アーカイブするならTiffがいいし、元々がrawかtiffならね。その他はJPEGで十分。もしファイルがすでにJPEGなら、新しい高品質フォーマットに変えても意味ないよ。品質はそれ以上にはならないし。古いかもしれないけど、どこにでもあるからね。最先端の技術よりも、20年以上後に開ける可能性の方が気になる。ストレージは安いし、プレゼンテーションは別の問題だから、元のファイルを保存するフォーマットとは違う形式にするべきだと思う。

└

PNG画像はファイルサイズを抑えるためにロスのある圧縮ができることを忘れがちだよね。JPEGほどではないけど、かなり効果的だよ。 https://pngmini.com/lossypng.html https://pngquant.org/ https://css-ig.net/pinga

└

macOSやLinuxを使ってるときは、最新の画像フォーマットに全く問題ないよ。Windowsは使わない方がいいかもね。

これを聞くと、ウェブページの目標が1MB未満だった頃を思い出すなぁ。その時、PNGを使う理由って透明度が必要な時だけだったし、JPEGの可変圧縮はすごく重要だったよね。Photoshopでは、画像を選んで必要なファイルサイズを指定すれば、JPEGの品質がデザインの制約に合わせて落ちてくれたんだ。

JPEGのすごいところは、30年経ってもまだ後方互換性のある圧縮改善が続いてることだね。Mozjpegはもう有名だけど、Jpegliは去年発表されたばかりで、高ビットレートでさらに良い結果を出してる[1]。古いJPEGがさらに改善されているのを見ていると、新しいフォーマットを採用したくなくなるよね。[1] https://opensource.googleblog.com/2024/04/introducing-jpegli...

└

人間の視覚的な好みじゃなくて、コンピュータビジョン処理に特化した圧縮の最適化を見てみたいな。つまり、特定のファイルサイズで画像をできるだけきれいに見せるのではなく、コンピュータビジョンのタスクパフォーマンスを向上させることが目標になるってこと。例えば、その画像で分類器やセグメンテーションモデルを実行して、モデルの予測の正確さを評価する感じ。特定のファイルサイズでモデルの精度が高いほど、圧縮アルゴリズムは優れてるってことだよね。追記：これ、実際にやられてるよ。https://www.ecva.net/papers/eccv_2020/papers_ECCV/papers/123... Jinyoung ChoiとBohyung Hanによる「JPEG画像圧縮のためのタスク対応量子化ネットワーク」。ECCV 2020

JPEGはただ動くからね。決して最高ではないけど、みんながサポートしてるし、サポートが悪くなったり、複雑さが増したり、余計な処理をするために数バイトを節約する価値はあまりないと思う。ロスのある圧縮画像は、通常、帯域幅やディスクスペースを最も消費するものではないし、動画がそれに当たるんだ。だから、動画フォーマットにもっと注目が集まってるのはそのためだよ。静止画像よりも得られるものが多いからね。JPEG-XLはすごく複雑で、ほとんどの人が本当に必要としない機能をたくさんサポートしてる。WebPはGoogleに支えられてるから、少しはサポートが良いけど、実質的には単一フレームの動画みたいなもので、動画（重要なところ）で頑張ったら、画像もほぼ無料で得られるし、Googleにとってはほんの少しの帯域幅を節約できる。それがGoogleのスケールでは「ほんの少し」でも大きいんだよね。音声でも同じことが起きてる。MP3（1991年）は今でも非常に人気で、他はほとんどM4A/AAC（2001年）だ。今や完璧な音声フォーマットであるOpus（2012年）があるのに、他のフォーマットが十分良いから、あまり使われてないんだよね。

└

Opusは裏方で使われてることもあるよね。確かDiscordがOpus使ってるし、YouTubeも結構変わった音声コーデック使ってる。だけど、誰もOpusファイルを自分のコンピュータに保存しないよね。

└

Opusはちょっと複雑すぎる。確か、完全な実装は1つだけだったはず。

「webpは今や良いブラウザサポートがあるから普及すべき」っていう意見をよく聞くけど、それだけじゃ画像フォーマットが広く受け入れられるには不十分だよ。人々はどこでも画像を開けることを望んでるし（スマートTVで写真を見るのはどうするの？古いタブレットは？デジタルフォトフレームは？）。また、どんなプログラムでも画像を編集したいと思ってる（このFOSSエディタはどうするの？サブスクリプション前のPhotoshopを使ってる人たちは？）。さらに、JPEG2000やWebPが消えてしまうかもしれない未来でも、大切な写真にアクセスできることを保証したいんだ。だって、webpはGoogleが作ったもので、彼らが大々的に宣伝したものがどれだけ死んでるか知ってるから…

└

だって、webpはGoogleが作ったもので、彼らが大々的に宣伝したものがどれだけ死んでるか知ってるから… この主張は理解できないな。WebPはアルゴリズムであって、サービスじゃないから、公開されたらそれを殺すことはできないよ。

└

webpを使うのは好きじゃない。特にChromeがあらゆるものに押し付けてくるのに、Googleの他のツール、例えばSlidesはサポートしてないのが超イライラする。特にGoogleが開発したのにね。

└

これ、錆びを思い出させるな。10年や20年後に錆びが広まっても、C++が本当に置き換わることはないと思う。COBOLがあんなに長い間生き残ってる理由をエンジニア的に説明してほしいな。どんな技術も永遠には生きられないから。

└

今じゃwebpはどこでもサポートされてると思うよ。単に慣性だと思う。

└

でも、それだけじゃ画像フォーマットが広く採用されるには全然足りないよ。WEBPをかなり使ってるけど、WEBPには大きな欠陥がある。ロスありとロスなしの両方ができるってこと。それって画像圧縮フォーマットとしては最もアホなことだと思う。こんなバカな選択がなぜなされたのか、混乱と無知のレベルが理解できない。WEBPがロスありかロスなしかを判断して分類するためのプロセスを持ってるんだ。昔はJPGやPNGがあって、生活は良かった。シンプルで簡単だったのに、アホな奴らがロスありとロスなしを同じ傘の下に押し込むのが理にかなってると思ったんだ。> 彼らはJPEG2000やWebPのようなフォーマットが消えてしまうかもしれない未来でも、自分たちの大切な写真にアクセスできることを保証したいんだ。でも、それは問題にはならないよ。今でもDOS時代の古いマイナーなフォーマットを開けるし、当時はごく限られたソフトウェアだけが使ってたカスタムフォーマットでもね。エミュレーターやコンバーターもあったし、全部オープンソースだし。将来的に古いWEBPファイルを開くのは全然問題じゃない。非技術的なユーザーにとって、ロスありかロスなしのWEBPを判断するのは… ; )

└

JPEG XLはwebpより優れてるよ。

└

最後にチェックしたとき、GitHubやTelegramに.webp画像をアップロードできなかったよ。GitHubでは、.pngに名前を変えればコンテンツ検出で動くけど、まあ、そんな感じ。

└

それに、ほとんどの人がwebpを使うときは、元々JPEGだった画像の強制再圧縮版を見てるから、あんまり良い印象がないよね。しかも、比較的低品質の設定で。

確かにJPEGより優れたフォーマットはたくさんあるけど、JPEGの一番大事な特徴は交換可能であることだってことを理解しないとね。新しいウェブブラウザが何をサポートしてようが、JPEGはどこでもサポートされてると見なされてるし、実際、編集部はJPEG以外のものを受け入れないんだ。GoogleがWebPを強制するからって、みんなのワークフローを壊すわけにはいかないよ。ウェブブラウザはJPEGにとって実はあまり重要なプラットフォームじゃないし。今でもJPEGはその使命を完璧に果たしてるし、帯域幅が増えたおかげでファイルサイズがどれだけ大きくても問題ないんだよね。

└

確かにJPEGより優れたフォーマットはたくさんあるけど、webpはその中には入らないよね。

└

この記事では、500x500px以上の画像サイズではmozjpegがwebpをクリーンに打ち負かすって主張してるよ。だから、JPEGコンテナフォーマット内で得られるパフォーマンスや圧縮は、一般的に言われてるよりもずっと多いんだ。 https://siipo.la/blog/is-webp-really-better-than-jpeg 追記： https://opensource.googleblog.com/2024/04/introducing-jpegli... は、現代のJPEGエンコーダーに関しては実際に最高のものかもしれない。フォーマット内の8ビットカラースペースの「天井」を効果的に打破してるからね！

└

圧縮の領域でも似たようなことがあったよ。ZIPはその手のファイル移動のデファクト勝者って感じ。まあ、他のも使われてるけどね。pkzip 2.04が出たときにはもっと良いのがあったのに、結局30年経ってもまだZIPを使ってる。ZIPアルゴリズムは多くの画像フォーマットでも使われてるしね。

記事自体はまあまあ良いんだけど、一つだけ目立つ技術的な間違いがあってイライラする。「コサイン変換が強くなるほど、最終結果はより圧縮される」というのは単純に間違い。DCT（離散コサイン変換）とその逆変換は、「サンプル」と「周波数」ドメインの間で変換するもので、圧縮なしで完全に逆変換できるはずだよ（JPEGのやつは、サンプルと同じだけのビットがあればロスレスになるはず）。DCTベースの圧縮のコツは、高周波数から情報が消えても人間は気づかないってこと（自然画像では高周波数にデータがほとんどないことが多く、すぐにカットできる0がたくさんある）。だから、圧縮が強くなるほど、ストレージから高周波数データをもっと削除することができて、復元時にサンプルを再構築する時にあまり気にならないんだよ。でも逆に、サンプルデータに「シャープなエッジ」があると、シャープなエッジを再現するためにもっと高周波数が必要で、「リング」アーティファクトが出ないようにしないといけない（これが、テキストがあるときに高圧縮JPEGで周りにノイズのあるブロックが見える理由だよ。帯域幅が足りなくなって調整できなくなるから）。周波数ドメインの値や、圧縮がさまざまな周波数を削除する影響（フィルター画像の白黒）については、下のウィキペディアのフィルター比較の例の画像で示されているよ。（低周波数はフィルターとスペクトル画像の左上隅にあり、高周波数は右側に、より高い垂直周波数は下にある）。 https://en.wikipedia.org/wiki/File:DCT_filter_comparison.png https://en.wikipedia.org/wiki/Discrete_cosine_transform （主に「IDCTの例」セクションの下の方だけど、前のセクションも見てみて）。