[インデックス 15598] ファイルの概要

このコミットは、Go言語の標準ライブラリである image/jpeg パッケージ内の src/pkg/image/jpeg/scan.go ファイルに対する変更です。このファイルは、JPEG画像のデコード処理、特にスキャン（走査）の管理とプログレッシブJPEGの係数処理を担当しています。

コミット

• コミットハッシュ: 0d9bf2757e71e64938b02c397d1d6e5666c5a213
• Author: Nigel Tao nigeltao@golang.org
• Date: Wed Mar 6 10:08:46 2013 +1100
• コミットメッセージの要約: image/jpeg: for progressive JPEGs, the first SOS segment doesn't necessarily contain all components.

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/0d9bf2757e71e64938b02c397d1d6e5666c5a213

元コミット内容

image/jpeg: for progressive JPEGs, the first SOS segment doesn't
necessarily contain all components.

Fixes #4975.

R=r, minux.ma, bradfitz
CC=golang-dev
https://golang.org/cl/7469043

変更の背景

このコミットは、Go言語の image/jpeg パッケージにおけるプログレッシブJPEG画像のデコードに関するバグ（Issue #4975）を修正するために行われました。

問題の核心は、プログレッシブJPEGの最初のSOS (Start of Scan) セグメントが、必ずしもすべての画像コンポーネント（Y, Cb, Crなど）の情報を含んでいるとは限らないという点にありました。従来のデコーダの実装では、最初のSOSセグメントがすべてのコンポーネントを定義していると仮定していたため、一部のプログレッシブJPEGファイルで「index out of range」エラーが発生していました。これは、d.progCoeffs 配列が、存在しないコンポーネントのインデックスにアクセスしようとした際に発生する可能性がありました。

この修正は、デコーダがプログレッシブJPEGの特性を正しく理解し、SOSセグメントで定義されていないコンポーネントに対して不適切な初期化やアクセスを試みないようにすることで、堅牢性を向上させることを目的としています。

前提知識の解説

JPEG画像フォーマット

JPEG (Joint Photographic Experts Group) は、主に写真などの連続階調画像を圧縮するための標準的な方法です。JPEGは、離散コサイン変換 (DCT) を使用して画像を周波数領域に変換し、高周波成分を量子化することで非可逆圧縮を行います。

プログレッシブJPEG

通常の（ベースライン）JPEG画像は、上から下へ順にデコードされ、表示されます。これに対し、プログレッシブJPEGは、画像を複数回に分けてエンコード・デコードする方式です。最初のパスでは低品質の画像が表示され、その後のパスで徐々に詳細が追加されていき、最終的に高品質な画像が表示されます。これは、特に低帯域幅のネットワーク環境で、ユーザーに素早い視覚的フィードバックを提供するために有用です。

プログレッシブJPEGは、複数の「スキャン」で構成されます。各スキャンは、画像の特定の周波数帯域やコンポーネント（輝度Y、色差Cb、Cr）のデータを伝送します。

SOS (Start of Scan) セグメント

JPEGファイルは、様々なマーカー（セグメント）で構成されています。SOS (Start of Scan) セグメントは、実際の画像データ（エントロピー符号化されたデータ）が始まることを示すマーカーです。SOSセグメントには、そのスキャンでどのコンポーネントが使用されるか、およびそのスキャンに適用されるスペクトル選択や逐次近似のパラメータが含まれます。

重要なのは、プログレッシブJPEGでは、最初のSOSセグメントが必ずしもすべてのコンポーネントのデータを一度に含んでいるわけではないという点です。例えば、最初のスキャンでは輝度成分（Y）のみの低周波データが送られ、その後のスキャンで色差成分（Cb, Cr）や高周波データが追加されることがあります。

image/jpeg パッケージ (Go言語)

Go言語の image/jpeg パッケージは、JPEG画像をエンコードおよびデコードするための機能を提供します。このパッケージは、JPEG標準に準拠したファイルの読み書きを可能にし、Goアプリケーションで画像処理を行う際の基盤となります。デコード処理では、JPEGファイルの構造を解析し、SOSセグメントなどのマーカーを読み取り、圧縮された画像データを復元します。

技術的詳細

このコミットの技術的詳細は、プログレッシブJPEGのデコードロジックにおける d.progCoeffs の初期化とアクセスに関するものです。

d.progCoeffs は、プログレッシブJPEGのデコード中に、各コンポーネントのDCT係数ブロックを保持するためのスライス（または配列）です。プログレッシブJPEGでは、画像データが複数のスキャンに分割されて送られてくるため、各スキャンで受け取った係数を一時的に保存し、最終的な画像を構築するために使用します。

元のコードでは、d.progressive が true (プログレッシブJPEG) の場合、processSOS 関数内で、現在のSOSセグメントに含まれる nComp (コンポーネント数) のループを回し、各 compIndex に対して d.progCoeffs[compIndex] の領域を確保しようとしていました。

// 変更前
if d.progressive {
    for i := 0; i < nComp; i++ {
        compIndex := scan[i].compIndex
        // ここで d.progCoeffs[compIndex] が nil のチェックなしに
        // make([]block, ...) を呼び出そうとしていた可能性がある
        d.progCoeffs[compIndex] = make([]block, mxx*myy*d.comp[compIndex].h*d.comp[compIndex].v)
    }
}

問題は、nComp が現在のSOSセグメントで定義されているコンポーネントの数であるのに対し、compIndex は画像全体のコンポーネントインデックス（通常0, 1, 2など）であることです。もし最初のSOSセグメントがすべてのコンポーネントを含んでいない場合（例えば、輝度Yのみ）、scan[i].compIndex が指すインデックスが、まだ d.progCoeffs に対応するエントリが初期化されていない、あるいは存在しないコンポーネントを指す可能性がありました。これにより、d.progCoeffs[compIndex] が nil の状態でアクセスされ、make 関数に渡されるサイズ計算でパニック（index out of range）が発生する可能性がありました。

修正は、d.progCoeffs[compIndex] が nil である場合にのみ、そのコンポーネントの係数ブロックのメモリを割り当てるように変更しました。

// 変更後
if d.progressive {
    for i := 0; i < nComp; i++ {
        compIndex := scan[i].compIndex
        if d.progCoeffs[compIndex] == nil { // ここで nil チェックを追加
            d.progCoeffs[compIndex] = make([]block, mxx*myy*d.comp[compIndex].h*d.comp[compIndex].v)
        }
    }
}

この変更により、processSOS が呼び出された際に、現在のスキャンに含まれるコンポーネントについてのみ d.progCoeffs の初期化を試み、かつ既に初期化されている場合は再初期化を避けることができます。これにより、プログレッシブJPEGの最初のSOSセグメントがすべてのコンポーネントを含まない場合でも、デコーダが安全に処理を続行できるようになります。

コアとなるコードの変更箇所

--- a/src/pkg/image/jpeg/scan.go
+++ b/src/pkg/image/jpeg/scan.go
@@ -109,9 +109,11 @@ func (d *decoder) processSOS(n int) error {
 	myy := (d.height + 8*v0 - 1) / (8 * v0)
 	if d.img1 == nil && d.img3 == nil {
 		d.makeImg(h0, v0, mxx, myy)
-\t\tif d.progressive {\n-\t\t\tfor i := 0; i < nComp; i++ {\n-\t\t\t\tcompIndex := scan[i].compIndex\n+\t}\n+\tif d.progressive {\n+\t\tfor i := 0; i < nComp; i++ {\n+\t\t\tcompIndex := scan[i].compIndex\n+\t\t\tif d.progCoeffs[compIndex] == nil {\n \t\t\t\td.progCoeffs[compIndex] = make([]block, mxx*myy*d.comp[compIndex].h*d.comp[compIndex].v)\n \t\t\t}\n \t\t}\

コアとなるコードの解説

変更は src/pkg/image/jpeg/scan.go ファイルの processSOS 関数内で行われています。

1. if d.img1 == nil && d.img3 == nil { d.makeImg(h0, v0, mxx, myy) }: このブロックは、画像データがまだ初期化されていない場合に、画像の構造（d.img1 や d.img3 はそれぞれグレースケールまたはカラー画像のピクセルデータを保持する）を初期化します。この部分は変更されていませんが、プログレッシブJPEGのデコードフローの初期段階で実行される重要なステップです。

2. if d.progressive { ... } ブロック: このブロック全体がプログレッシブJPEGのデコードロジックを扱います。

   • for i := 0; i < nComp; i++: 現在のSOSセグメントで定義されているコンポーネントの数 (nComp) だけループします。
   • compIndex := scan[i].compIndex: 現在処理しているコンポーネントのグローバルなインデックスを取得します。
   • if d.progCoeffs[compIndex] == nil { ... }: この行が追加された主要な変更点です。 この条件文は、d.progCoeffs スライス内の、現在の compIndex に対応するエントリがまだ nil であるかどうかをチェックします。
     • もし nil であれば、そのコンポーネントのDCT係数ブロックを格納するためのメモリ (make([]block, ...)) を新しく割り当て、d.progCoeffs[compIndex] に設定します。
     • もし nil でなければ（つまり、既にメモリが割り当てられている場合）、何もせず、既存のメモリ領域を再利用します。

この nil チェックの追加により、デコーダは、プログレッシブJPEGの最初のSOSセグメントがすべてのコンポーネントを含んでいない場合でも、存在しないコンポーネントの progCoeffs エントリにアクセスしようとしてパニックを起こすことを防ぎます。これにより、デコード処理の堅牢性が向上し、より多様なプログレッシブJPEGファイルを正しく処理できるようになります。

関連リンク

• Go Issue #4975: https://code.google.com/p/go/issues/detail?id=4975 (現在はGoのIssueトラッカーがGitHubに移行しているため、直接アクセスできない可能性がありますが、情報源として重要です。)
• Go CL 7469043: https://golang.org/cl/7469043 (Go Code Reviewのリンク)

参考にした情報源リンク

• narkive.com - image/jpeg: index out of range in progress JPEG processSOS
• goissues.org - image/jpeg: index out of range in progress JPEG processSOS
• JPEG File Interchange Format (JFIF) (JPEGフォーマットの公式仕様書)
• Go Documentation: image/jpeg package (Go言語の image/jpeg パッケージの公式ドキュメント)