画像変換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 がイベント駆動だということは忘れる
  • JPEG Hinting

  • 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

  • http://hayabusa.io

  • デザイナー、フロントエンド、ネイティブエンジニアの間でタイムロスがあった

    • 素材の切り出しや sprite の出力を毎回依頼しないといけない
    • これをオンデマンドで可能にした
  • メリット

    • 作業が楽になる
  • PSD やイラストを REST API で変換が出来る

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

    • ローカルでも使える