ちょいちょい「環境設定」→「セキュリティとプライバシー」→「アクセシビリティ」を開かせたいケースがあるが、openURL とかで Security.prefPane を開くだけだと「どこやねん」となりがちなので、アクセシビリティを設定するところまで一気に移動したくなる。

ScriptingBridge を使えばできるのだが、Objective-C でやる場合でもメソッド定義のヘッダファイルを生成して使うみたいな感じになっており、Swift からちょっと気軽に使おうと思うとダルくなってしまう。

フル機能を使うなら一度 Objective-C でラッパー書くのが正当だと思うが、一行も Objective-C を書きたくない気分のときは、プロトコルとエクステンションで必要なメソッドを強制的に定義してコンパイラを騙せば乘りきることができるようだ。

import Cocoa
import ScriptingBridge

// 元にないやつは optional にしないと extension でエラーになる
@objc protocol SBSystemPreferencesApplication {
    optional var panes: SBElementArray {get}
    func activate()
}


@objc protocol SBSystemPreferencesPane {
    optional var anchors: SBElementArray {get}
    optional var id: NSString {get}
    
}

@objc protocol SBSystemPreferencesAnchor {
    optional var name: NSString {get}
    optional func reveal() -> id_t
}

// protocol 定義を無理矢理使えるようにする
extension SBApplication : SBSystemPreferencesApplication {}
extension SBObject : SBSystemPreferencesPane, SBSystemPreferencesAnchor {}

struct Accessibility {
    static func checkAccessibilityEnabled(app: NSApplicationDelegate) {
        if AXIsProcessTrusted() != 1 {
            let alert = NSAlert()
            alert.messageText = "Require accessibility setting"
            alert.alertStyle = NSAlertStyle.CriticalAlertStyle
            alert.addButtonWithTitle("Open System Preference")
            alert.addButtonWithTitle("Quit")
            if alert.runModal() == 1000 {
                openSecurityPane()
                NSApplication.sharedApplication().terminate(app)
            } else {
                NSApplication.sharedApplication().terminate(app)
            }
        }
    }
    
    static func openSecurityPane() {
        // openURL 使うのが最も簡単だが、アクセシビリティの項目まで選択された状態で開くことができない
        // NSWorkspace.sharedWorkspace().openURL( NSURL.fileURLWithPath("/System/Library/PreferencePanes/Security.prefPane")! )
        
        // ScriptingBridge を使い、表示したいところまで自動で移動させる
        // open System Preference -> Security and Privacy -> Accessibility
        let prefs = SBApplication.applicationWithBundleIdentifier("com.apple.systempreferences")! as SBSystemPreferencesApplication
        prefs.activate()
        for pane_ in prefs.panes! {
            let pane = pane_ as SBSystemPreferencesPane
            if pane.id == "com.apple.preference.security" {
                for anchor_ in pane.anchors! {
                    let anchor = anchor_ as SBSystemPreferencesAnchor
                    if anchor.name == "Privacy_Accessibility" {
                        println(pane, anchor)
                        anchor.reveal!()
                        break
                    }
                }
                break
            }
        }
    }
}
  1. トップ
  2. tech
  3. Swift で Mac の ScriptingBridge を無理矢理つかう

フルサイズ5060万画素

ところで以前レンズの理論上の解像度限界というのを求めたことがあった。これは、絞りを絞るほど回折によってボケてしまうという物理的な絶対的制約からくる解像度限界だった。

フルサイズセンサ (36x24mm) で 8688x5792pixel だとすると、画素サイズは 約 0.00414mm なので、F7 波長500nm でのレイリー限界 0.00427mm よりも細かくなる。

高画素数になるということは、より回折にシビアなセンサーになるということになる。ある程度よりも (この機種の場合 F7 程度) 絞ってしまえば、いくら高画素でも解像度はあがらないので意味がない。

実際のところでは、回折ボケよりも手ぶれのほうが厳しい場合が多いように思われるが、とにかく回折による解像度の限界を感じやすくなる。

ローパスレス

高画素化することによって空間的なサンプリング周波数があがり、ナイキスト周波数(=サンプリング周波数の半分)も上げることができる。十分に高いナイキスト周波数 (具体的にはレンズの性能よりもセンサーが勝る=レンズがローパスフィルタとして働く) の場合、センサー直前のローパスフィルタを省くことで画質の向上をはかることができる (ローパスフィルタでは、ナイキスト周波数ぴったりで遮断するということはできないので、いくらか解像度が犠牲になる)。

画素サイズを(アスペクト比間違いにより)間違えていたので、いろいろ修正しました。

  1. トップ
  2. tech
  3. EOS 5DS というフルサイズ5060万画素のカメラが発表された。

Picasa での色化け

先にまとめ

  • sRGB で出力すること
  • Google+ の「フォト」の設定で「自動補正」を「オフ」にすること

経緯

Picasa にアップロードすると、めちゃくちゃ色が変わるというのは認識していたが、面倒なので見ないふりをしていた。やる気を出してちゃんと調べた。

sRGB プロファイル強制適用

Picasa はアップロード時に問答無用で sRGB IEC61966-2.1 black scaled が適用される。マッチングされないで強制適用なようなので、AdobeRGB な画像をアップロードすると明かに彩度が落ちる。

sRGB でアップロードしても色が変わる

しかし、sRGB な画像をアップロードしても、色化けが起こる。OS に入っている sRGB と sRGB black scaled の違いかと思い (同じはずだけど)

http://www.color.org/srgbprofiles.xalter ここから .icc をダウンロードして

sudo cp ~/Downloads/sRGB_IEC61966-2-1_black_scaled.icc  /Library/ColorSync/Profiles/   
sudo chmod +r /Library/ColorSync/Profiles/sRGB_IEC61966-2-1_black_scaled.icc 

(なぜか read できない permission になってて混乱)

として、このプロファイルを使って書きだしてアップロードしてみたが、やはりダメ。Picasa にアップロードすると少し明くなってしまう。

いろいろ試行錯誤していたが、Google+ 側の「フォト」を開き、該当画像の「自動補正」を「オフ」にしたら色が正しくなった。Picasa 側ではこの設定が見えないので気付かなかった……

今後ハマらないように、Google+ 側の設定で自動補正をオフにした。念のため sRGB black scaled はそのまま適用するようにする。

  1. トップ
  2. tech
  3. Picasa にあげるときのカラープロファイル

いろいろ確認していたところ、Chrome で Preview.app と色が違うことに気付いた。sRGB モニタで見ていると同じように見えるが、AdobeRGB 色域のモニタにウィンドウを移動するとかなり彩度が上がる。謎……

Google Chrome は ICC v4 には対応してないが、sRGB_IEC61966-2-1_black_scaled.icc は v2 なので、それが原因ではない。

結局、結論は「Google Chrome はプライマリディスプレイのプロファイルしか認識しない」だった。

マルチモニタ環境で、モニタごと別々の Chrome のウィンドウを置いておくと、プライマリモニタ以外は全て色がずれるので気をつけましょうという感じだった。

なお Safari だけがマルチモニタでのプロファイル適用に対応しているみたいだった。

  1. トップ
  2. tech
  3. Google Chrome (Mac版) の色化け

USB 3.0 の伝送路における基本波が 2.5GHz なため、ISM バンドの 2.45GHz 帯 (2.4GHz〜2.5GHz)で電波障害が起きやすいという話。(波長の半分で1bit転送するのでデータレート的には5Gbps)

一応 USB 3.0 はEMI 対策として、スペクトラム拡散クロック (広い範囲にクロックを拡散することでピークを回避する) や、スプレッド処理 (信号経路には常にランダムのビットが流れるようにしてピークを防ぐ) をしているが、あまりに発生源とアンテナが近過ぎるとやはりダメらしい。

うちで使っているワイヤレスマウスも、USB 3.0 ハブに繋ぐとかなり挙動がおかしくてイライラする感じになる。

今後

USB 3.1 になると基本波が倍の 5GHz になるので、この問題は解決するかもしれない。(5.8GHz帯のISMバンドとはある程度離れてるし)

備考

USB 3.0 は 2.5GHz 基本波、5Gbps の物理ビットレートだが、8b/10b エンコードするので、実行ビットレートは 4Gbps 程度

USB 3.1 は 5GHz 基本波、10Gbps の物理ビットレート、128b132b エンコードなので、実行ビットレートは 9.7Gbps 程度

USB 3.0 では、USB 2.0 と違い、完全なスリープ状態でなければ常に信号が流れているらしい。


ref.

  1. トップ
  2. tech
  3. USB 3.0 の 2.4GHz 帯干渉 (無線マウスなどへの電波障害)