画像変換Night #imgconv 参加メモ

画像変換Night

業務で動的画像変換処理を実装しているので、参加してみた。

発表はどれも内容が濃いものばかりで、普段はHTMLやJSなどフロントエンドばかりやっている自分とはレベルが違いすぎた。

サムネイルマスタとgo-thumber @harukasan

  • Webサービスにおける画像投稿機能事例
    • オリジナル画像をそのまま配信
      • 転送量が多い
      • 画像の読み込みが遅い
      • サムネイルをつくるのが大変
      • サービスが大きくなるにつれてきつくなる
    • アップロード時にサムネイル作成
      • アップロード処理が大変
      • 処理完了までにユーザを待たせてしまう
      • サイズ変更が難しい
    • リクエスト時にサムネイル作成
      • 動的変換
      • デザイン変更が簡単
      • キャッシュしてくれればリクエストは少ない
      • smalllight, tofu
  • サムネイル生成で困ること
    • 生成元画像に依存
    • 処理が面倒
      • 様々な画像フォーマットに対応しないといけない
  • サムネイルマスタ
    • サムネイル生成元となるマスタ画像
    • 長年培われた技術
      • 縦横の長さでクロップ位置を変える
    • サムネイルマスタを基にしたサムネイル画像生成
  • JPEGにおける問題
    • カラーモデルがなんでもいい
    • JPEG/JFIF
    • JPEG/EXIF
  • JPEG/EXIFにおける問題
    • ICCプロファイルは解釈するのにモニタプロファイルは無視したり
    • どう扱えばいいか難しい
  • CMYK JPEG 表示できない問題
  • JPEGにおける色空間
    • 色空間がいろいろ違う
  • どうすればよいのか
    • カラーマネジメントできるエンジニアが不在
    • 結局諦める
  • サムネイルマスタで問題を緩和
    • JPEG/JFIF互換のJPEGをつくる
    • ICCプロファイルを考慮するとOKなユーザ、NGなユーザが存在する
  • go-thumber
    • LibJPEG APIを生で叩いているため高速
    • ベンチマーク
      • smalllight(imlib2), smalllight(magick), go-thumber
      • スループット, 平均処理時間
      • imlib2と同じくらいの精度
    • ブラインドテスト
      • 50%以上の人に選ばれた
      • go-thumberの圧勝
    • スケーリングデコードのサイズ最適化
    • サムネイルマスタとgo-thumber
      • サムネイルマスタにいろいろな問題を押しこむことでサムネイル作成を簡単に
      • go-thumberが安定しているのでうまくいっている

実践ngx_small_light入門 @cubicdaiya

  • ngx_small_light
  • small_light_getparam_mode
    • 画像変換のパラメータをquerystringに指定出来る
  • 外部サーバ(s3)にある画像をngx_small_lightで変換する
  • 画像ライブラリの比較
  • その他の変換モジュール
    • mod_small_light
      • 元祖SmalllightのApacheモジュール
    • ngx_http_image_filter
      • Nginxの標準モジュール
    • go-thumber
      • pixiv謹製画像変換プロキシサーバ
      • 特定条件下では絶大な効果
  • worker_(processes|connections)
    • worker_processesは多めに
    • worker_connectionは少なめに
    • ngx_small_ligheを使うときはngxがイベント駆動だということは忘れる
  • libjpeg-turbo
    • x86とx86_64に最適化されたlibjpeg
  • OpenMP
    • マルチプロセスが走る環境ではOpenMPを無効にするのがベストプラクティス
  • WebP
    • Googleが開発しているフォーマット
    • ngx_small_lightはImageMagickとGDで利用可能
  • Cache
  • まとめ
    • 機能豊富なnginxモジュール
    • 画像変換は重いので相応のチューニングをしましょう

ImageMagick + WebP (仮) @mirakui

  • 今日覚えて帰って欲しいこと
    • WebP
      • ウェッピー!ウェブピーではない!
  • クックパッドでの採用事例
    • iOS/Androidアプリの料理写真
  • WebPの欠点
    • 対応環境が少ない
    • 「右クリックで画像を保存」でJPEGが欲しい人
      • facebookのwebp不詳事件
      • ネイティブアプリなら問題無いのでは?
  • Tofu
    • クックパッドにおける画像動的変換システム
    • Apacheモジュール + ImageMagick
  • ImageMagickでWebP

    • 6.6.8で対応
    • 当時Tofuは6.7.6
  • ImageMagick-6.6.8でのWebP

    • WebP変換時にQuality(画質)の指定ができない
      • WebPの目玉である画質コントロールが出来ない
      • 返還後は常に0になる
    • メモリリーク
    • 要するに壊れている
  • WebP対応するためにImageMagickのバージョンアップが強いられる
  • ImageMagickバージョンアップが怖い問題
    • 出力画像の色味が変わってしまうことだけは避けたい
  • WebPのためにどのバージョンを使えばいいか
    • すでに利用中(6.8.7以前)のシステム
      • 6.8.6-8まであげれば必要十分
      • 6.8.6-8でWindows対応もされている
    • これから利用するシステム
      • 最新版でOK

ImageMagickアレコレ @yoya

  • ImageMagickとは
    • 画像処理が出来る何か
    • コマンドが用意されている
    • 各言語から利用できる
    • 対応フォーマットはマイナーなものまで100種類以上
    • MagickCoreというエンジンと、プラグイン的なcorder集合体と、ユーティリティ的なMagickWand APIと、結びつくコマンドラインや言語バインディングの仕組み
  • ImageMagickの開発傾向
    • 良くも悪くも活発
      • 新しい機能やフォーマットを取り込んでリリースするがよくデグレる
    • APIのバイナリ互換とか気にしない
      • キレてフォークしたのがGraphicsMagick
  • バージョン間の差異の確認
    • 全バージョンをビルドして実行(手元に600個w)
    • バージョンごとの出力画像を並べて目視
  • QuantumDepth
    • RGBの各値を 8bit/16bit どちらで持つか
    • ImageMagickはデフォでQ16
    • 普通の人ではQ8でもQ16でも違いはわからない
    • Q8はQ16の使用メモリ半分で済む
  • 6.8.7-4のトピック
    • OpenCLにガチ対応し始めた
    • 減色処理の高速化
      • GIFアニメーション作成も速くなるはず
  • 6.9.0-4のトピック
    • Inline 形式出力変換 (ImageMagick-6.9.0-4)
      • Web data スキーマ base64 inline 画像
  • GraphicsMagickのdis
    • 最新のImageMagickと比べると速度はあまり変わらない
    • GraphicsMagickはGIF最適化出来ない
    • GraphicsMagickのデフォルトがQ8
      • ImageMagickのデフォルトがQ16なのでQ8で比較しないとアンフェア

RICOH THETAの全天球画像でペーパークラフト作成 @chihayafuru

  • 全天球画像をつくる
  • RICOH THETAの静止画を加工
  • 印刷してペーパークラフト!
  • 加工処理をPazuCraftというアプリ化

1px interpolation

  • 1px interpolation
    • 1ピクセルの線を描画する際に、レンダラがどのドットに割り当てるか悩んで憤死する
    • WebKit ブラウザに潜んでいるバグ
  • 再現方法
    • 1pxに線を含む画像
    • Chrome or SafariのHTMLCanvas
      • 256x256以上
    • アンチエイリアスをオフ
    • Y軸方向に0.5pxずらす

とあるECサイトに動的変換を導入した話 @yano3

  • 問題点
    • 動的画像変換をしていない
    • 画像の仕様が提供元によって違う
  • おから(仮)を作った
    • 動的画像変換サーバ
    • ngx_small_light
    • ngx_mruby
    • CDN
  • 今後
    • WebP

nginx-image-server @spesnova

  • WANTEDLY
  • ngx_small_lightの利用事例
  • ngx_small_light導入の経緯
    • 動的にリサイズしたい!
  • WebP導入の経緯
    • 通信量の改善
  • サーバ構成
    • Nginxコンテナ
    • Dockerデーモン
    • CoreOSサーバ
  • 遭遇した問題
    • WebPの変換がおかしい
    • Nginxがcoredumpを吐く
    • Nginxが異常に高負荷になる
    • AWS上でCoreOSがクラッシュ
      • kernelのバグ
      • 継続的なOSアップデート
  • まとめ
    • ImageMagickのビルド、一度動いたらイメージに焼いてしまいたい
    • Dockerで全部同じフローでデプロイできる

JPEGのDCTブロックでコンテンツ指向のトリミング @4_suke

  • 構図を工夫して撮影した写真がサムネイルで残念になる
  • Facebook
    • 顔認識の結果をベースにして、トリミング範囲を決めている
    • 顔認識は計算リソースがかなり必要
    • 顔以外は認識してくれない
  • JPEGエンコーダに手を加えればいい
    • DCT変換して高周波成分の多い場所にコンテンツがある可能性が高い
    • 高周波成分の中心位置を決め、トリミングをする
  • メリット
    • JPEGの圧縮展開工程内のDCTをそのまま使うので追加計算が少ない
    • 追加実装も少ない
  • デメリット
    • JPEGのみに対応
    • 文字が入っているコンテンツが苦手
  • pixiv方式とどっちがいいか
    • アプローチの仕方が違いそう
    • 定量評価するしかないのでは

デザイン作業効率化「ImageHayabusa」 @gunta85

  • デザイナー、フロントエンド、ネイティブエンジニアの間でタイムロスがあった
    • 素材の切り出しやspriteの出力を毎回依頼しないといけない
    • これをオンデマンドで可能にした
  • メリット
    • 作業が楽になる
  • PSDやイラストをREST APIで変換が出来る

    • もちろんWebP対応!
  • nw.jsでMacアプリ化

    • ローカルでも使える
Meetupimgconv