はてなブックマーク

はじめに ドキュメントやソースコードから推測した ImageMagick の歴史メモです。 ImageMagick (無印)からImageMagick 7 までとなります。 識者の目に届いてより正確な情報が共有される呼び水になれれば幸いです。 ImageMagick 公開前 https://imagemagick.org/script/history.php 1987年に ImageMagick の開発が始まりました。 米DuPont 社の社員だった Cristy 氏が上司からの依頼で 256 色モニタに、なるべく元の見た目を維持して表示するツールとして開発を始めたそうです。 24ビットトゥルーカラー画像をそのまま表示できる環境が非常に高価で希少だった時代です。 ImageMagick (無印) 1990年8月。DuPont 社の許可を得て Usenet's comp.archives に

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 画像を表示する際に意図せぬ回転して困る事で有名な Exif Orientation に関するうんちくです。(2021年12月5日作成記事) Exif Orientation とは カメラ撮影で保存する JPEG 画像ファイルに関する主な規格として、DCF と Exif があります。 そのうち Exif の Orientation 情報は、カメラの向き等によって画像が本来意図するものと違う回転/鏡像で JPEG ファイルに保存される事を示すメタデータです。 図のように横長のカメラを縦にして撮影した場合、本来の映像を横に倒した画像

JPEG 画像ファイルはメタデータとして解像度(Resolution もしくは Density)値を DPI単位もしくはcm単位で保持できます。そのうんちくです。 JPEG 解像度について スキャナで映像を取り込んだ時やスクリーンショットで JPEG 保存した時など、 対象の物理的大きさを元に算出した DPI 値を JPEG ファイルに含める事が多いです。 スキャナだと 200 や 300、スクリーンショットは 72 や 144 が代表的な値です。 ベクター画像から JPEG に変換する場合だと 37 をよく見かけます。 とりあえず JPEG のメタデータを見るツールを作ってみました。JPEGファイルをドロップしてお試し下さい。 https://yoya.github.io/image.js/jpegmeta.html JavaScript でローカルに動くので、サーバにアップロードしませ

はじめに サーバでなくブラウザ側で画像処理が動く WebAssembly 版 ImageMagick 〜 magick-wasm の使い方と 2023年初頭での状況報告です。 https://github.com/dlemstra/magick-wasm magick-wasm 本体にまだブラックボックス要素があるので、本体自体の解説はせず、今回は、実際に magick-wasm を使う事ができた。でも機能的に物足りなく感じた。それだけの解説エントリです。 書いたきっかけ magick-wasm 使いたいけど分からないと呟いてたら作者からリプライを貰ったので、自分で解説書くしかないなと。。٩( 'ω' )و There is a demo repository here: github.com/dlemstra/magic... that uses the library with @vu

HEIF / HEIC HEIF は主に H.265/HEVC のエンコーダを使って画像をファイル化します。 ただ、HEIF 自体は H.264/AVC や JPEG 等も入れられる汎用画像コンテナフォーマット規格です。 そこで H.265/HEVC の画像が含まれる事を示すのに HEIC の呼称があり、拡張子によく使われます。ImageMagick における HEIF のコーダー名は HEIC です。 ImageMagick の HEIF 対応 2018年5月リリースの ImageMagick-7.0.7-32 (6系は 6.9.9-44) で HEIF 画像に対応しました。 実はその前に、2018年1月の ImageMagick-7.0.7-22 で HEIF 対応したのですが、色々と問題があり、その実装はなかった事にして、libheif の利用を前提にいちから作り直してます。(詳しく

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 画像リサイズ処理の個性についてのうんちく話です。(2019年06月04日 投稿) はじめに ビットマップ画像は表示する状況に応じてさりげなくリサイズ処理するシーンが多々あります。 そのリサイズ結果をよく眺めると、同じ画像を同じサイズ(width x height)指定でリサイズしても、アプリの種類やその時々の状況で異なる画像が生成される事に気づくでしょう。 その差異になり得る要素を紹介します。 アスペクト比と内接外接 補間フィルタ iDCT scaling コーナー合わせ パレット色維持 ガンマ補正とリニアRGB 内部ビット深度 USM

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

世間には WebP Lossless が本当は Lossy(劣化) なのでは疑惑があるようで、本当に劣化するの？しないの？と気になり調べたメモです。 (2020年1月31日投稿) 結論はタイトルの通りで libwebp の古いバージョン含め Lossless(劣化しない)を確認しました。その際に気付いたいくつかの注意点も紹介します。 はじめに注意 WebP は 8bit 色深度のみ対応です。16bit 画像を WebP に変換すると bit 数を減らす分だけ劣化します。 Lossless エンコーダのオプション機能に、Near Lossless があります。わずかに劣化を覚悟して圧縮率を高めます。後の方で改めて解説します。デフォルトoffです。 色深度 8bit, 16bit 色深度の 8bit と 16 bit の違いを図にしました。表現できる色数が段違いです。 Web 上では今でも 8

世間では WebP Lossless は実は Lossy なのでは。という噂を聞くので、本当に劣化しないの？するの？と調べてみたメモです。 なお、"WebP Lossless" で Google 検索してトップに出てくるサイトでは Lossy だと断定しちゃってますけど、これはほぼ間違いです。 WebP lossless might be lossy https://wave.hatenablog.com/entry/2016/04/30/070900 真摯にも実験に使った TIFF 画像を公開してくれてるので調べられますが TIFF が 16bit 画像なんですよね。WebP は 8ビットしか扱えないので、その分の差分が出ています。ただ、今どき 16ビット駄目なの？と言われるとごめんなさいです。 仕様 https://developers.google.com/speed/webp/do

セピア調について 18世紀中頃〜19世紀初頭にかけて様々な感光剤による写真が発明され、多くのモノクロ写真が作られました。 それらは経年劣化で白が黄ばみ黒はくすみ、全体として色材のセピア(イカ墨)を思わせる茶色味がかった色になる傾向があった故に、古い写真の色調を表す代名詞としてセピア調(sepia-tone)の言葉が生まれました。 セピア調に退色した写真 セピアインクを使った図面 セピア色について セピア色という単語は、主に以下の３つの意味で使われているようです。 顔料としてのイカ墨のセピア セピアで書かれた古い絵の退色した様子 (セピア調の元ネタ) 古ぼけた写真の色調としてのセピア (本記事がターゲットとするセピア調) 顔料としてのセピアはイカ墨を乾燥させてインクとするもので歴史は古く、紀元前のまだギリシア文化の残る(Greco-Roman)古代ローマの頃には筆記用に使われていました。それ

昔々、WebP が世に知られはじめた頃、JPEG に比べてファイルサイズが節約できると評判の一方、色がくすむ悪評を耳にし距離を置いた人も多いと思います。 実は、libwebp は2年前(2017/1/31)にこの色の問題をオプション扱いで改善しています。libwebp を使っている ImageMagick もようやく昨日(2019/2/18)対応して気軽に試せるようになりました。この機会に少し情報をまとめてみます。 (2019年02月19日投稿) はじめにまとめ 2017年1月リリースの libwebp-0.6.0 から use-sharp-yuv オプションが追加され、ImageMagick は大幅に遅れて 2019年2月に対応しました。 この use-sharp-yuv を有効にすると色劣化の問題はかなり改善されます。少し処理が重たいのと少しファイルサイズが増えるデメリットはあります。

はじめに 実は、主に Mojave(10.14) で利用していた Xcode10 の頃から /usr/include は非推奨でした。 まず、Xcode10 を導入すると /usr/include が消えます。手動で復活させてもマイナー更新でいつの間にか消えたりしました。 (参考) Xcode10 の /usr/include インストール方法 (mojave) https://qiita.com/yoya/items/630c991a98e4554e6e87 Xcode10 リリースノート Xcode10 から /usr/include が無い件は、そのリリースノートに説明があります。 https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035624 The comma

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

特によく使われそうな OpenCV, PIL(Pillow), scikit-image で処理するサンプル例を紹介します。(2019年06月19日投稿) 前提知識 カラー画像のグレースケール化は、各ピクセルの R,G,B を適切に混ぜて 1つの値にする処理です。 R,G,B をどの割合で混ぜるかは、主に BT.601 と BT.709 規格の係数が使われます。この２つは 微妙に結果が異なります。 JPEG/PNG 画像の多くは sRGB 規格に従い、その RGB 値はリニア輝度からおよそ 1.0/2.2(=0.4545..)相当のガンマ補正がかかるので、値をそのまま四則演算するとおかしな結果になりがちです。 グレースケール処理の詳細は、こちらをどうぞ。 グレースケール画像のうんちく https://qiita.com/yoya/items/96c36b069e74398796f3 Ope

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

前篇、中編、後編の三部作に分けます。この記事は前編です、 ビット深度自体は知ってて具体的な処理を知りたい方は、この記事を読み飛ばして中編から読んでください。 RGB ビット深度のうんちく (前編) 〜 前提知識 https://qiita.com/yoya/items/41b00127b0b1fea8c4f1 RGB ビット深度のうんちく (中編) 〜 実数型と整数型の変換 https://qiita.com/yoya/items/6ee02736f1db8bdd520e RGB ビット深度のうんちく (後編) 〜 整数型同士の変換 https://qiita.com/yoya/items/3509bbb54c0732865882 サンプルデモを作りました。任意の画像のビット深度を変更できます。お試し下さい。 http://app.awm.jp/image.js/bitdepth.html

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

gamma:(1/2.2=0.4545...) で左上の点線カーブ、gamma:2.2 で 右下の実線カーブを描きます。0〜1 に対するべき乗なので、gamma値 が大きいほどカーブが引き下げられる事に注意して下さい。 昔のモニタの特性が下の実線カーブに近かったので、そのガンマ補正がかかるのを想定して、実際の輝度スケールに対し上の点線の補正をかける規格が RGB に適用されています。 メリット 冒頭で少し触れましたが、各家庭のテレビに入力電圧と輝度がリニアになるよう頑張る装置を載せるより、放送局側でガンマ補正した方が業界全体としてのコストが圧倒的に安いのがまず一点。 人の眼の視覚特性は低輝度の変化に敏感で高輝度で鈍感な性質があり、ガンマ補正はその点でも都合が良いです。 例えば階調が100分割だとしてガンマ補正された値は、上記グラフだと輝度50以下で 0〜73、50以上に 75〜100 の値