HEIF(HEVC image)検証#1

 iPhone 8及びXと共にリリースされたiOS11及びmacOS High Sierraでサポートされた画像フォーマットHEIF(High Efficiency Image File Format)について検証を行います。
 

はじめに

 広義にはHEIFは画像フォーマットですが、正確にはコンテナ形式でしかありません。
 例えるなら映像フォーマットとしてMP4がありますが、あれも正確にはコンテナ形式です。その内部はH.264などでエンコードされた映像データと、AACなどでエンコードされた音声データから構成されますが、それを格納する容器(コンテナ)の一つとしてMP4があるという位置付けです。
 HEIFも同様に容器でしかないわけですが、HEVCでエンコードされた画像を格納することができます(JPEG画像を格納することもできるようですが、本投稿で扱うのはHEVC画像についてのみ)。
 なおHEVCはH.265とも呼ばれますが、H.264がAVCと呼ばれるのと同じ関係です。
 
 ご存知の方も多いと思いますがH.264は映像で使われるコーデックで、H.265も本来は映像をターゲットに開発されたコーデックです。が、映像とはパラパラ漫画と同じで静止画の塊です。パラパラ漫画の1枚(1フレーム)だけ圧縮すると考えれば、それは単に静止画を圧縮するのと同義ですから、静止画圧縮にも転用可能な訳です。
 

HEIFの訴求ポイント

 Appleによれば以下のようにHEIFはJPEGより小さいことがメリットとして主に訴求されているようです(なお、HEICはHEIFにHEVC画像が格納された場合の拡張子)。

HEIC files are twice as small as JPEGs

https://devstreaming-cdn.apple.com/videos/wwdc/2017/511tj33587vdhds/511/511_working_with_heif_and_hevc.pdf

 他にも、上記PDF中では単一のHEIFファイル内に複数の画像を格納できることもメリットとして触れられてはいます。例えば、連写画像を個別のファイルにバラバラに格納するのではなく単一のHEIFに格納出来たり、最近のスマートフォンでは珍しくなくなってきた被写界深度の浅い写真に加工するための深度情報を記録するための深度画像を単一のHEIFに格納したりといった用途での利便性が語られています。
 が、複数画像を格納するのは既存のTIFFでも可能ですし、あまり普及しませんでしたが*1CIPAで標準化されたMPファイル(拡張子MPO)でも実現されています。
http://www.cipa.jp/std/documents/j/DC-007_J.pdf
 故に複数画像を単一ファイルに格納できることの自体に目新しさは無く、ファイルサイズの軽量化こそが最大のメリットと言えるのでしょう(特にSDカードでストレージを増やせる多くのAndroid端末とは異なり、内蔵フラッシュメモリのみのiPhoneに於いてはその恩恵は大きい)。
 

検証項目

 ファイルがコンパクトであるというメリットについて、そのサイズを実際に確認してみます。
 一方で、HEVC(H.265)はJPEG同様に非可逆圧縮ですから、画質を損なうことを許容できれば小さくなるのは当然でもあります。
 故に、画質とファイルサイズという2つの軸で評価するのが妥当だと考えられます*2
 なお、ファイルサイズについては明確に測定可能ですが、画質については定性的な評価となってしまいまがちで、評価者の主観も含まれてしまう恐れもあります。そこで、定量的な評価項目として本投稿では元画像とエンコード後の画像の差分を用いることにします。
 画像はピクセルの2次元的な集合ですが、各ピクセルはRGBの各値を持つ数値データでしかありません。仮にエンコード後の画像が元画像と全く同一であれば、差分画像は真っ黒(差が無い=0=黒)となります。
 故に、差分が小さい方が高画質と定量的に判断できます。本投稿では差分の絶対値の平均(画像を構成する各ピクセルごとの差分の絶対値の平均値)と、差分の絶対値の最大値(画像を構成する各ピクセルごとの差分の絶対値の最大値)を測定します。
※H.265は人間の視覚や心理的にどうでも良さそうな情報を捨てて圧縮率を高めることもできるため、目視では特に気にならない画質劣化でも、このように単純に差分で比較されると芳しくない結果となるかもしれません。
 ファイルサイズおよび差分値はJPEG画像をベンチマーク対象として比較します。
 

検証パターン

 複数の入力画像(スクリーンショットのようなPNGや、RAWから現像したTIFFなどいずれも可逆圧縮の無劣化画像)パターンを用意し、H.265のCRF(Constant Rate Factor)及びJPEGのQ(Quality)を変更しながらファイルサイズおよび差分を測定します。
 なお、HEVCのCRFは0~51の範囲内で指定しますが、0に近いほど高画質でデータ量が大きい、51に近いほど低画質でデータ量が小さくなります。一方、JPEGのQualityは1~100の範囲で指定しますが、1に近いほど低画質でデータ量が小さい、100に近いほど高画質でデータ量が大きくなります。HEVCのCRFとJPEGのQualityでは値の大小と画質とデータ量の関係が逆になりますので、混乱しないようご注意ください。
 

検証方法

  • HEVC(H.265)エンコーダとして、libx265*3を利用可能なffmpegを使用
  • JPEGエンコーダとして、libjpegを使ったImageMagickを使用
  • ImageMagickで差分を取得・評価

※HEIFをネイティブで扱えるWindows用ソフトウェアは現時点では事実上ほぼありません。今回利用するImageMagickでも扱えませんし、Adobe Photoshopでも扱えません。そのため、ffmpegでHEVCでエンコードした画像を、ffmpegPNGに変換した画像を差分比較用画像として扱います(ファイルサイズ測定は当然HEVCでエンコードしただけのファイルを測定します)。
 



続きます…。
HEIF(HEVC image)検証#2 - 記憶は人なり

*1:RICOH CXシリーズの連写画像や、SONYPanasonic機等の3D画像記録形式として実際に採用されていた。

*2:本当はエンコード・デコードのパフォーマンス(所要時間・消費メモリ等システムリソースへのインパクト)も測定するべきですが、環境依存が激しいので今回は測定対象から割愛します。

*3:libavcodec 57.3.100