指定のデジカメ画像のExif情報から指定のプロパティを取得するAppleScriptです。

デジカメ画像のExif情報を取得する場合には、Image Events経由でアクセスすることになりますが……実際に使ってみると、クラッシュしまくるImage Events。AppleScriptの実行をApple純正のアプリケーションが阻害するというあり得ない現象が頻発。

そこで、Image Eventsをアテにしないで、sipsコマンドをAppleScriptから呼び出すことにしてみました。Image Eventsはsipsを呼び出しているAS用インタフェース・アプリケーションですが、この調子ではAppleScriptによる並列処理などを考えるとsipsをダイレクトに呼び出した方がご利益が大きそうです。

指定できるプロパティ値については、Terminal上でsipsコマンドのhelpを見て確認してください。

Special property keys:
all binary data
allxml binary data

Image property keys:
dpiHeight float
dpiWidth float
pixelHeight integer (read-only)
pixelWidth integer (read-only)
typeIdentifier string (read-only)
format string jpeg | tiff | png | gif | jp2 | pict | bmp | qtif | psd | sgi | tga
formatOptions string default | [low|normal|high|best| ] | [lzw|packbits]
space string (read-only)
samplesPerPixel integer (read-only)
bitsPerSample integer (read-only)
creation string (read-only)
make string
model string
software string (read-only)
description string
copyright string
artist string
profile binary data
hasAlpha boolean (read-only)

Profile property keys:
description utf8 string
size integer (read-only)
cmm string
version string
class string (read-only)
space string (read-only)
pcs string (read-only)
creation string
platform string
quality string normal | draft | best
deviceManufacturer string
deviceModel integer
deviceAttributes0 integer
deviceAttributes1 integer
renderingIntent string perceptual | relative | saturation | absolute
creator string
copyright string
md5 string (read-only)

AppleScriptを並列処理するAppleScriptの改良型、v3の実行中のムービーです。

先週末には出来上がっていたのですが、挙動がおかしい箇所があったので地道にデバッグしていました。

並列処理デモv3（5.7MB）

AppleScriptによる並列処理 v2を実際に使ってみての評価です。

■前提となる話

たまたま、大量かつそこそこの容量のテキストファイルの処理をする必要があったので、マシンのCPU性能を生かすために並列処理を行わせてみた。

通常のデスクトップ用アプリケーションを複数同時起動できるわけではないし、複数のAppleScriptアプレットから同時に１つのアプリケーションにアクセスした場合にきちんと排他処理してくれたりするかどうかは不明（昔は、FileMaker Proがbegin transaction〜end transactionの構文をサポートしていたが、他で見かけたことがない）。そんなに高度なことを期待してもダメ。

InDesignとかIllustratorの処理を１台で並列実行とかいう話は無理。ただし、もしもMac OS X10.7になって複数ユーザーが同時ログインして別々のGUI環境を同時に実行できるとかいう環境になってくると、１つのユーザー環境から他のユーザー環境上のアプリケーションをコントロールできる可能性は……ないこともない。

AppleScriptのプログラムを動的に実行バイナリに変換して、同じ仕事を手分けして処理するという程度の話がこの話のゴール地点。テキストファイルの大量処理という話ならけっこう使える。

ひととおり使えるレベルのプログラムに育ったら、１台で複数の処理をやるのと同様に、複数のマシンで分散処理を行うプログラムを作ってみるとよさそう。安くてそこそこの性能のマシンを複数台集めるとか、オフィスや学校にあるMacを夜間に動かして仕事を分散処理させるのはけっこうよさそう。

■評価

処理対象のファイル一覧をスレッド数で分割して、まとめて渡すというやり方はよくない。処理対象のファイルにはサイズにバラツキがあるので、それぞれのスレッドの処理時間がバラバラ。「数」で割って仕事を割り振るのは、無駄が多いことが分かった。

たとえば、４スレッドで並列処理を行っても、割り当て分を終わらせたスレッドは早々にプログラムを終了してしまう。処理が早く終わったスレッドは、処理が終わっていないスレッドの未処理分を処理すべきなのに、それができていない。最後のほうでCPUの利用効率が落ちてしまう。

また、途中でトラブルに遭遇して停止した場合、１スレッド文の処理がいきなりすべて無駄になってしまうのは時間の無駄すぎます。

そのため、１ファイルずつスレッド側に渡して処理するように変更すべきだと思われました。……というか、もう出来上がってテスト中です。

読者の方からメールでお寄せいただいたプログラムの中に入っていて、「え？　なにこれ？！」と驚いてしまったのが、このopenハンドラでファイルパス以外のものを渡すというやり方。

AppleScript Studioのアプリケーションに外部のAppleScriptから命令を渡すような場合に、コマンド入りのファイルを作成して、openハンドラ経由でそのファイルをAppleScript Studioアプリ側にオープンさせ、ファイルを経由してコントロール。

AppleScript Studioアプリケーションの内部ハンドラを外部からコントロールすることは事実上無理で、さまざまな迂回のための手段が考え出されてきましたが、ファイル経由でコマンド送信するのはなかなかいいやり方でした。……そう、処理スピードを考えなければ。

ファイルI/Oが毎回発生するので、スピードはいまひとつです。ただ、信頼性という意味では並列処理で連続して発生させても問題がなかったので、大丈夫だと考えています。

そのうえ、openハンドラをファイルI/Oを経由せずに呼び出せるのであれば、それに越したことはありません。

そんなところに飛び込んできた、openハンドラに渡せるのがファイルパスだけではないという情報。

さっそく、ためしてみました。

たしかに、openハンドラにファイルパス以外のものを渡しても大丈夫でした。ただ、openハンドラの受信パラメータに複数指定してしまうと、肝腎のファイルを（ドラッグ＆ドロップで）渡したときにパラメータエラーになってしまいます。

そんなわけで、受信パラメータは１つに変更。その内容を判断して、処理するようにいろいろ試してみました。

AppleScriptで並列処理を行うサンプルです。メイン（GUI）側はAppleScript Studio（Xcode 3.1.4 on Mac OS X 10.5）、サブ側は通常のAppleScriptで記述しています。

子プログラムからメインプログラム（画面つきのプログラム）に向けて、ファイルシステム経由でイベントを６プロセス並列で送信。子プログラム側では1〜1000まで順次カウントアップし、すべての子プログラムがカウントアップを終了したら、その時間を表示するようになっています。

→　テストプログラムをダウンロードする

使用方法は……アーカイブを展開したら、「docOpen1」アプリケーションを起動して、「START」ボタンを押すだけです。

結果は、手元のマシンでは……

　　CoreDuo 2.0GHzのMacBook Pro：95〜100秒
　　Core2Duo 2.4GHzのMacBook Pro：90〜95秒
　　Core i7 2.66GHzのMacBook Pro：55〜60秒

といったところです（Mac OS X 10.6.3上で計測）。Core i7のMacBook Proでは６プロセス並行して走らせてもまだCPUに余力があり、HyperThreadingで仮想的に4コアのCPUとして振る舞えることが、こうしたタイプのプログラムの実行に有利に働いているようです。Core 2 Duo 2.4GHzの環境ではCPUの全能力を必要としていたAppleScriptのプログラムが、余裕で動いてしまう様にはほれぼれします＞Core i7

▲MacBook Pro Core i7 2.66GHzで本サンプルが稼働中の負荷

本サンプルの本当の目的は、並列処理時の子プログラムからメインプログラムへの状況・結果通知のテストでした。それぞれの子プログラムが並列でてんでバラバラにメッセージを投げた場合でも、イベントを取りこぼさずに正しく処理できることを確認できました。

パラメータをファイルに書き出して、そのファイルをメインプログラムでオープンさせるようにイベントを投げるというシンプルな処理ですが、並列処理時や長期間に渡る処理を行わせた場合の時間計測など、さまざまな用途が考えられます。実際に、ぜんぜん速度を要求されない「アドレスブック.app（のプラグインAppleScript）からAppleScript Studioアプリへのデータ転送」に、このファイルシステム経由のイベント送信を使って実装したことがあります。

本当は、こんなに短い間隔で連続的に子プログラム→メインプログラムの方向でイベントを送るようなシーンは考えていませんでした。かなりまとまった処理を子プログラムに行わせて、子プログラム側の処理終了後にその実行結果なりエラー内容なりを親プログラム側に伝えられればよい、というスタンスです。

さらに……本来であれば子プログラムの生成については、ダイナミックにその数を増減させられるのですが、GUIのプログラムに経過を表示する関係で、本サンプルでは６プロセス固定で行っています。

とても高価なため自分の手元にはないのですが、もっとCPUコア数の多いMacProなどで処理を行った場合の速度などが分かると有意義でしょう。速いマシンでの実行結果（秒数）については、コメント欄にて教えていただけると助かります。

Snow LeopardのAppleScriptについてのリリースノートのうち、変更点に関するものが別途アップされていました（AppleScript Users MLより）。

Mac Dev Center: AppleScript Release Notes: 10.6 Changes

(more…)

AppleScriptによる並列処理実験に用いたアプレットです。

とくに、手の込んだところはひとつもないのですが、このAppleScriptを保存する際に、「アプリケーションバンドル」形式で保存し、さらにオプションで「実行後、自動的に終了しない」チェックボックスをオンにしておく必要があります。

sub.zip

AppleScriptによる並列処理実験Scriptのv2です。v1では、複数のアプレットがDockに表示され……16プロセス起動すると同じアイコンが16個並んでしまいましたが、このv2ではInfo.plistのLSUIElementエントリを作成して、Dockに表示しないようにします。

あとは、アプレットを複製する場所を~/Library/Caches/TemporaryItemsあたりにでもして、終了後の実行ファイルの削除あたりを行うようにライブラリを整理すればいい感じでしょうか。

AppleScriptによる並列処理の実験Scriptです。あらかじめ、他にバンドル形式のアプレットをAppleScriptで作成しておき……そのアプレットをコピーしつつバンドル内のInfo.plistの中のエントリを書き換えて別名のアプレットに仕立て上げ、別々のプロセスとして扱えるようにします。

最近のMacは最低でもデュアルコア、最高で16コアというマルチコア化まっしぐらの状況なので、時間のかかる処理については並列処理を考えたほうが得策です。AppleScript自体に並列処理のための機能は……複数のアプレット間でプロセス間通信を行ったりプロパティを参照し合ったりというぐらい。いまひとつマルチコア時代に適した便利な機能を持っていませんが、なければ作るまでのこと。

そこで、アプレットのファイルをコピーして必要なプロセス分用意し、さらにそのバンドル内のInfo.plistを書き換えて、別プロセスとして扱えるように細工します。

これで、プロセス名（アプリケーション名）を個別に指定してハンドラを呼び出したり、プロパティの参照/書き換えを行ったりできるので、１つの時間のかかる処理（大量のJPEG画像ファイルの破損チェックなど）を複数プロセスの生成・起動により時間短縮できるものと思われます。

複数のアプレットから特定のアプリケーション（QuickTime Playerなど）に同時アクセスするのは得策ではないため、それらのリクエストを受け付けるキューイング用のアプレットを別途用意するなどの対策は必要になってくることでしょう。

私の手元にはDual Coreのマシンしかないので、どこからか実験用に16コアのMac Proでも貸していただければ、さまざまな検証も行えるのですが（＾ー＾；。