KerasのVGG16でファインチューニングする場合は、画像データを255で割っちゃダメ！？

ちょっとマニアックな記事です。分かる人には分かる。

以前、VGG16のファインチューニングコード: EeePCの軌跡という記事を書きました。

その中で、画像データを読み込んだ後に、numpy形式に変換し、

X = X / 255

のように、255で割っているところがあります。

これは、画像データの三原色(R、G、B)ごとのデータ値が0～255となっているため、数値計算上、正規化するためにやってる操作なのですが。

最近、この「255で割る」をやらない方が精度が上がるという妙な現象に出くわしまして。

実際、自宅にある適当な画像セットで、30サイクルほどを回した結果が、以下のようになります。

点線が、255で割ってる時のLoss値(train、val)の減少、実線の方が255で割らなかった時のLoss値のグラフ。

明らかに、255で割らない方が収束が速く、Loss値も小さくなる、という結果でした。

これは、会社でやっても同じだったんです。

で、ある人から、以下のサイトを教えていただきました。

 TensorFlow, KerasでVGG16などの学習済みモデルを利用 | note.nkmk.me

この記事の中ほどに「画像の前処理: preprocess_input()」という項目があるんですが、その中で、この入力する画像データの前提として

• 画素値の範囲: 0 - 255
• 色の並び: RGB
• channel last(サンプル数, 縦, 横, チャンネル数)

って、書いてあるんです(VGG16だけではなく)。

で、ここにもある通り、画素値の範囲の前提が0～255となってるんです。

えっ！？やっぱり255で割っちゃいけないってこと！？

もちろんこれは、推論コードでも同じです。

まだそれほど試してませんけど、会社では推論後にGrad-CAMでヒートマップ出力させてますけど、明らかに255で割らない方がしっくりする結果が出てきたりしてます。

どうやら、keras等の事前学習データを用いるときって、注意が必要みたいです。

あまり考えてませんでしたが、これからはちゃんとリファレンスを読んだ方がよさそうですね。

ちなみに、Qiitaなどに上がっている記事では、このVGG16のファインチューニングコードでけっこう255で割ってたりします。というか、割ってるものしか見当たらない。

ということで、本当にこの解釈が正しいのかどうか自信が持てないんですが……まあ、そういう話もあるということで。

高校数学からはじめるディープラーニング　初歩からわかる人工知能が働くしくみ (ブルーバックス)