Upgrade to Pro — share decks privately, control downloads, hide ads and more …

imagemagick_knowhow

yoya
January 22, 2016

 imagemagick_knowhow

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

yoya

January 22, 2016
Tweet

More Decks by yoya

Other Decks in Technology

Transcript

  1. 自己紹介 @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  
  2. 良いと思ったノウハウ •  リリース大量消費に注意   – 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
  3. ツッコミ目次 •  画像比較は人間の眼で行うべし?   •  OrientaYon  を考慮しよう?   •  透過画像を考慮しよう?

      •  グレースケール画像を考慮しよう?   •  -­‐define  jpeg:size  に注意?  
  4. 画像比較は人間の眼で行うべし? (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    #差分画像を明るくする  
  5. 画像比較は人間の眼で行うべし? (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   差分の大きい   バージョン発見!
  6. 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
  7. 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
  8. 透過画像を考慮しよう?(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    
  9. 透過画像を考慮しよう?(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
  10. グレースケールを考慮しよう?(1/2) •  ブログの記述     •  減色処理で暗くなるのは不自然   – 参考) h<p://labs.gree.jp/blog/2012/09/4824

      •  そもそも8bitカラーのグレー画像なら256色で 全色を表現できるはず     白黒画像を PNG  に変換すると、元画像より暗くなる場合があります。 これは減色アルゴリズムによる挙動と思われます。 JPEG  はフルカラー画像を扱えますが、通常の PNG  だと 256  色しか扱えないのです。
  11. グレースケールを考慮しよう?(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))  
  12. -­‐define  jpeg:size に注意? (1/4) •  注意は必要なのですが     •  これは勿体無い

      •  ツッコミ詳細 JPEG  の size  hinYng  について   – h<p://blog.awm.jp/2016/01/08/jpeghint/     弊社では、このオプションはサービスの安定運用のためには無用と判断し、   現在このオプションは利用していません。 変換後のサイズが大きい場合、大抵は元画像サイズ 1/3  以上程度ですが、   これを超えると -­‐define  jpeg:size  オプションを指定していない時以上に   メモリを消費します。
  13. -­‐define  jpeg:size に注意? (2/4) •  普通に小さくリサイズ       • 

    jpeg:size  つきで小さくリサイズ  (メモリ節約)  
  14. -­‐define  jpeg:size に注意? (3/4) •  普通に大きくリサイズ       • 

    jpeg:size  つきで大きくリサイズ (余計にメモリ を使う)  
  15. -­‐define  jpeg:size に注意? (4/4) •  1/2〜1/3以下にリサイズされる時のみ – define  jpeg:size  をつければ良い

      •  本当は速いImageMagick:  サムネイル画像生 成を10倍速くする方法   •  h<p://blog.mirakui.com/entry/20110123/1295795409   •  効果が大きいので使わないのは勿体無い  
  16. ツッコミまとめ •  画像比較は人間の眼で行うべし?   –  > なるべく計算で炙り出そう   •  OrientaYon

     を考慮しよう?   –  > バグなんだけど +repage で補正できる   •  透過画像を考慮しよう?   –  >  -­‐extent でも治るけど -­‐fla<en  が正道   •  グレースケール画像を考慮しよう?   –  > 減色処理でなく一時期あった色空間の不具合   •  -­‐define  jpeg:size  に注意?   –  > メモリとCPUの節約効果大きいので  ½〜1/3  以下に縮小 する時は積極的に使っていきたい