Naganoya画像のすべてのピクセルが白であることをチェックするAppleScriptです。10.12上で作成した「空白画像検出v3」は一般的に処理時間のかかる空白画像の検出(ヒストグラム計算してチェックする?)が高速に処理できます(GPUImageでヒストグラム計算を行うより2倍ぐらい高速)。Photoshopが必要になるといった事態は避けられます。10.14.6上でこのルーチンを再度試してみたところ、思ったとおりに空白検出(数百万ピクセルの画像でも1つだけ黒であればfalseを返す)してくれません。書き方を変えていますが、単体で通常のAppleScript(Cocoa不使用)にコンテクストメニューから突っ込むモジュールとして運用するためです。copyしてくれない?参照ではなくすべてのデータをコピーするコマンドとして、copyコマンドはとても重宝しています。「パラメータの代入の方向が違う偏屈なコマンド」ではなく、明示的にデータ内容をコピーするためのコマンドと認識しています。10.14.6上で本ルーチンを試してみたところ、どうも参照をコピーしている気配がします。AppleScriptのオブジェクト(配列とか)をcopyコマンドでコピーすると、参照ではなくデータが複製されていることを確認しました。Cocoaオブジェクトのcopyも同様かどうかは、ちょっとそうじゃないんじゃないかというところです。|copy|()Cocoaの世界のオブジェクトのコピーはこんな感じ(↑)でできたので、今後はこちらを採用することにします。1×1のNSImageに色を塗るとデータサイズが増えるビットマップ画像の状態であるNSBitmapImageRepになっていれば、1×1画像のサイズは同じことが期待されます。10.12上ではそのように扱えていました。10.14上で1×1ドットのNSImageに対して色を塗って、NSBitmapImageRepを取得すると、塗らない状態のNSImageよりもデータ(NSData)サイズが大きくなることがわかりました。▲1×1のPNG画像をビットマップ化したデータ。10.15では大幅にデータ量が減る)。10.15.2)さすがに匙を投げかけましたが、比較元のデータに透明の色(clearColor())を塗る=画像的に意味はないが、同じ処理を通すことでデータサイズを同程度にするという処理を行うことで、いい感じに空白検出できるようになりました。NaganoyaWebコンテンツ(HTML)の並列ダウンロードを行うAppleScriptです。Webコンテンツからデータを抽出する際に、あらかじめ一括でHTMLを並列ダウンロードしておいて、ダウンロードずみのデータを一括処理すると処理時間を大幅に短縮できます。「戦場の絆」Wikiから機体データの表をすべて取得するのに、順次HTMLを取得して抽出していた場合には3〜4分程度かかっていたものを、並列ダウンロードしたのちにデータ処理するように変更すれば、これが十数秒程度にまで高速化できます。既存のプログラムを修正してHTMLのダウンロード用に仕立ててみました。並列キュー(未処理タスク数)へのアクセスはAppleScriptからはできなかった(実行すると結果が返ってこなかった)のですが、そこに手をつけずに並列処理の完了状態を検出しています。ダウンロードが完了したデータはlist(配列)に入るので、リクエスト数と完了リクエスト数をループ内でチェックし、完了アイテム数がリクエスト数と同じになれば終了、条件を満たさない場合でも指定のタイムアウト時間を超えたらエラー終了という処理を行なっています。Debugger上では実行できないことです(結果が返ってきません)。AppleScriptアプレットに書き出して実行してみたところ、結果が返ってきません。10.12.6、10.13.6、10.14.6で同様)。Appのプロジェクト内で実行することはできました。このように、ランタイム環境に実行状況が左右される点にご注意ください。したマイナス面を補ってあまりあるほどダウンロードは高速です。90ファイル強のダウンロードを数秒で完了(マシン、ネットワーク速度、ダウンロード先サーバーの負荷状況、キャッシュ状態などに左右される、参考値です)するため、ダウンロード後に各HTMLからのデータ抽出も高速に行えます。Naganoya指定の画像のドットがすべて白色かをチェックする(=画像の空白判定)AppleScriptです。画像の空白判定処理は自分的にはひじょうに重要な処理であり、画像をグレースケール化しておいて、(方法1)Photoshopを用いて明度ヒストグラムを取得し、明度=255のデータだけが存在することを確認(方法2)GPUImage.frameworkを用いて明度ヒストグラムを取得し、明度=255のデータだけが存在することを確認といった方法で確認を行なっていました。Storeに出せるため)、AppleScript+Frameworkぐらいで高速処理できることにはものすごく価値があります。そんな中、GPUImageは急速に2度の方向転換を行い、AppleScriptからは付き合いにくいフレームワークに変化しました。10.14で行われた「OpenGL/OpenCLの非推奨化」という方針転換(わかっていたことですが)を受け、Metalを活用するように書き換えられたGPUImage3へと姿を変えました。オリジナルから見るとほぼ別物です。3はまだまだ機能不足なうえにAppleScriptから呼べない状態。ヒストグラムの計算フィルタも搭載されていません。Objective-Cで書かれ、中国のスマホ開発者が写真加工するのに活用しまくった、人民に愛されまくったGPUImageの姿はもう見られないのでしょうか。GPUImageを用いた他のフィルタ処理はCIFilterで代替できるのであまり問題にはなりませんが、この空白画像検出処理だけはなんとしても代替手段を見つける必要に迫られました。応用例が多すぎるからです。そこで思いついたのが、「チェック対象の画像と同サイズの白い画像を作って、データ内容が同じかどうか調べる」というシンプルな方法(最初から思いついてほしい>自分)。これならCPUパワーもそれほど必要とせず、GPUの力を絞り出す必要もありません(あたりまえ)。書いてみたものの、今度はどうも「白い色」の値が合わず、頭をひねりまくりました。▲1×1ドット画像を新規作成して白く塗りつぶして比較。Photoshopで作成してファイルから読み込んだ画像とDataが同じにならないカラープロファイルが合わないために「白い色」を指定してもイコールにならないようだったので、オリジナル画像をコピーしてそれ自体を白く塗りつぶして空白検出の比較対象としてみました。これで空白検出が無事できるようになりました。Photoshop版、GPUImage版のAppleScriptと比較してみたところ、1980×1200ピクセルぐらいの画像だとGPUImage版の倍ぐらい高速、8K(7680×4320)ぐらいになるとPhotoshopに負けるといったところです。2018、GPUImage、本Scriptで各種サイズの画像の空白検出を実行(単位:秒)処理内容がシンプルなだけに小さい画像の処理は得意で、大きな画像は不向きといえるかもしれません。2.66GHzメモリ8GBのマシンであり、より搭載メモリ量の多いマシンで実行すると挙動が変わってくるかもしれません。補足までに、GPUImageの明度ヒストグラム検出は、結果を数値の配列ではなく、1×256ドットの「画像」として返してくる変態仕様なので、結果を判定するために1×256ピクセルの画像をループでチェックする必要があります。この仕様が余計なオーバーヘッドを生んでいる(つまり、GPUで処理しているから爆速、という世間の期待値を大幅に下回る処理内容になっている)可能性は否定できません。PhosothopなしでPhotoshopと同様のヒストグラム処理が行えるという「手軽さ」がいいと思ってGPUImageを使い出したので、速度をベンチマークしてみると「こんなもんだろ」という印象です。Viewを表示して位置座標の選択を行うAppleScriptです。Viewを使用するためには、インターネット接続が必要です。location」とかいうコマンドになるでしょうか。本当は地図.appのように地図中でクリックした場所にピンを打って選択箇所を明示するようなものを考えていたのですが、実際にASだけで作ろうとすると難しいものがありそうで。した「ざっくり場所を選ぶ」ダイアログのほか、複数の地点をピンで表示し、そのうちのどれかを地図上で選択するといったコマンドがあると使いでがありそうです。Naganoyaスクリプトエディタの最前面のドキュメントを解釈して、CocoaのClass名とEnumを抽出してpropertyに展開して、新規書類に展開するAppleScriptです。いわゆる「AppleScriptの内容を解析して書き換える」AppleScriptです。Classのチェックのために、実際にNSClassFromStringでオブジェクトを作れるかどうかチェックしています。Enumについては、ヘッダーファイルを検索してチェックを行っています。そのため、本AppleScriptは実行環境にXcodeがインストールされていないとEnumチェックが行えません。前バージョンではXcodeのアプリケーションバンドル以下に存在しているヘッダーファイルのパスを計算するときにXcodeが起動されていましたが、本バージョンではXcodeが起動しないように修正しました。propertyを展開するときに、プロポーショナルフォントで画面描画した際の幅を実際に計算して、文字の描画幅のピクセル数順にソートしています。本AppleScriptはEnumの確認のために全ヘッダーファイルを走査しているため、この部分で少々処理時間がかかります。ClassとEnumの確認をキャッシュするようにして、二度目以降は同じ文字列の問い合わせを行わないようにしたいところです。me–置換してはいけないリスト。encoding系はenumの桁数が足りなくてpropertyに代入できない。