画像の価値は上がったのに、技術は10年前から変わっていない ─ ImageFluxで描く画像変換の世界(前編) - pixiv inside
2012年入社。ピクシブでインフラエンジニアとして活動している道井俊介。ニックネームは、はるかさん(@harukasan)。入社以来、彼は画像配信インフラに関わり続けています。 サービス開始当初はよく障害を起こしていたpixivの画像配信インフラも、対策を重ね、今では安定した配信を実現しています。2014年には、画像変換のためのGo製プロキシ「go-thumber」をオープンソースとして公開。メルカリの久保達彦氏と共著した技術評論社「nginx実践入門」などの執筆にも関わりました。現在は、さくらインターネットと提携し、メルカリなどで活用されている画像変換のクラウドサービス「ImageFlux」の開発リーダーとして活動しています。 まさに、画像変換の世界で最前線に立っているはるかさん。今回彼に、世界最大規模のイラスト画像配信インフラの中でやってきた取り組みを語っていただきながら、同技術の今と
ImageMagickのピクセルキャッシュとリソース制限 - クックパッド開発者ブログ
こんにちは、成田（@mirakui）です。今日はみんな大好き ImageMagick チューニングのお話です。 2016/5/13 に公開された、いわゆる ImageTragick と呼ばれる脆弱性では、 policy.xml というファイルを更新するという workaround が紹介されていたのは記憶に新しいと思います。 この policy.xml は、今回の workaround のようにファイルタイプを制限するだけではなく、画像の縦横ピクセル数、利用するメモリやディスクのサイズなどを制限することができます。 Web サービスなどでユーザのアップロードした画像を ImageMagick で変換する場合、このようなリソース制限を適切に行うべきでしょう。 そこで今回は policy.xml によるリソース制限方法を紹介します。 前提 特に明記しない限り、2016/05/14 現在の 6
もうサムネイルで泣かないための ImageMagick ノウハウ集に一言ツッコミ // Speaker Deck
もうサムネイルで泣かないための ImageMagick ノウハウ集に一言ツッコミ
もうサムネイルで泣かないための ImageMagick ノウハウ集 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちわ、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなみかんは紅マドンナです。 今回は、サイボウズのサムネイル事情について記事を書きたいと思います。サイボウズに限らず通常の Web アプリケーションでもサムネイル作成はよくあると思いますが、ハマりどころが多く涙しているサムネイリストも多いかと思います。これからの時代を生きるサムネイリストが快適なサムネイルライフを送れるよう、知見を共有したいと思います。 弊社では画像変換ツールに ImageMagick を用いており、従って本知見は ImageMagick 固有のものがほとんどです。 画像比較は人間の眼で行うべし サムネイル周りに何か修正を入れたら修正前後の画像を比較しましょう。機械によるバイト列の比較では画像の良し悪しがわかりません。頼れるのは人間の眼だけです。肉眼で確認しましょう。 比較できるツールを作ると良
ImageMagick と go-thumber(swscale)のリサイズ性能比較 - yoya's diary
go-thumber(https://github.com/pixiv/go-thumber) にコマンドラインで画像変換する main ルーチン(mkthumb)が含まれていたので、それを使って ImageMagick と性能を比較してみました。(つまりネットワークを使わない、画像ファイル変換処理のみの比較) 検証環境 動作環境は MacBookPro 13inch 2014 mid モデルの SSD つき。 ImageMagick(v6.9.0-6) は MacPorts から。libjpeg と swscale ライブラリ(ffmpegに含まれる)は HomeBrew で入れてます。 尚、この評価用に集めた 487枚のイラストJPEG画像(縦横サイズは大体1000x1000位)をアスペクト比無視で 80x80 に縮小リサイズしました。 ImageMagick の convert で変
How We Gain "Mobile First" Using WebP with ImageMagick
2015/2/18 画像変換Night http://connpass.com/event/11516/
画像ライブラリGrappyの作成と、ImageMagick, GDとの比較【実装編】 | 株式会社サイバーエージェント 株式会社サイバーエージェント
概要 簡単な画像処理機能も備えた、シンプルかつ高速そしてAnimationGIFをサポートした画像形式変換ライブラリの Grappy を実装した。 これの性能について、ImageMagick, GDと、下記の比較を行った。 SSIMによる画質の比較 処理速度 Valgrindを使ったヒープメモリの使用量 ファイルサイズに関して 最後にそれらとの比較結果から、Grappyの優位性について述べた。 1.はじめに 画像のエンコード・デコードやリサイズといった処理をサービスに組み込もうと考えた場合、多くの場合は高レベルな画像処理をサポートした既存のライブラリの利用を検討することとなる。 しかし、既存のライブラリは機能と速度のバランスが悪く、使いにくいものであった。 Webサービスの中に画像関係の機能を取り入れる場合、求められるのは次のような単純な要求項目に限られる場合が多い。 JPEG, PN
GIF アニメ生成は本当に GraphicsMagick で行うべきか？ | GREE Engineering
具体的には以下のように使い分けると良いでしょう。 手早く GIF アニメを作りたい > GraphicsMagick Web のバックエンドで動かしたい > YoyaMagick YoyaMagick が使える環境ではない > ImageMagick 自分が今まで耳にした誤解を元に、ポイントを列挙します。 まず、ImageMagick の GIF アニメ生成に時間がかかる場合、その処理の大半は減色処理です。 ImageMagick の減色は主に減色専用のデータ構造を用いる為、Q8, Q16 (*2)による性能の違いは殆どありません。 実は、GIF アニメ最適化の差分フレーム抽出は、減色やGIF エンコードの時間に比べて殆ど時間が掛かりません。 差分フレームが小さい程、２枚目以降の GIF 画像が小さくなり、むしろ全体として処理時間が短くなります。 ImageMagick に比べて、Grap
ImageMagick 改造入門 (その弐) 減色処理前編 | GREE Engineering
こんにちは。クライアント基盤チームのよやです。 アバター等を表示する為に PNG や JPEG の画像を元に GIF アニメーションを生成する事がよくありますが、GIF は 256色までしか扱えない為、元画像が数万といった単位で色を使っていると減色処理に大変時間がかかります。そこで、ImageMagick の減色処理を改造して高速化した事例をご紹介します。 尚、一度に読む分量ではまとめ切れない為、前編と後編に分けました。前編は減色処理、後編はその改造について説明します。 プログラム構成では上の図の magick/quantize.c が減色処理に相当します。 まず、減色処理の一般的な話から始めます。 減色の利点 Web で見かける画像ファイルの多くは、1つのpixel(描画の最小単位)に対して、Red, Green, Blue が各々8bits で計 24bits(= 3bytes) 、透
ImageMagick 改造入門 (その壱) GIFアニメーション | GREE Engineering
こんにちは。ミドルウェア開発チームのよやです。 今回は、ImageMagick についてお話します。 http://www.imagemagick.org/ ImageMagick は高機能で大変便利な画像処理ツールです。弊社でも利用させて頂いていますが、稀に実サービスにそのまま適用出来ないケースがあります。 そこで、困った時に ImageMagick 自体を改造する際のポイントと、実際の応用例をご紹介します。 ImageMagick のプログラム構造 ImageMagick のプログラムは主に以下のディレクトリに分かれます。(Magick+ ディレクトリ等幾つかは割愛します) utilities/<コマンド名>.c コマンドラインツールの起点(main 関数) wand/〜.c (コマンド共通処理とコマンド毎の処理、Wand API) magick/〜.c (機能モジュール、ユーティリテ
本当は速いImageMagick: サムネイル画像生成を10倍速くする方法 - 昼メシ物語
一般的に ImageMagick のサムネイル画像生成は遅いとされており、パフォーマンスが求められるシーンでは Imlib2 などのより高速な画像処理ライブラリが使われることが多いです。 Imlib2 の高速さについては、以前「Imlib2でImageMagickより3倍高速かつ美しいサムネイル画像の生成 - 床のトルストイ、ゲイとするとのこと」という記事で紹介しました。この記事のベンチマークにおいて、Imlib2 によるサムネイル画像の生成は、 ImageMagick の3倍程高速でした。 しかし、 ImageMagick は Imlib2 より画質がよく、高機能で使いやすく、今も頻繁にメンテナンスされており、とてもよく出来ています。その点 Imlib2 は、2004年からメンテナンスされておらず、セキュリティホールが見つかっても、各Linuxディストリビューションがそれぞれパッチを当て
Imlib2でImageMagickより3倍高速かつ美しいサムネイル画像の生成 - 昼メシ物語
この記事の概要 Imlib2を使って画像のサムネイルを生成してみたところ、ImageMagickより3倍速かった。 また一般的には、Imlib2の方が画質が悪いとされているが、パラメータを調整することで、十分に美しいサムネイル画像を得ることができた。 はじめに Imlib2は画像処理ライブラリ。mixiの発表資料大規模画像配信とPerl によれば、mixiは高速に高品質なサムネイルを生成するために、ImageMagickでなくImlib2を選んでいる。 上記資料の中では、以下のように説明されている。 速度 Epeg > Imlib2 > Imager >>> ImageMagick 画質 ImageMagick > Imlib2 >>> EpegImlibの画質は多少ImageMagickに劣るが、速度は十分に速い、とのこと。 一方で、404 Not Foundという記事では、ImageM
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ImageMagick アレコレ
How do I install ImageMagick 6.5.6 on Debian Lenny?