https://docs.google.com/presentation/d/1LHplQ8nqNJNxaqY7DL4eM329jZKfO-E15XHoadYeLfE/edit
広色域時代の画像の正しい扱いかた | tech - 氾濫原
モバイル端末も iPhone7 など DCI-P3 サポートが増えてきて、CSS での広色域サポートもはじまりつつあるなかで、サーバサイドなどで画像をとりあつかうときに、正しく扱えていないというのはとても微妙です。HTTPS 対応が当然になっていくように、広色域対応も当然のこととなっていくことでしょう。 正しいやりかたといっても簡単で、 付属するICCプロファイルをそのままにする (一番簡単) なんらかの事情で sRGB にするならするでプロファイル変換する (CMSが必要) ということです。全然当たり前で面白くないですね。でも考慮してないことが多いのではないでしょうか。 まず付属するICCプロファイルを保持するというのは一番簡単で確実です。 一方で小さい画像だとICCプロファイルのサイズが無視できなくなるので色再現よりファイルサイズを優先したいという場合もあります。この場合は sRGB
WebP – Webを速くするためにGoogleがやっていること Make the Web Faster 01 –
WebP – Webを速くするためにGoogleがやっていること Make the Web Faster 01 – Jxck 画像は、サイズが大きい（大きくなりがちな）コンテンツの一つです。 最近は画像を使わないページはほとんどなく、むしろ使う量はどんどん増えているんじゃないでしょうか。また、HiDPI対応などでサイズも増えつつあるでしょう。 Googleの調査では、現在Web上のトラフィックの65%を画像が占めているそうです。Introで解説したように、パフォーマンスを考えるとファイルサイズは「なるべく小さく」が望ましいため、画像は通常圧縮された形式で使用されます。 WebPは、Googleが開発した圧縮形式で、従来の形式よりもファイルサイズを小さくすることを目的としています。今回はそんなWebPの概要と使い方、注意点を取り上げます。 画像圧縮とは？ ここで対象としているのはピクセル形式
ImageMagickのピクセルキャッシュとリソース制限 - クックパッド開発者ブログ
こんにちは、成田（@mirakui）です。今日はみんな大好き ImageMagick チューニングのお話です。 2016/5/13 に公開された、いわゆる ImageTragick と呼ばれる脆弱性では、 policy.xml というファイルを更新するという workaround が紹介されていたのは記憶に新しいと思います。 この policy.xml は、今回の workaround のようにファイルタイプを制限するだけではなく、画像の縦横ピクセル数、利用するメモリやディスクのサイズなどを制限することができます。 Web サービスなどでユーザのアップロードした画像を ImageMagick で変換する場合、このようなリソース制限を適切に行うべきでしょう。 そこで今回は policy.xml によるリソース制限方法を紹介します。 前提 特に明記しない限り、2016/05/14 現在の 6
Golangで画像プロキシサーバをつくった - yuhei.kagaya
Graidという画像プロキシサーバをつくりました。 外のサーバから画像を取得してリサイズしたりして返す、ということをするサーバです。 Golangでなんかミドルウェア的なものが作ってみたかったのでやってみました。 Graidについてのスライド エンジニアが集まってお昼ご飯を食べながら技術的なネタを話すテックランチという会が社内で定期的に開催されているので、Graidについて話してきました。 Graid // Speaker Deck 機能 http://localhost:8080/path/to/image.jpg:w400:h300:q80 例えば8080ポートで起動させてURLにアクセスすると、 オリジンの画像サーバ（設定ファイルに設定する）の/path/to/image.jpgを取ってきて 横400px、縦300pxにリサイズして画質80%に加工して レスポンスを返す という処理を
もうサムネイルで泣かないための ImageMagick ノウハウ集 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちわ、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなみかんは紅マドンナです。 今回は、サイボウズのサムネイル事情について記事を書きたいと思います。サイボウズに限らず通常の Web アプリケーションでもサムネイル作成はよくあると思いますが、ハマりどころが多く涙しているサムネイリストも多いかと思います。これからの時代を生きるサムネイリストが快適なサムネイルライフを送れるよう、知見を共有したいと思います。 弊社では画像変換ツールに ImageMagick を用いており、従って本知見は ImageMagick 固有のものがほとんどです。 画像比較は人間の眼で行うべし サムネイル周りに何か修正を入れたら修正前後の画像を比較しましょう。機械によるバイト列の比較では画像の良し悪しがわかりません。頼れるのは人間の眼だけです。肉眼で確認しましょう。 比較できるツールを作ると良
GIF アニメ生成は本当に GraphicsMagick で行うべきか？ | GREE Engineering
具体的には以下のように使い分けると良いでしょう。 手早く GIF アニメを作りたい > GraphicsMagick Web のバックエンドで動かしたい > YoyaMagick YoyaMagick が使える環境ではない > ImageMagick 自分が今まで耳にした誤解を元に、ポイントを列挙します。 まず、ImageMagick の GIF アニメ生成に時間がかかる場合、その処理の大半は減色処理です。 ImageMagick の減色は主に減色専用のデータ構造を用いる為、Q8, Q16 (*2)による性能の違いは殆どありません。 実は、GIF アニメ最適化の差分フレーム抽出は、減色やGIF エンコードの時間に比べて殆ど時間が掛かりません。 差分フレームが小さい程、２枚目以降の GIF 画像が小さくなり、むしろ全体として処理時間が短くなります。 ImageMagick に比べて、Grap
MOONGIFT: » 待ちに待ったオープンソースの日本語OCR「NHocr」:オープンソースを毎日紹介
OCRという技術はアナログなデータをデジタル化する上で欠かすことができない。しかし様々な特許が絡み、オープンソースやフリーウェアとしては発展しづらい分野でもある。しかしそこに風穴を開けられるかも知れない技術が登場しそうだ。 デモサービスで試せます 今回紹介するオープンソース・ソフトウェアはNHocr、日本語OCRシステムだ。Google Code上にホスティングされ、まだソースコードは一部しか開示されていないが、デモサービスは公開されている。 デモサービスでは、BMP/JPEG/PBM/PGM/PPMのファイル（さらに各ファイルをGZip圧縮していても可能）をアップロードすると、それを解析した結果を日本語表示してくれる。日本語OCRとあって、漢字/ひらがな/片仮名/英語などが判別可能になっている。 読み取らせた画像 手書き文字であっても認識率はそこそこ高い。正式リリースがまだという段階にあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
imgix - The End-to-End Visual Media Solution
Microsoft 課金サービス
GitHub - nagadomi/waifu2x: Image Super-Resolution for Anime-Style Art
画像変換Night - 資料一覧 - connpass
pypuzzle
otamapy
VT[4]Jユーザー事例