I code therefore...

Yuji Miyane's blog - programming, signal processing, art, music, etc.

ImageMagick (1) インストール編

ImageMagickとは

画像処理用ソフトウエアライブラリ。

http://www.imagemagick.org/

スペルが変だがこれで正しい(ImageMagicは誤り)。このようにスペルをわざといじるのは名前付けの有効なテクニック。ユニークな名前の方が覚えてもらえるし、検索もしやすくなる。

基本的な使用法はコマンドラインツールで、UnixシェルやWindowsコマンドプロンプトなどから利用する。2番目の利用法はAPIで、開発環境経由でアプリケーションの内部処理に用いられる。

特にUnix系アプリは内部処理をImageMagickで行っているものが多い。

この分野の現役ライブラリでは最も古くかつ今でもメジャーなものの一つで、画像処理として考えられる機能はほぼ完全網羅している。

  • ファイルフォーマット変換(この点ではたぶん世界No.1)
  • 画像変換(基本、応用すべて)
    • サイズ変更、切り取り、拡大縮小、回転、反転、変形
    • 色彩調整(明暗、コントラスト、RGB、Alpha, etc.)
    • 各種描画(外枠、文字列、図形等)、特殊効果(多すぎて略)
  • アニメーション、モーフィング、ディザー処理、フーリエ変換、etc.
  • これ以外にも山ほど(以下略)

画像変換で何ができるかは次を見るとよい(これでもまだ全体の一部)。

http://www.imagemagick.org/script/examples.php

今もばりばり現役なので新トピックへの対応も早い。特に新フォーマット対応が充実している(ここはNo.1を自負している以上譲れないポイント)。

  • 主要カメラメーカーのraw image (Canon, Kodak, Nikon, Olympus, Sony/Minolta, etc.)
  • SVG(読み込んでビットマップに変換できる)
  • GIMPXCFなど現在進行形のフォーマットも対応が早い

画像ライブラリとして考えられることはほぼ全て対応しており、特に画像を高画質で処理するのに適している。そのため処理は画質優先で、逆に速度が最重要となる場合にはあまり向いていない。

ImageMagickにはユーザーインターフェースは付いていない(簡単なビューアのみ)。コマンドライン実行か、またはアプリの開発環境からAPIを通じてライブラリコードを利用するという形で用いる。

以下始めの一歩としてインストール方法から説明する。Linux系は特に難しい点はないが、Windowsは(インストール場所が自由なのが災いして)注意点が多い。

Windowsで今まで体験した失敗パターンがいくつもあり、書いていたら長くなってしまったので単独トピックにした。しかしどんなツールでも導入時が一番大変というケースは多いし、こういうことは一番つまらないけど大事だと思う。

Linux(Unix系)

プリインストールの確認

ImageMagickはUnix系の定番ライブラリで多くのアプリが利用しているためLinuxディストリビューションにはよくプリインストールされている。以下は自分が使っているUbuntu 16.04上の確認例(convertはImageMagickの画像変換コマンド)。

$ convert -version
Version: ImageMagick 6.8.9-9 Q16 x86_64 2016-06-01 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
...以下略...

(Ubuntuユーザー用参考): apt-cache rdepends imagemagickで依存性を逆引きするとLibreOfficeやgnupgなど多数のアプリがImageMagickを利用しているのが分かる。

自分の場合はこれでおしまい。ここから先は自分では確認してないのであしからず(だいたい合ってると思うけど…)。

パッケージマネージャを使う

もしプリインストールされてなかったら次の手段はパッケージマネージャ。パッケージマネージャは大きく分けてdpkgとRPMという二大派閥がある。Debian/Ubuntu系はdpkg派で、コマンドラインからはapt-getを使う(GUIツールのSynapticでもOK)。

$ sudo apt-get install imagemagick

RPM派の代表はCentOS。yumを使う場合の例。

$ sudo yum install imagemagick

Macもbrewを使えば同じようにできるはず(でもMacは持ってないので…)。

最新版が必要な場合はUnix Binary Releaseがある(下記URL)。ただしこれが使えるのはRPMで管理している環境のみ(CentOSなど)。どうしても最新版が必要という場合だけ考えればいい(十分枯れているので最新版にこだわる必要なし)。

http://imagemagick.org/script/binary-releases.php#unix

ソースからインストールする場合

今のUnixディストリビューションなら必ずパッケージマネージャが使えるはず。でも興味があればソースからビルドすることも可能。次を参照(しかしあくまで物好きな人用、または運悪くパッケージマネージャを利用できない人向け)。

http://imagemagick.org/script/install-source.php#unix

実はImageMagickは多くの外部ライブラリに依存している。そのため依存する外部ライブラリを全部用意してldconfigで解決しなければならないのでかなり敷居は高い。具体的には次のステップで大量のエラーメッセージを覚悟しておく必要がある。

sudo ldconfig /usr/local/lib

自分は全くやる気がしないが、今動いているImageMagickがどれだけの外部ライブラリに依存しているか調べることならできる(大変さが分かる)。ここだけ実際に確認してみた(以下は参考: Ubuntu 16.04の場合)。

インストール済み環境ではapt-cache depends imagemagickで依存性を検索できる。順番に子孫を辿ると心臓部のlibmagickcore-6.q16-2(およびその関連パッケージ群)に到達し、それらが多くの外部ライブラリに依存しているのを確認できる。

$ apt-cache depends libmagickcore-6.q16
libmagickcore-6.q16-2
  PreDepends: dpkg
    dpkg:i386
  Depends: libbz2-1.0
  Depends: libc6
  Depends: libfftw3-double3
...以下長いので略...

Dependsが依存パッケージで、libmagickcore-6.q16-2だけで20個、関連パッケージも含めると(重複を除去しても)40個くらいはある。パッケージマネージャならコマンド一発で自動解決できるが手動インストールだと大変な手間になる。調査はここで打ち切り。

まとめ: プリインストールされていればそれを使う。次はパッケージマネージャ。ソースビルドは最終手段。

Windows

こちらはWindows特有のややこしい問題がいくつもあるので順番に詳しく説明する。まずWindows Binary Releaseから目的に合ったものをダウンロードする(これを書いている時点の最新バージョンは7.0.2)。

http://www.imagemagick.org/script/binary-releases.php#windows

でも種類が多くて何を選べばいいか分からない人が多いはず。まとめてみた。

  • Q8Q16は画素のビット深度の違い(今はQ16が定番)
    • Q16はQ8の約2倍メモリーを食う(でも今はもうQ8はメモリーが高かった頃の名残)
    • Q8は気を付けないと色彩の分解能がよく不足する(今はこの方が問題)
    • 参考: UnixのパッケージマネージャはQ16のみ
  • HDRIはver. 7から導入された高画質用バージョン(通常は不要)
  • x86x64はCPU(OSと言い換えてもいい)の違い(x86は32bit、x64は64bit)
  • dllはDLL版、staticはstatic版(違いはこの後詳しく説明)
  • portableはインストーラなしのstatic版

Hi-Fiオーディオに例えるとQ8とQ16の違いはCD(16bit)とハイレゾ(例えば24bit)、HDRIはSACDみたいなもの。Q8は最終結果に使うだけなら問題ないが、Q8で何回も繰り返し処理すると誤差が蓄積されて目に見えてしまう。

(1) DLL版

以下「DLL版のメリットは特殊な場合だけでデメリットの方が多い」という主旨(やや長文)。余計なことは覚えたくないという人はスキップしてstatic版かportable版をインストールするといい。

DLL版は共有(動的)ライブラリ(DLL)を導入して最大限に利用することが特徴。特に並列実行時に全プロセスが同じコードを共有することによりメモリーを削減し、さらに起動時間も短縮できるメリットがある。

複数起動する場合はDLLコードは最初の起動時のみメモリー上にロードされる。2つ目以降は最初にロードしたメモリー上のコードを再利用するため起動時間は短く、メモリーも節約できる。

しかしDLLを使うソフトウエアは(自分の経験上)インストール時のトラブルが起きやすい。一番多いのは外部DLLの追加インストールが必要なケースで、現在のDLL版ImageMagickも(VC++2013の)vcomp120.dllを別途用意しないと動作しない。

次に多いのは実行プログラム(.exe)の起動処理中にDLL(.dll)をロードできないケース。DLLロード時のモジュール検索でDLLファイルを見つけられないのが理由だが、その元となる原因はいくつも考えられる。

典型的な原因の一つは環境変数のPathに問題がある場合で、DLLもパスを使って検索するため正しく設定されていないと実行できない。だが他にも色々なパターンがあり、経験上これが発生するとトラブルシューティングに時間を食う。

Unixではコマンドは/usr/bin、共有ライブラリは/usr/libのようにインストール先がルールとして決められているが、Windowsにはそれがないのがそもそもの原因。そのためパスを使ってDLLを検索するが見つからないというのが典型的パターン。

ちなみに自分は長年使っているがまだDLL版がどうしても必要な状況に出会ったことは一度もない。だが数年に一回程度気まぐれでDLL版を試してみるとかなりの確率で何かしらトラブルになる。

まとめ: DLL版はインストールのトラブルリスクが大きく、効率のメリットは乏しい。

ただし以上はコマンドツールとして利用する場合の話。Windows用アプリ開発の内部処理のためにImageMagickのライブラリを利用する場合はDLL版という選択しかない。しかしかなり高度かつレアなケースなのでここでは割愛する。

(2) static版

一方のstaic版は単独で動くように作られた実行ファイルで、DLLで生じる外部依存性やモジュール検索の問題は発生しない。またC:\ImageMagic\convert.exe ...のように絶対パスを指定すればPathを設定しなくても実行できる。

DLL版と比較すると並列実行時に不利になる。static版の実行ファイル(例えばconvert.exe)は約16MBなので、作業時に数個のプロセスを同時実行する程度なら何も問題ない。だが仮に1000個同時だと起動だけで16GB近く消費する計算になる(おそらく実行困難)。

こういう場合にぴったりなのがDLL版だが、こんな状況はサーバー以外では考えにくい(大量アクセスが同時発生するケース)。しかしサーバ用にWindowsを使う人は少ない(今はもうMicrosoft関係者だけだと思う)。

個人で使用するのならDLL版をわざわざ使う理由は乏しい。並列実行もたかだか2-3個同時に実行する程度であれば効率はまず変わらない。比較しようとして実行時間を測定しても検出は困難だろう。

まとめ: static版の方がインストール時のトラブルが少ない。効率もDLL版とほぼ変わらない。

(3) portable版

しかし実はstatic版のインストーラにはPathの設定に関する微妙な問題がある(この後で解説)。またアンインストーラの出来も悪く、設定したPathを元に戻さない。

そのため自分は現在portable版(インストーラなしのstatic版)を使っている。Windows Binary Releaseの最後の2つでportable-Q16-x86が32bit用、portable-Q16-x64が64bit用。

インストールは手動で行う必要があるが、難しいことは何もない。

  • 適当なフォルダに解凍
  • 必要があれば自分でPathを設定する(これで終わり)

(自分もよく忘れるので備忘録) Windowsのパス設定は「コントロールパネル→システム→システムの詳細設定→環境変数(N)…」。

アンインストールも自力だが、インストール時作業の逆を行えばいい。

  • フォルダ丸ごと削除
  • もしPathを設定していたら削除

インストーラはよく知らない場所にファイルやレジストリを書き込むし、アンインストーラを実行しても元通りに掃除してくれないことが多い(ゴミが残る)。この方法だとそのような心配が全くないのが大きなメリット。

Path設定の注意

ここが一番重要。時間のない人はここだけでいいから読んでほしい。

Windows版ImageMagickには次のコマンドがある(portable版の場合)。インストーラを使った場合はもう一つunins000.exeというような名前のコマンド(アンインストーラ)も生成される。

compare.exe    convert.exe  hp2xx.exe      magick.exe   stream.exe
composite.exe  dcraw.exe    identify.exe   mogrify.exe
conjure.exe    ffmpeg.exe   IMDisplay.exe  montage.exe

これを見て分かる通りcompare, convert, streamなど他と衝突しそうな名前が多い。特にImageMagickで最も使用頻度が高いconvert.exeは同名のWindowsシステムコマンドと実際に衝突する。

Unix系ではこの問題はまず発生しない。ImageMagickはUnixでは昔からの定番ツールなので現行のUnixコマンドはImageMagickのコマンド名を避けて作られている。

Windowsのconvert.exeはFAT(旧式)→NTFS(現行)のファイルシステム変換。昔のコマンドで今ではほとんど使うことはない(あるとしたらFAT時代の古いHDDを後付けしてNTFSに変換する場合くらい)。

一方ImageMagickのconvert.exeは最もよく使うコマンドなので、ImageMagickのインストーラはシステム環境変数のPath(システムパス)の先頭に設定している(自分を最優先にする)。これだとWindowsのconvert.exeは動かなくなるが実害はない。

ただしImageMagickはWindowsではあまり有名とは言えないため、Windowsアプリの多くはImageMagickに対する配慮はしていない。そのため特にcompare.exeやconvert.exeというような名前はよく衝突する。

もう一つ補足。ビューアの本来(Unix系)のコマンド名はdisplay。しかしWindowsではこの名前だとよく衝突するためIMDisplay.exeに変更している。

そのためすでに多くのアプリをインストールしているWindows環境でImageMagickのパスを最優先に設定すると別の何かが動かなくなる可能性がある。実際に問題が発生した場合はImageMagickをユーザーパスの末尾(優先度最低)に移動すれば復旧できる。

今までインストーラを使い何回かこれを経験した(記憶があいまいだが少なくとも2-3回は…)。

しかしImageMagickの優先度を最低にすると今度はconvert.exeがWindowsコマンドに隠れてしまう。また衝突の原因になっていたImageMagickコマンドも同様に先にインストールしている同名コマンドの裏に隠れる。

そういう場合は絶対パスを指定すれば実行できるが、毎回それでは使いにくいので補助用のバッチファイルを作るとよい(C\ImageMagickの部分は自分がインストールした絶対パスに適宜変更すること)。

imconvert.bat
1
C:\ImageMagick\convert.exe %1 %2 %3 %4 %5 %6 %7 %8

これをパスが通るディレクトリ(例えばImageMagickと同じ場所)に置けばよい。最後にもうひとつ注意、他と衝突しないファイル名にするのが一番のポイント(imconvert.bat, IMConvert.bat, im-convert.batなど)。

まとめ: Windowsではコマンド名がよく衝突する。パス設定に注意してportable版をインストールするのがベスト。インストーラ任せにせず自分で調べて設定した方が安全。

ブログのテスト

現在ブログの立ち上げ作業中。以下はテスト。ソースコードは次を参考に記述し、ここで表示を確認する。

https://github.com/cgmartin/hexo-theme-bootstrap-blog/blame/site/source/_posts/tag-plugins.md

リスト

  • リスト(ul)
    • ネスト
      • ネスト
        • ネスト
          • ネスト
  1. リスト(ol)
  2. リスト(ol)
    1. ネスト
    2. ネスト
      1. ネスト
      2. ネスト

引用文

code block

Code Block
Code Block

Fenced code block

1
2
line 2
line 3

キャプション付き

imconvert.sh
1
2
#!/bin/sh
C:/usr/ImageMagick/convert $*

Gist

table

TH TH
TD TD
TD TD

画像