Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
imagemagick_knowhow
Search
yoya
January 22, 2016
Technology
6
4.6k
imagemagick_knowhow
もうサムネイルで泣かないための ImageMagick ノウハウ集に一言ツッコミ
yoya
January 22, 2016
Tweet
Share
More Decks by yoya
See All by yoya
resize_nitpick
yoya
1
140
ImageFluxBinary
yoya
2
2.6k
HEIF-kaisetsu
yoya
4
3.2k
go-thumber-imagick
yoya
1
160
chokaizomae
yoya
2
520
wildimagebinary
yoya
1
200
goimagicksyokai
yoya
2
1.1k
GoImagickThumbnail
yoya
0
1.5k
sushigazou
yoya
0
12k
Other Decks in Technology
See All in Technology
Data-centric AI入門第6章:Data-centric AIの実践例
x_ttyszk
1
370
PL900試験から学ぶ Power Platform 基礎知識講座
kumikeyy
0
110
組織貢献をするフリーランスエンジニアという生き方
n_takehata
1
1k
スタートアップ1人目QAエンジニアが QAチームを立ち上げ、“個”からチーム、 そして“組織”に成長するまで / How to set up QA team at reiwatravel
mii3king
1
1.1k
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
3
710
Classmethod AI Talks(CATs) #15 司会進行スライド(2025.02.06) / classmethod-ai-talks-aka-cats_moderator-slides_vol15_2025-02-06
shinyaa31
0
170
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue
shift_evolve
2
880
データ基盤の成長を加速させる:アイスタイルにおける挑戦と教訓
tsuda7
3
650
Platform Engineeringは自由のめまい
nwiizo
4
1.9k
家電アプリ共通PF "Linova" のAPI利用とPostman活用事例ご紹介
yukiogawa
0
130
『AWS Distinguished Engineerに学ぶ リトライの技術』 #ARC403/Marc Brooker on Try again: The tools and techniques behind resilient systems
quiver
0
130
現場の種を事業の芽にする - エンジニア主導のイノベーションを事業戦略に装着する方法 -
kzkmaeda
2
1.5k
Featured
See All Featured
The Invisible Side of Design
smashingmag
299
50k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.5k
For a Future-Friendly Web
brad_frost
176
9.5k
How to Think Like a Performance Engineer
csswizardry
22
1.3k
Building Your Own Lightsaber
phodgson
104
6.2k
Site-Speed That Sticks
csswizardry
3
370
Unsuck your backbone
ammeep
669
57k
Music & Morning Musume
bryan
46
6.3k
Practical Orchestrator
shlominoach
186
10k
Typedesign – Prime Four
hannesfritz
40
2.5k
Transcript
もうサムネイルで泣かないための ImageMagick ノウハウ集に一言 2015/01/22(金) “よや”
[email protected]
自己紹介 @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
一部界隈で話題 • もうサムネイルで泣かないための ImageMagick ノウハウ集 – h<p://blog.cybozu.io/entry/2016/01/06/080000 • 色んなバッドノウハウが詰まっていて素晴らし
い記事です。便乗して幾つか勝手に補足して みます。
良いと思ったノウハウ • リリース大量消費に注意 – 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
ツッコミ目次 • 画像比較は人間の眼で行うべし? • OrientaYon を考慮しよう? • 透過画像を考慮しよう?
• グレースケール画像を考慮しよう? • -‐define jpeg:size に注意?
画像比較は人間の眼で行うべし? (1/4) • 最終的な判断は人間の眼だけど、それだけ では画像の差を結構見逃します – 間違い探しの得手不得手があるように画像認識 は個人差が大きいので、なるべく計算で炙り出す •
2枚の画像のdiff(差分)を超簡単に調べる方 法 – h<p://blog.mirakui.com/entry/ 20110326/1301111196
画像比較は人間の眼で行うべし? (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 #差分画像を明るくする
画像比較は人間の眼で行うべし? (3/4) • 差分が大きい場所に注目すれば見逃しにくい
画像比較は人間の眼で行うべし? (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 差分の大きい バージョン発見!
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
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
OrientaYon を考慮しよう?(3/4) • RotateImage 関数に 90 といった角度の値を 渡して回転させてる – 回転軸を間違えて左上隅の座標が移動
OrientaYon を考慮しよう?(4/4) • Webブラウザがレイアウトする時に以下のよ うにズレる可能性がある • +repage (描画領域の座標をリセットする)で 対処可能
透過画像を考慮しよう?(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
透過画像を考慮しよう?(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
グレースケールを考慮しよう?(1/2) • ブログの記述 • 減色処理で暗くなるのは不自然 – 参考) h<p://labs.gree.jp/blog/2012/09/4824
• そもそも8bitカラーのグレー画像なら256色で 全色を表現できるはず 白黒画像を PNG に変換すると、元画像より暗くなる場合があります。 これは減色アルゴリズムによる挙動と思われます。 JPEG はフルカラー画像を扱えますが、通常の PNG だと 256 色しか扱えないのです。
グレースケールを考慮しよう?(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))
-‐define jpeg:size に注意? (1/4) • 注意は必要なのですが • これは勿体無い
• ツッコミ詳細 JPEG の size hinYng について – h<p://blog.awm.jp/2016/01/08/jpeghint/ 弊社では、このオプションはサービスの安定運用のためには無用と判断し、 現在このオプションは利用していません。 変換後のサイズが大きい場合、大抵は元画像サイズ 1/3 以上程度ですが、 これを超えると -‐define jpeg:size オプションを指定していない時以上に メモリを消費します。
-‐define jpeg:size に注意? (2/4) • 普通に小さくリサイズ •
jpeg:size つきで小さくリサイズ (メモリ節約)
-‐define jpeg:size に注意? (3/4) • 普通に大きくリサイズ •
jpeg:size つきで大きくリサイズ (余計にメモリ を使う)
-‐define jpeg:size に注意? (4/4) • 1/2〜1/3以下にリサイズされる時のみ – define jpeg:size をつければ良い
• 本当は速いImageMagick: サムネイル画像生 成を10倍速くする方法 • h<p://blog.mirakui.com/entry/20110123/1295795409 • 効果が大きいので使わないのは勿体無い
ツッコミまとめ • 画像比較は人間の眼で行うべし? – > なるべく計算で炙り出そう • OrientaYon
を考慮しよう? – > バグなんだけど +repage で補正できる • 透過画像を考慮しよう? – > -‐extent でも治るけど -‐fla<en が正道 • グレースケール画像を考慮しよう? – > 減色処理でなく一時期あった色空間の不具合 • -‐define jpeg:size に注意? – > メモリとCPUの節約効果大きいので ½〜1/3 以下に縮小 する時は積極的に使っていきたい
質問タイム • (袋叩きにされるイメージ画像)