Image Stabilization

E-M5m3 の手ぶれ補正をもう少し試したい。
Vlog の人達がよくやっているような実験は正直参考にならない。
やっぱり野鳥で試さないと、でも野鳥が実験に都合よくなんて…

いや方法はある、名古屋城の堀だ。
冬の間は必ず鴨類がのんびり過ごしている、よし行ってくる。

1

ハシビロガモ、フルサイズ換算 800mm で。
うおぉ OM SYSTEM やるやん、被写体ブレはしたけど。

2

オナガガモ、フルサイズ換算 200mm で。
まさかのバキバキ、パナ同志でないととか考えなくてもよかった。

3

キンクロハジロ、物凄く遠い所にしかいなかった。
流石に離れていると綺麗には撮れないな、LUMIX でも同じだし。

なんだよ Dual.I.S とか気にする必要は無かったんや。
本体の手ブレ補正だけでイケる、体感では Dual.I.S と同等。
ただ常に補正している LUMIX 本体のほうが被写体は見つけやすい。

ついでに、オリンパスブルーという気になるワードがある。
LUMIX G99 と同じ場所で空を撮ったらどんな感じになるのかな。
共にいつもの F6.3 で撮影しカメラ内で LAW 現像したものです。

4

思っていたよりも違うな、葉っぱの色は同じ感じなのに。
てか LUMIX のほうが綺麗に見えるんですけど。
いやまあ Lightroom でどうにでもできるんですけどね。

OM-D E-M5 Mark III

OM-D E-M5 Mark III を LUMIX G99 のサブカメラ用途で買いました。
ボディのみ中古 B 級品で 66000 円なり、を見つけたのでってことで。
これなら買っても充分お得かなって。

しかし一昨年 Nikon 去年 LUMIX 今年 OM SYSTEM か。
来年は多分 FUJIFILM だな、ウソです。

em5m3

ネオレトロなデザインは好き、小さくて軽いのもいい。
よーくみるとプラスチッキーです、いやパッと見の良さと軽さのバランスですよ。
見た目どおりの軽さって重要、デジイチはバイク同様に重さでビビる人が多いと思うし。
ただ 14-140 レンズを付けるとなんか色々とチグハグでかっこわるい。
奥のパナライカ 100-400 がウルトラ超カッケーのは気にしないで下さい。

おぉズームレンズを付けて動かすと焦点距離がモニター右上に出る。
いや LUMIX では何も出ないんですよ、焦点距離の決め打ちは勘だけ。
LUMIX で一番気にいらない所だったのでコレは嬉しい。

さて、まずはパナライカ 100-400 を装着して野鳥撮影。
って花や風景用途のサブカメラとして買ったのじゃないのか?なんだけど。
筆者はこのレンズで野鳥ばかりなのでこのレンズでないと何も比較ができない。

m5mozu

うんブレてない、このレンズは OM-D でも問題なく使える。
曇っていて遠いのをトリミングという最悪条件でコレなら、しか用意できなかった。
こんな条件でもがんばって探したんだから、ね。
O.I.S.スイッチはオフにしようと見かけるけど普通に無視されるだけ。
MF 切り替えスイッチは動作する、G99 本体にもあるので使ったこと無いけど。

ところで手ぶれ補正は OM-D と LUMIX で全然違ってたのね。
LUMIX は微妙なブレは常に補正、OM-D はシャッターボタン半押しで動作する。
最初「全然ダメじゃん!」と思った、半押しするとビタ止まりしてまたビビる。

ただ右手が辛い、G99 のデカいグリップは意味があったことを新ためて感じる。
E-M1 なら問題ないと断言、手持ちの野鳥撮影で最重要なのはグリップのデカさ。
ココが小さくてダメだと他に長所があっても全部帳消し。

そんなことよりアイセンサーが過敏すぎて辛い。
G99 は感度調節できイイ感じにできたけどコイツは設定が無い。
頭にきて手動切り替えにしたら今度はコンパネが出ない、どうしろと。

G99 にある一発でマニュアルフォーカスに変更するレバーやボタンが無い。
と思ったけど Fn レバーをそれに割り付けすれば同様の操作ができる。
コレはなるほどって思った、ある程度経験を積んだ人向きってことかな。

ISO 感度の上限設定はコイツも 800 に。
ギア→E1→ISO オート設定→上限/基準値設定、やっと見つけた
メニュー解り辛い、なんでこんなに深いんだよパナを見習え。
前のオーナーは iso 感度を 200 に固定していた…
気持ちは解るけど、動きモノは一切撮影しなかったのだろうか。

m5book

色々感じたけど一番驚いたのはコレだったりして。
読みすぎて色あせた G99 取説の三倍くらいコイツの取説は厚いぞ!
力をいれる所が違うんじゃないのかって突っ込みたい。

今日はもう晴れそうにないのでまた次回。

aki

今日の五条川。
は少し趣向を変えて紅葉写真の練習。

1

千本桜の中にヒョッコリ楓が混ざっている場所がいくつかある。
五条川を背景に、背景の無いイラストとかってつまんないよね。

2

毎度の玉ボケを作ったけどちょっと白飛びした。
しかし Youtube にある写真講座とかを見ると背景が何なのか全然解らないほどボカした写真ばかりでなんだかなって。

3

銀杏の木は五条川には無いけど岩倉で合流する矢戸川にある。
いや、名駅の桜通りに山ほどあるのは知っているけど。

4

ところで、カメラを縦向きで撮影した場合だけど。
RAW を Lightroom で現像すると普通に縦写真になるんだね。
LUMIX 内で現像するとスマホ写真と同じ回転情報付きの横写真なんですけど。
以下の PyGObject コードで確認した。

#!/usr/bin/env python3

import gi
gi.require_version('Gtk', '4.0')
from gi.repository import Gtk, Gio

LIGHTROOM = 'ichou.jpg'
LUMIX = 'sagi.jpg'

class TestWindow(Gtk.ApplicationWindow):
    def __init__(self, app, fn):
        Gtk.ApplicationWindow.__init__(self, application=app, title=fn)
        #
        f = Gio.file_new_for_path(fn)
        pic = Gtk.Picture(file=f)
        self.set_child(pic)
        self.set_default_size(300, 300)
        self.present()

class TestApplication(Gtk.Application):
    def __init__(self):
        Gtk.Application.__init__(self, application_id='org.suzuki.address')

    def do_activate(self):
        TestWindow(self, LIGHTROOM)
        TestWindow(self, LUMIX)

app = TestApplication()
app.run()

5

メーカーによって違うかもしてないけど。
Lightroom を使っていれば回転情報のアレコレは心配しなくていい。

さて、見ての通りバリアングル液晶を駆使して撮っています。
以前はバリアングルなんて不要と思っていたのになぁ。
あると使うもんだ、ミラーレス万歳。
固定液晶てかレフ機な D3400 はもう使うこと無いかも、

しかしやはりサブカメラが欲しい。
今日もレンズを超望遠に交換している間に野鳥を見失ったぜ。。。。。
超望遠付けっぱと通常用の二台体制ならば、ってマジ思う。
マイクロフォーサーズでバリアングルが絶対条件で。

やはり G9 pro を野鳥用に買って G99 をサブに回すか。
でも似たようなカメラを買ってもなぁと思うし、重いのも困る。
E-M5 をサブ機に買って小型軽量狙いのほうがいいかも。
でも評判はイマイチなんだよな、使ってみないとわかんないけど。
この二択だよな、あぁ悩んでいる時が一番楽しい。

bird

先週の五条川、とその周辺。
別の個体だからと同じ鳥を何度も公開、は筆者的にはツマラナイのでまとめて。

hidorigamo

ヒドリガモ、清洲城付近にて。
筆者の認識する五条川は基本岩倉で、犬山の羽黒から清洲まで満遍なくです。
いや、鴨は名古屋城の堀や堀川のほうが寄れるのでソッチのほうがいいよと。
てか特にキンクロハジロなんて堀川ばかりに、五条川にも来てよって。

goji

アオジ、小牧山にて。
基本薮の中にいるんだけど次の薮を狙う時に高所に飛び出す一瞬が狙い。
薮に入ってしまったらカメラで捉えるなんてもう無理だよねこんなの。
2021.11.16 な小牧山は野生のサルが出没らしい、先週から行っていないけど。

uguisu

ウグイス、犬山城付近にて。
えっと、ウグイスって薮の中をサーカス並のアクロバットな移動するのね。
平地ではスズメよろしく両足ジャンプでの移動だけど、薮の中では最強なのかも。
今回は尻しか撮れなかった、それくらいに。

Hataka

ハイタカ、堀尾跡公園付近にて。
こんな見た目なのにハトくらいの体格、タカなのに可愛く見える。
休憩やトイレ用途によく利用している公園だったけど、ココ有名だったのか…
てか SSR だろ、初めて見つけたてか存在すら知らなかったもん。

場所だけ見れば歴史や城のマニアっぽく見えるな、あぁ愛知県の隠れた名所。
城の写真なんて一枚も撮っていないのに。

macOS Monterey JXA

macOS Monterey の JXA は NSRect のバグが無くなった。
ということで、今の知識で NSWindow を作ってみたらどうなるか。

いや PyObjC のほうが簡単なんだけど、デフォルトで入っていないのが。
JXA ならどんな Mac でもそのまま動かせるという利点があるので捨て難い。

ただ JXA では PyObjC みたいに class にできないんだよなぁ。
ネットで簡単に見つかる方法では全部グローバル変数にするしかないのが。
そもそも JavaScript の class は他の言語の class とは違うし。
なので GNOME の Gjs もアクロバットな手段で class っぽくしている。

ObjC.registerSubclass を上手く利用してソレっぽくやってみよう。
追加メソッドはどう書けばいいのかな?とか。

#!/usr/bin/osascript

ObjC.import('Cocoa');

//let wins = [];

ObjC.registerSubclass({
    name: 'AppDelegate',
    protocols: ['NSApplicationDelegate'],
    methods: {
        'applicationDidFinishLaunching:': function (notification) {
            let window = $.MyWindow.alloc.initWithContentRectStyleMaskBackingDefer(
                $.NSMakeRect(0, 0, 300, 100),
                $.NSTitledWindowMask
                | $.NSClosableWindowMask
                | $.NSMiniaturizableWindowMask
                | $.NSResizableWindowMask,
                $.NSBackingStoreBuffered,
                false
            );
            window.makeKeyAndOrderFront(window);
            $.NSApp.activateIgnoringOtherApps(true);
            //wins.push(window);
        }
    }
});

ObjC.registerSubclass({
    name: 'WinDelegate',
    protocols: ['NSWindowDelegate'],
    methods: {
        'windowWillClose:': function(notification) {
            console.log('MyApp Close !');
            return $.NSApp.terminate(0);
        }
    }
});

ObjC.registerSubclass({
    name: 'MyWindow',
    superclass: 'NSWindow',
    propertyies: {},
    methods: {
        'initWithContentRect:styleMask:backing:defer:': function
        (contentRect, style, backingStoreType, flag) {
            let _this = ObjC.super(this).initWithContentRectStyleMaskBackingDefer(
               contentRect, style, backingStoreType, flag);
           _this.title = $('JXA NSWindow');
           _this.delegate = $.WinDelegate.new;
           // Button
           let button = $.NSButton.buttonWithTitleTargetAction('button', this, 'onButtonClick:');
           button.setFrame($.NSMakeRect(10, 10, 200, 36));
           _this.contentView.addSubview(button);
           // return
            return _this;
        },
        'onButtonClick:': {
            types: ['void', ['id']],
            implementation: function(sender) {
                sender.setTitle('Clicked!');
            }
        }
    }
});

/**
 * Application
 */
$.NSApplication.sharedApplication;
$.NSApp.setActivationPolicy($.NSApplicationActivationPolicyRegular);
$.NSApp.mainMenu = function() {
    let mainMenu = $.NSMenu.new;
    let itemApp  = $.NSMenuItem.new;
    mainMenu.addItem(itemApp);
    let menuApp  = $.NSMenu.new;
    itemApp.setSubmenu(menuApp);
    // quit menu
    let itemQuit = $.NSMenuItem.new;
    itemQuit.initWithTitleActionKeyEquivalent('Quit App', 'terminate:', 'q');
    menuApp.addItem(itemQuit);
    return mainMenu;
}();
$.NSApp.setDelegate($.AppDelegate.new);
$.NSApp.run;

nswindow

こんな感じになった、
ボタンのハンドラは delegate ではなく this に届くようだ。
オーバーライドは types 指定不要なのね、ふむふむ。
これだけ解れば応用でなんとかなりそう。

ただ PyObjC と違って NSWindow がガベージコレクションされないんだが。
let 指定ならばハンドラを抜けたら破棄されるはずなんだけど、何故だ?
Python とは破棄対象の選定方法が違うんだろう、知らんけど。

ところで Monterey で今頃気がついたんだけど。

power

iOS みたいに充電の保留機能が付いたんだね。
筆者は滅多に持ち歩かないんで意味はないかもだがけど。