![画像比較は人間の眼で行うべし？
(4/4)
? compose difference と idenfity mean でピクセ
ル差分の度合いを算出
? 特定バージョンとの差を数値でリスト
569.07 : 6.6.9-6-logo.gif
569.07 : 6.6.9-7-logo.gif
9533.31 : 6.6.9-8-logo.gif
569.07 : 6.6.9-9-logo.gif
569.07 : 6.7.0-0-logo.gif
$ for i in *-logo.gif ; do
composite -compose difference 6.9.3-0-logo.gif $i t.png ;
identify -format "%[mean]" t.png ; echo " : $i" ; done
差分の大きい
バージョン発見！](https://image.slidesharecdn.com/imagemagickknowhow-160125051015/85/Imagemagickknowhow-9-320.jpg)
![グレースケールを考慮しよう？(2/2)
? ツッコミ詳細 グレー形式JPEGをPNGに変換すると暗くな
る件 http://blog.awm.jp/2016/01/06/gray/
? 6.8.0-0?6.8.0-7 の色空間処理の不具合
? 修正イメージ (ありがちな条件式のミス)
$ diff -rwb ImageMagick-6.8.0-[78]/coders/png.c
8305,8306c8305,8306
< if ((IssRGBCompatibleColorspace(image->colorspace) == MagickFalse) &&
< (IssRGBColorspace(image->colorspace) == MagickFalse))
---
> if ((IssRGBCompatibleColorspace(image->colorspace) == MagickFalse) ||
> (IssRGBColorspace(image->colorspace) != MagickFalse))](https://image.slidesharecdn.com/imagemagickknowhow-160125051015/85/Imagemagickknowhow-17-320.jpg)
Imagemagickknowhow
- 2. 自己紹介 @yoya ? ImageMagick のストーカーです – http://d.hatena.ne.jp/yoya/searchdiary?word=Image Magick ? ImageMagick の減色処理が重たいのでチートっ ぽい改造で高速化したら本家に採用されました – ImageMagick proposal QBRA ? http://d.hatena.ne.jp/yoya/20131025/im – ImageMagick-6.8.7-4 差分 ? http://d.hatena.ne.jp/yoya/20131101/im
- 3. 一部界隈で話題 ? もうサムネイルで泣かないための ImageMagick ノウハウ集 – http://blog.cybozu.io/entry/2016/01/06/080000 ? 色んなバッドノウハウが詰まっていて素晴らし い記事です。便乗して幾つか勝手に補足して みます。
- 4. 良いと思ったノウハウ ? リリース大量消費に注意 – limit 大事 (特にユーザ投稿画像を扱う場合) ? ImageMagick のオプションの順序に注意 – 引数を先頭から順に命令実行する $ convert -limit memory 256MB -limit disk 0 src.jpg dst.png $ convert in.png -resize 200x200 -background red –flatten out.jpg $ convert in.png -resize 200x200 –flatten -background red out.jpg
- 5. ツッコミ目次 ? 画像比較は人間の眼で行うべし？ ? Orientation を考慮しよう？ ? 透過画像を考慮しよう？ ? グレースケール画像を考慮しよう？ ? -define jpeg:size に注意？
- 6. 画像比較は人間の眼で行うべし？ (1/4) ? 最終的な判断は人間の眼だけど、それだけ では画像の差を結構見逃します – 間違い探しの得手不得手があるように画像認 識は個人差が大きいので、なるべく計算で炙り 出す ? 2枚の画像のdiff(差分)を超簡単に調べる方 法 – http://blog.mirakui.com/entry/20110326/130111 1196
- 7. 画像比較は人間の眼で行うべし？ (2/4) http://www.pixiv.net/member_illust.php?mode=medium&illust_id=13086025? Dinyc JPEG ?GIF 変換 (減色) JPEG GIF $ convert image.jpg image.gif $ composite -compose difference image.jpg image.gif diff.png $ mogrify -auto-level diff.png #差分画像を明るくする
- 9. 画像比較は人間の眼で行うべし？ (4/4) ? compose difference と idenfity mean でピクセ ル差分の度合いを算出 ? 特定バージョンとの差を数値でリスト 569.07 : 6.6.9-6-logo.gif 569.07 : 6.6.9-7-logo.gif 9533.31 : 6.6.9-8-logo.gif 569.07 : 6.6.9-9-logo.gif 569.07 : 6.7.0-0-logo.gif $ for i in *-logo.gif ; do composite -compose difference 6.9.3-0-logo.gif $i t.png ; identify -format "%[mean]" t.png ; echo " : $i" ; done 差分の大きい バージョン発見！
- 10. Orientation を考慮しよう？(1/4) ? オフセットが壊れる？ ? JPEG を経由する方法を提案してる ? ツッコミ詳細 -auto-orient でオフセットがズレる件 http://blog.awm.jp/2016/01/06/orient/ このケースは -auto-orient をつけて一度 JPEG に変換し 、改めて PNG に変換すると正しい情報の画像が得られます。 $ convert right-mirrored.jpg -auto-orient out.png $ identify out.png out.png PNG 480x640 640x480+160+4294967136 8-bit PseudoClass 256c 13.8KB 0.000u 0
- 11. Orientation を考慮しよう？(2/4) ? オフセットが壊れる件は恐らく、signed long (32bit符号付き整数)を unsigned long で表示 ? 正しくはこう。(2の補数表現で計算) $ convert right-mirrored.jpg -auto-orient out.png $ identify out.png out.png PNG 480x640 640x480+160+4294967136 8-bit PseudoClass 256c 13.8KB 0.000u $ convert right-mirrored.jpg -auto-orient out.png $ identify out.png out.png PNG 480x640 640x480+160-160 8-bit PseudoClass 256c 13.8KB 0.000u 0:00.000
- 12. Orientation を考慮しよう？(3/4) ? RotateImage 関数に 90 といった角度の値を 渡して回転させてる – 回転軸を間違えて左上隅の座標が移動
- 13. Orientation を考慮しよう？(4/4) ? Webブラウザがレイアウトする時に以下のよ うにズレる可能性がある ? +repage (描画領域の座標をリセットする)で 対処可能
- 14. 透過画像を考慮しよう？(1/2) ? -extent で背景を白にできる？ ? -extent はキャンバスの拡大命令 $ convert in.png -resize 200x200 out.jpg $ convert in.png -resize 200x200 -extent 200x200 out.jpg $ convert in.png -resize 200x200 –extent 400x400 out.jpg
- 15. 透過画像を考慮しよう？（2/2) ? -flatten (レイヤーを重ねる命令)が正しい – 例えば赤い背景を用意して重ねる ? (-extentでも結果的に同じ事をやってる) – オプションの順番に注意 $ convert in.png -resize 200x200 -background red –flatten out.jpg $ convert in.png -resize 200x200 –flatten -background red out.jpg
- 16. グレースケールを考慮しよう？(1/2) ? ブログの記述 ? 減色処理で暗くなるのは不自然 – 参考) http://labs.gree.jp/blog/2012/09/4824 ? そもそも8bitカラーのグレー画像なら256色で 全色を表現できるはず 白黒画像を PNG に変換すると、元画像より暗くなる場合があります。 これは減色アルゴリズムによる挙動と思われます。 JPEG はフルカラー画像を扱えますが、通常の PNG だと 256 色しか扱えないのです。
- 17. グレースケールを考慮しよう？(2/2) ? ツッコミ詳細 グレー形式JPEGをPNGに変換すると暗くな る件 http://blog.awm.jp/2016/01/06/gray/ ? 6.8.0-0?6.8.0-7 の色空間処理の不具合 ? 修正イメージ (ありがちな条件式のミス) $ diff -rwb ImageMagick-6.8.0-[78]/coders/png.c 8305,8306c8305,8306 < if ((IssRGBCompatibleColorspace(image->colorspace) == MagickFalse) && < (IssRGBColorspace(image->colorspace) == MagickFalse)) --- > if ((IssRGBCompatibleColorspace(image->colorspace) == MagickFalse) || > (IssRGBColorspace(image->colorspace) != MagickFalse))
- 18. -define jpeg:size に注意？ (1/4) ? 注意は必要なのですが ? これは勿体無い ? ツッコミ詳細 JPEG の size hinting について – http://blog.awm.jp/2016/01/08/jpeghint/ 弊社では、このオプションはサービスの安定運用のためには無用と判断し、 現在このオプションは利用していません。 変換後のサイズが大きい場合、大抵は元画像サイズ 1/3 以上程度ですが、 これを超えると -define jpeg:size オプションを指定していない時以上に メモリを消費します。
- 19. -define jpeg:size に注意？ (2/4) ? 普通に小さくリサイズ ? jpeg:size つきで小さくリサイズ (メモリ節約)
- 20. -define jpeg:size に注意？ (3/4) ? 普通に大きくリサイズ ? jpeg:size つきで大きくリサイズ (余計にメモリ を使う)
- 21. -define jpeg:size に注意？ (4/4) ? 1/2?1/3以下にリサイズされる時のみ – define jpeg:size をつければ良い ? 本当は速いImageMagick: サムネイル画像生 成を10倍速くする方法 ? http://blog.mirakui.com/entry/20110123/1295795409 ? 効果が大きいので使わないのは勿体無い
- 22. ツッコミまとめ ? 画像比較は人間の眼で行うべし？ – > なるべく計算で炙り出そう ? Orientation を考慮しよう？ – > バグなんだけど +repage で補正できる ? 透過画像を考慮しよう？ – > -extent でも治るけど -flatten が正道 ? グレースケール画像を考慮しよう？ – > 減色処理でなく一時期あった色空間の不具合 ? -define jpeg:size に注意？ – > メモリとCPUの節約効果大きいので ??1/3 以下に縮小 する時は積極的に使っていきたい