画像変換Nightに行ってきた
- http://connpass.com/event/11516/
- とりあえず、見つかった限りのスライドは載せました。
- 発表者のみなさま、会場のGREEさん、ありがとうございましたm( )m
感想・まとめ
- 全体的に濃い話だった
- go-thumber使ってみたい
- 基本的にみんなImageMagick大好き
- というか、あまり他に優秀なインターフェースがないんだな、の印象
- yoyaさんは神
- 自力でやりました、という話が中心で、こうやって楽にやってますという話はなかった
- 切り出しとか考えると、ASPつらいのかもね
- でもCloudinaryすごいよ？
- ImageHayabusaへの期待感すごい
サムネイルマスタとgo-thumber
- はるかさんさん
pixivのひと
オリジナル画像をそのまま配信
- 転送量がめちゃ多い
- デザイン大変
- 後からサムネイル作るの大変
- サービスが大きくなるにつれ、つらくなる
アップロード時にサムネイル生成
- アップロード処理が大変
- 非同期処理必要になる
- そうしないと待たせちゃう
- サイズ変更が大変
- アップロード処理が大変
リクエスト時にサムネイル生成
- 動的変換
- デザイン変更が簡単
- キャッシュしてくれればリクエストも少ない
動的生成で困ること
- 生成元画像に依存
- サイズもバラバラでメモリ量もバラバラ
- 処理が面倒
- フォーマットの問題
- 加工とかとか。。。
- 生成元画像に依存
サムネイルマスタ
- サムネイル生成元となる画像マスタ
- リクエスト時の生成の負荷を軽減
- 他のサムネイルよりでかい
- 長年培われたcrop技術により。。。縦長は下が切られる
画像はJPEG保存
-
- ブラウザによってICCプロファイルを解釈したりしなかったり
どうすればよいのか
- カラーマネジメントできるエンジニアが不在
- ユーザー環境がただしいプロファイルを扱っているかわからない
これらの問題をサムネイルマスタで解決
go-thumber
- サムネイルマスタをいい感じに作ってくれるプロキシ
- はやい
- LibJPEGv6 APIを生で叩いて書き込み
- LibswscaleでImageMagickと同等の精度
-
mod_smalllight(imlib2 / imagick)と比較- Apacheはあんまり頑張ってない
- だいたいimlib2と同じくらいの速度になった
ブラインドテストをやった
- 50%ぐらいの人が、go-thumberのサムネイルを一番きれいだと選択した
何故綺麗に出たか？
スケーリングデコードのサイズ最適化
- libJPEGは1/1 - 1/8の好きなスケールでデコードできる
- go-thmberでは必ずサイズの2倍に設定してる
次はwebp-thumbersを目指してる
Q: URLにパラメータが直接見えると、だれでも変換できるが？
- A: nginxのrewriteで特定のものだけ通してる
- 開発環境ではフリーに通してる
- A: nginxのrewriteで特定のものだけ通してる
実践ngx_small_light入門
- bokkoさん
Mercari, Inc.
ngx_small_light- Imagemagick / imlib2 / GD
- PNG / JPEG / GIF / WebP
setup / install / 設定
small_light on;small_light_pattern_defineで名前を付けられる基本的なパラメータ
- dw,dh
- of
- q
- p
- e (defaultはImageMagick)
small_light_getparam_mode on;- query stringから指定できる
- デフォルト off
- 設定すると
small_light関数は使えなくなる
S3にある画像を
ngx_small_lightでリサイズ- リゾルバの設定が抜けてた
画像ライブラリの比較
- それぞれ特色ある
その他のモジュールについて
mod_small_lightngx_small_lightのポーティング元
ngx_image_filter- 標準で付いているimage filter
go-tumber- pixiv制
Image最適化について
worker_(processes|connections)- worper_processesは多めに
- worker_connectionsは少なめに
- nginxとは逆ｗ
- nginxがイベント駆動であることは忘れるｗ
- JPEG Hinting
- 本当は早いImageMagickでググれ！
jpeghint=y- JPEG以外では無視される
- libjpeg-turbo
- OpenMP
- WebP
- JPEG / PNGと比べて軽量
- ImageMagickとGDで使える
- Cache
ImageMagick + WebP
mirakuiさん
WebP
- ウェッピーです！！！！！！
なぜWebP?
- 小さい
- JPEGに比べて画質が劣化しにくい
- 半分以下ぐらい
WebPの欠点
- 対応環境が少ない
- 右クリックで画像を保存、でJPEGが欲しい人達がいる
- Webだと変な不評がでる
ネイティブアプリなら。。。
- Android 4.0以降なら大丈夫という噂もあるが。。。真に受けない方がいい
- 4.4以上で有効にしてる
Tofu
- ImageMagickが対応してる
- 調査すればノーコーディングでいけるのでは
yoyaさんのブログを見る
- 6.6.8から対応してた！
ただ6.6.8でのWebPはぶっ壊れてる
ChangeLogを追う
- 6.8.6-8まで。。。
ImageMagickのバージョンアップ怖すぎ問題
- 絶対避けたいこと
- ImageMagickのバージョンアップで画像の色味が変わってしまうこと
- 全てをチェックするのは無理
yoyaさんに相談
- 6.8.7からは色空間の扱いが変わった
- ここで色味が変わる可能性がある
- 6.8.7からは色空間の扱いが変わった
WebPにはどのバージョンを使えばいいか
- 6.8.6-8まで上げれば、必要十分
- 6.8.7からは色味が変わる可能性がある
- これから使う人は、最新を。
- 6.8.6-8まで上げれば、必要十分
ImageMagickアレコレ
- http://diary.awm.jp/~yoya/data/2015/02/18/ImageMagick-something.pdf
- yoya
今回はImageMagick 6だが、本家は既に7前提
6と7の違い
- ディレクトリ名が違うだけ。。。
ImageMagickってなんだっけ
- 画像を処理できる何か
- コマンドがある
- いろんな言語から使える
- フォーマットがたくさん
- 100種類以上のマイナーなものまで
- cssのinlineフォーマットまで対応してる
ImageMagickの開発傾向
- 活発すぎる
- APIのバイナリ互換とか気にしない
- コレに切れてforkしたのがGraphicsMagick
バージョン毎に声質が違う
- 全バージョンをそろえるｗｗｗ
- 600ぐらいビルドｗ
全バージョンで実行
QuantumDepth
- Q8/Q16
- RGBの各値を8bit/16bitのどっちで持つか
- 普通の人間の目なら8bitで十分
- ImageMagickはデフォルトQ16
Q8の問題点
- 医療用画像などではQ16なので使えない
- HDR等のフィルタでちょっと荒くなる
OpenMPが重い
JPEG画像変換
- 何故JPEGHintが早いのか
最近のトピック
- 6.8.7-4がエポックメイキング
- 6.8.8-2
- icoファイルをauto-resizeできるように
6.9.0-4
GIFアニメ最適化
- 変化のある部分を切り出して、透明にして軽量化
GraphicsMagickは？
- GIFアニメ生成が早いのは、実は単にエンジンが古いだけ
- GraphicsMagicはQ8デフォルトなので、比較するなら同一にしないとアンフェア
ImageMagickを弄りたくなった人へ
- Cristyさんはコミットコメントを書かないｗ
- コードはきれいなので、意図は伝わる。。。
RICOH THETAの全天球画像でペーパークラフト
- ちはやふるさん
全天球画像をつくる
RICOH THETAの静止画保存形式を切り取り、印刷
- iOSアプリ PazuCraft
- ペーパークラフトになるの面白い！
1px interpolation
https://docs.google.com/presentation/d/1R4htUndRQonOeTg35t17J8Lw4hWiHje0fWtm1xdIkds/edit#slide=id.p
Greeのひと
宮崎さん
- JS書いてる
1px interpolation
- 1pxの線を描画する際に、レンダラがどのドットに割り当てるか悩んで憤死するｗ
- ブラウザのバグ
再現方法
とあるECサイトに動的画像変換を導入した話
GMOペパボ yano3
カラメル
- ショッピングモールサイト
動的画像変換はしてなかった
- 提供元によって画像の仕様はさまざま
おから(仮)
- 動的画像変換サーバ
ngx_small_light
ハッシュ値があってたら、動的生成に投げる
今後
- WebP
ngx_small_lightの利用事例
- 導入の経緯
- バックグラウンドジョブで変換してたが、時間かかる
WebPの経緯
- 通信の改善
VagrantでCore OS VMからPushして、infratasterでCI、Merge押すとQuary.ioでビルド
CoreOSインスタンスを立てて切り替えて古いものを消す
- どのサーバでも同じフローで
遭遇した問題
- WebPの変換がおかしい
- mirakuiさんにきいたｗ
- nginxがcoredump吐く
- ImageMagickの初期化タイミングの問題だった
- nginx異常に高負荷になる
- WebPの変換がおかしい
JPEGのDCTブロックでコンテンツ指向のトリミング
4_sukeさんコンテンツの場所を考慮して切り取ってくれたらいいのに！
-
- 顔認識の結果をベースとしているらしい
- 顔認識は計算リソース必要
- 保存するとしても、ストレージ必要
- 顔以外は認識してくれない
JPEGエンコーダに手を加えればいいんじゃね？
- DCTブロックを直接参照すれば！
JPEGデコードの過程でDCT変換したデータが得られる
- 高周波成分が集まってるところが、経験則的には中心ぽくなる
ハフマン展開 + 逆コサイン変換を DCT変換の後に追加
- 人がたくさん入ってくると、平均化されて真ん中が切り抜かれがち
まとめ
- ナマの画像にそのまま使うので、計算量が少ない
- 追加実装も少ない
- 顔認証と違い、なんでも大丈夫
- JPEGにしか適用できない
- 文字が入ってると弱い
jpgjsに手を入れた
pixiv方式とどちらがいいか？
- どれだけコンテンツに対する仮定を置くか
- 何がメインか、によって違う
- 仮定を踏まえて定量評価するしかない
ImageHayabusa
Guntherさん
デザイン作業効率化
- 素材の切り出しや必要な素材サイズを毎回デザイナーにお願いしないといけない
- これを一発で
メリット
- 作業が楽になる
パラメータで様々な変換ができる
- PSDの特定のレイヤーを指定して書き出しもできる
初回は生成、２回目以降はキャッシュ
- CSSも出力し、中で使っているフォントもわかる
