PhotoShopユーザーの知人に
「PhotoShopのJPEG保存でのベースライン”最適化”オプションって何だか知ってる？」
と聞くと・・・
「画像を最適化してくれるんじゃないの？」
・・・・とか・・・・
「ファイルをPhotoShop用に最適化するから、ソフトによってはファイルが開けなくなると聞いた」
・・・・だのという回答が帰って来てオドロくことが結構多い。
誰が流したウワサか知らないが、両方ともハズレである!!
まず、”最適化”の有無で画像に変化があるかは、以下の手順で容易に確認できる。
1.テキトーな画像を用意する。（フォトショでテキトーに絵なり、線なりを描けば良い）
2.この画像を同じ画質段階（9/12とか）でベースライン”標準”とベースライン”最適化”とで2ファイル作成・保存する
（最適化.jpgと非最適化.jpgとかの名前で・・・・）
3.この2つのjpegファイルを再びフォトショで開いて、それぞれをBMPファイルで保存する
（Tiffでもいいが・・・これで、最適化有無でjpeg再生画像に差があればBMPファイルの画像データ部に反映されたはず）
4.コマンドプロンプトを開いて、DOSコマンドで2つのBMPファイルをバイナリ比較する
（fc /b とタイプして、間にスペースを挟んで2つのファイルをドラッグする）
と、結果はこうなる・・・・
”最適化”オプションは画像の表示には影響していないことがわかる。
・・・では”最適化”で何が違うのか、
今度はBMPではなく、JPEGファイルを比較してみる。
トーゼンだが、大量の相違点が報告される。
なお、コレをやる時はｆｃコマンドをEnterで実行開始直後にBreakキーを押さないと、先頭を見失う。
Breakが間に合わない人は、
fc /b c:￥最適化.JPG c:￥非最適化.JPG > c:￥FC_Result.txt
などとして、結果をテキストファイルに収納すればよい。
この相違点のアドレス情報を基にJPEGファイルをバイナリエディタでチェックして、具体的に何が違うのかを確認する。
なお、最近のバージョンではAPP1セグメント（FFE1マーカ）やPhotoshopセグメント（FFEDマーカ）の記載内容が
ベラボウに長くなっており、差異を紹介しにくいため今回の例では少々古いバージョンのフォトショを使用している。
（述べたいことの内容は基本的に新・旧バージョンで変わらない）
最適化.JPGのファイル先頭部分は
非最適化.JPGのファイル先頭部分は
ピンクで塗った部分が先のfc /bで検出した最初の差異アドレス（000000ED）と2番目のアドレス（000001CC）で、
緑塗りはこの範囲に存在するJPEGマーカである。
これにより、最初の差異はAPP13（FFEDマーカ）：Photoshopセグメント内に、
2番目の差異はDHT（FFC4マーカ）：ハフマン変換テーブルセグメント内に存在することがわかり、
同時にDQT（FFDBマーカ）：量子化係数やSOF0（FFC0マーカ）：ハフマン符号&DCTベースライン方式を表す
には差異がなく、これらセグメントが握る画質要素に違いが出ないことがわかる。
さて、最初の差異（アドレス000000ED）の意味はAPP13の記述仕様が不明のため、正確な所はわからない。
・・・が、どうやら画像の再生表示に対しては全く影響していない。
なぜなら、バイナリエディタで最適化.JPGのアドレス000000EDの値を16進01から、
非最適化.JPGと同じ16進00に書き換えてやっても問題なく同じ画像表示が得られる
からである。（BMPにしてfc /b比較して全く同じであることを確認）
2番目の差異はハフマン変換テーブルセグメント内にあるが、アドレス000001CCと次の000001CDはセグメントの長さをあらわす。
つまり、最適化.JPGのDHTセグメントは16進0074Byteに対して、非最適化.JPGのDHTセグメントは16進01A2Byteと大きい。
実際に双方のDHT領域（次のFFDAマーカ：画像データの開始位置まで）を抜き出して見ると・・・
最適化.JPGのDHT
非最適化.JPGのDHT
と、ゼンゼン違う!!
（トーゼンだが、ハフマン変換表が異なれば、ハフマン符号で書かれた画像データ領域も見た目には全く別モノになる。
モチロン、ハフマンコードを逆変換して元に戻せば同じデータになることはBMPデータ比較から明らか!）
実は”最適化”とはハフマン符号変換に際し、実際の画像データ（YCｂCr変換・DCT変換・量子化を経たもの）に対して
Byteデータとしての出現頻度の多寡を調査して、頻度の多いものから順次bit長の短いハフマン符号を振るコトを言う。
BMPやTiffでは各RGB画素値がいくつであれ常に8bit（あるいは16bit）の固定データ長を使うが、Jpegでは可変長のデータを使うので、出現頻度の多い値にデータ長の短いコードを与えることでファイルサイズを小さくしている。
これがJpeg圧縮の正体であり、出現頻度に大きな偏りを持たせるために離散コサイン変換だのの前処理を行うのである。
最適化を行わない”標準”とは、あらかじめアプリが想定した”標準”変換表をそのまま適用することを言う。
フォトショ（あるいは他のアプリやデジカメでも）の使用する標準変換表がJFIFの推奨変換表と一致している保証はない。
通常ならハフマン符号変換の前までの処理で、データは絶対値の小さいデータに集中するので（それが前処理の目的である）、
ざっくり標準変換表を想定するなら、絶対値の小さい値に短いハフマン符号を与えるように作っておけば、最良ではなくとも、良好な圧縮効果が期待できるものになる。
ハフマン変換表の最適化を行うと全データをサーチする分だけ処理時間がかかるが、最大の圧縮効果が得られる。
・・・では、最適化を実施したJPEGファイルを開けないアプリはあるのか？
そんなアプリはあり得ない!!
もしも、最適化したJPEGが読めないのならば、そのアプリはファイルに記述されたハフマン変換表を使用していないことになる。
（最適化しても変換表自体はJPEGのルールに従った記述になっており、ルール通りの手順であれば必ず読んで使える）
ところが、現実のJPEGでは最適化されてなくとも、数多くのハフマン変換表が存在しうるのであって標準変換表が唯一に定まっているのではない。
（だから、最適化処理の有無に関係なく、必ずDHTセグメントにハフマン変換表が書き込まれているのだ）
仮にDHT記載の変換表を常に無視して、アプリ内部に搭載した変換表だけを使ってコード変換するアプリであったら、
そのアプリには正しく読めないJPEGファイルが世間にはごっそり存在することになるハズで、そんなアプリは成立し得ないのである。
巷のウワサって、どうしてこうもしょーもないモノなんだろう・・・・!?
流すヤツも、真に受けるヤツも・・・・
