imagemagick_knowhow

もうサムネイルで泣かないための ImageMagick ノウハウ集に一言ツッコミ

1. もうサムネイルで泣かないための ImageMagick  ノウハウ集に一言 2015/01/22(金)   “よや”  yoya@awm.jp
2. 自己紹介 @yoya •  ImageMagick  のストーカーです   –  h<p://d.hatena.ne.jp/yoya/searchdiary? word=ImageMagick   •  ImageMagick の減色処理が重たいのでチートっ ぽい改造で高速化したら本家に採用されました   –  ImageMagick  proposal  QBRA   •  h<p://d.hatena.ne.jp/yoya/20131025/im   –  ImageMagick-­‐6.8.7-­‐4  差分   •  h<p://d.hatena.ne.jp/yoya/20131101/im  
3. 一部界隈で話題 •  もうサムネイルで泣かないための ImageMagick  ノウハウ集   – h<p://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  –fla<en  out.jpg     $  convert  in.png  -­‐resize  200x200  –fla<en  -­‐background  red  out.jpg
5. ツッコミ目次 •  画像比較は人間の眼で行うべし？   •  OrientaYon  を考慮しよう？   •  透過画像を考慮しよう？   •  グレースケール画像を考慮しよう？   •  -­‐define  jpeg:size  に注意？  
6. 画像比較は人間の眼で行うべし？ (1/4) •  最終的な判断は人間の眼だけど、それだけ では画像の差を結構見逃します   – 間違い探しの得手不得手があるように画像認識 は個人差が大きいので、なるべく計算で炙り出す   •  2枚の画像のdiff(差分)を超簡単に調べる方 法   – h<p://blog.mirakui.com/entry/ 20110326/1301111196  
7. 画像比較は人間の眼で行うべし？ (2/4) h<p://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    #差分画像を明るくする  
8. 画像比較は人間の眼で行うべし？ (3/4) •  差分が大きい場所に注目すれば見逃しにくい
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  ;   idenYfy  -­‐format  "%[mean]"  t.png    ;  echo  "  :  $i"  ;  done   差分の大きい   バージョン発見！
10. OrientaYon  を考慮しよう？(1/4) •  オフセットが壊れる？   •  JPEG  を経由する方法を提案してる   •  ツッコミ詳細 -­‐auto-­‐orient  でオフセットがズレる件   h<p://blog.awm.jp/2016/01/06/orient/   このケースは -­‐auto-­‐orient  をつけて一度 JPEG  に変換し   、改めて PNG  に変換すると正しい情報の画像が得られます。 $  convert  right-­‐mirrored.jpg  -­‐auto-­‐orient  out.png   $  idenYfy  out.png     out.png  PNG  480x640  640x480+160+4294967136  8-­‐bit  PseudoClass  256c  13.8KB  0.000u  0
11. OrientaYon  を考慮しよう？(2/4) •  オフセットが壊れる件は恐らく、signed  long   (32bit符号付き整数)を  unsigned  long  で表示   •  正しくはこう。(2の補数表現で計算)   $  convert  right-­‐mirrored.jpg  -­‐auto-­‐orient  out.png   $  idenYfy  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   $  idenYfy  out.png     out.png  PNG  480x640  640x480+160-­‐160  8-­‐bit  PseudoClass  256c  13.8KB  0.000u  0:00.000
12. OrientaYon  を考慮しよう？(3/4) •  RotateImage 関数に 90  といった角度の値を 渡して回転させてる   – 回転軸を間違えて左上隅の座標が移動  
13. OrientaYon  を考慮しよう？(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) •  -fla<en  (レイヤーを重ねる命令)が正しい   – 例えば赤い背景を用意して重ねる   •   (-extentでも結果的に同じ事をやってる)   – オプションの順番に注意       $  convert  in.png  -­‐resize  200x200  -­‐background  red  –fla<en  out.jpg     $  convert  in.png  -­‐resize  200x200  –fla<en  -­‐background  red  out.jpg
16. グレースケールを考慮しよう？(1/2) •  ブログの記述     •  減色処理で暗くなるのは不自然   – 参考) h<p://labs.gree.jp/blog/2012/09/4824   •  そもそも8bitカラーのグレー画像なら256色で 全色を表現できるはず     白黒画像を PNG  に変換すると、元画像より暗くなる場合があります。 これは減色アルゴリズムによる挙動と思われます。 JPEG  はフルカラー画像を扱えますが、通常の PNG  だと 256  色しか扱えないのです。
17. グレースケールを考慮しよう？(2/2) •  ツッコミ詳細 グレー形式JPEGをPNGに変換すると暗くな る件 h<p://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  ((IssRGBCompaYbleColorspace(image-­‐>colorspace)  ==  MagickFalse)  &&   <                            (IssRGBColorspace(image-­‐>colorspace)  ==  MagickFalse))   -­‐-­‐-­‐   >                    if  ((IssRGBCompaYbleColorspace(image-­‐>colorspace)  ==  MagickFalse)  ||   >                            (IssRGBColorspace(image-­‐>colorspace)  !=  MagickFalse))  
18. -­‐define  jpeg:size に注意？ (1/4) •  注意は必要なのですが     •  これは勿体無い   •  ツッコミ詳細 JPEG  の size  hinYng  について   – h<p://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倍速くする方法   •  h<p://blog.mirakui.com/entry/20110123/1295795409   •  効果が大きいので使わないのは勿体無い  
22. ツッコミまとめ •  画像比較は人間の眼で行うべし？   –  > なるべく計算で炙り出そう   •  OrientaYon  を考慮しよう？   –  > バグなんだけど +repage で補正できる   •  透過画像を考慮しよう？   –  >  -­‐extent でも治るけど -­‐fla<en  が正道   •  グレースケール画像を考慮しよう？   –  > 減色処理でなく一時期あった色空間の不具合   •  -­‐define  jpeg:size  に注意？   –  > メモリとCPUの節約効果大きいので  ½〜1/3  以下に縮小 する時は積極的に使っていきたい  
23. 質問タイム •  （袋叩きにされるイメージ画像)