Nikon AF-S NIKKOR 35mm f/1.4GとSigma 35mm F1.4 DG HSMの比較（その2）
新しくレンズを購入したらすぐにでも使って試したいのが人情です。
Sigmaのレンズを入手した時も、その週末にすぐポートレート撮影に出かけました。それまでの数日は、自宅で少し試し撮りをしたくらいで、あまり細かな検証はしないまま出かけました。
結果は失敗でした。AFのピントが合っていないのです。横位置の撮影でフォーカスポイントは中心付近とし、被写体まで1、2mくらいの距離であればAFは許容範囲内でした。これは自宅での試し撮りでも確かめていました。
ところが縦位置で数m離れてモデルさんの全身を入れると（フォーカスポイントはかなり端の方を使うという意味）、目にピントを合わせているはずがかなり前ピンで顔がぼけているのです。しかもほぼすべてのショットです。純正を使っていたときは絶対に無かったようなピンぼけ写真を量産してしまいました。いいモデルさんだったので無念でした。
撮影の仕方、ピントの合わせ方の問題もあるかもしれませんが、純正レンズでも撮影方法は同じですし、こんなにAFのピントが外れたことはありません。
家に帰ってたくさんのピンぼけ写真を見ながら、対策を考えました。
まず考えたのはカメラ側での対応です。
Nikon機（少なくともD810）には「AF微調整」という設定項目があり、レンズごとにAFの微調整ができます。これを「+15」くらいにすると、縦位置全身での顔の前ピンがかなり改善されました。他の撮影距離や横位置での撮影でもその設定で問題なさそうだったので、次の撮影はこれで臨むことにしました。
AF微調整を使っての撮影は、無調整のときよりも格段にAFが合うようになりました。
でも少し問題がありました。私の場合、35mmレンズは純正とSigmaを持っていて、撮り比べのために撮影途中で取り替えることもあります。
ところがAF微調整はレンズの焦点距離と開放絞り値の組み合わせでレンズを識別するため、カメラ側は純正とSigmaの区別ができないのです。つまりSigmaのレンズを装着したらAF微調整をオンにし、純正レンズに代えたらAF微調整をオフにするというメニュー操作をしなければなりません。万一それを忘れたら、ピンぼけ写真の量産です。
そもそも使うレンズとAF微調整のオンオフを意識しなければならないなんて嫌です。私の場合はSigmaと純正の使い分けでしたが、純正の同一レンズを2本持っている場合も同様の問題が生じます。
AF微調整がレンズ固有の番号（たとえばシリアル番号）みたいなものでレンズを識別し、それに対応したAF微調整の値が設定されるような仕組みになっていれば、このような問題は起こりません。原理的には十分実現可能な気がしますが、旧タイプのレンズなども含めた完全な対応は難しいかもしれませんね。だからこそ、こういう中途半端な仕様になっているのでしょう。
この状態で使うのは不本意です。
AF微調整はオフのままSigmaのレンズが使えるようにしようと思いました。
（つづく）
Nikon AF-S NIKKOR 35mm f/1.4GとSigma 35mm F1.4 DG HSMの比較（その1）
銀塩カメラを使っていた頃から焦点距離35mmのレンズが好きで、一番よく使っていました。その頃は旅行での風景や記念写真が主でした。
デジタル時代になり、ここ数年は室内ポートレートばかり撮っていますが、35mmの使用頻度が一番高くなっています。寄ってバストアップを撮るもよし、少し引いて全身を入れてもよしで使いやすいからです。
そんなわけで35mmはもともと一番好きな焦点距離で思い入れがある上、実際の使用頻度でも一番ですから、納得のいくいいレンズを使いたいと思いました。
実は一番最初にNikon Ai AF Nikkor 35mm f/2Dを買いましたが、D800系で使うには解像も粗い感じがしたのと、レンズの作りも無骨な古い感じがあってなじめませんでした。もうひとつ、オートフォーカス（AF）が動くたびに一緒にピントリングがぐるっと動いて指をこすって痛い（笑）というのもありました。
もしかしたらこのレンズ特有の味のようなものがあったかもしれず、もう少し長く使って試してもよかったかなと思いますが、とにかく早々に手放してしまいました。
そして買ったのがNikon AF-S NIKKOR 35mm f/1.4Gです。これを買った当時は、単焦点レンズに10万、20万も出すなんて考えたこともない時期だったので相当な勇気を振り絞って注文しました。
購入してから3年ほど経ちますが、これは買っておいて本当によかったと思っています。描写もしっかりしており、AFも安定していて、純正の安心感もあります。思い入れのあるモデルさんの写真は、このレンズで撮って残しておけてよかったと心から思っています。
Nikon AF-S NIKKOR 35mm f/1.4Gの購入当時、競合するレンズはCarl Zeiss Distagon T* 1.4/35 ZF.2くらいしかありませんでしたが、ZeissはAFが使えないので私にとっては論外でした。主にマニュアルフォーカス（MF）で撮っている人もいるでしょうし、AF任せと言ってもMFを併用することもあるでしょうし、MFを否定する気は全くありません。でも、逆にAFが全く使えないというのは私にはあり得ません。かえってZeissでAFが使えなくてラッキーだったかもしれません。もしAFも使えるとなれば選択肢に入ってきて、やはり買って試したくなるに違いないからです（笑）
35mmに関しては、買い換える誘惑のない安泰な日々を過ごしていましたが、Sigmaから新しいレンズが発売され、少し心が揺らぎました。それがSigma 35mm F1.4 DG HSMです。性能の評判もよく、特に解像では純正以上との噂でした。純正レンズを手放して買い換えた人もいるようなので、かなり気になっていました。それでもすでに純正を持っていて、しかも満足していましたから、しばらくは模様眺めをしていました。
でも結局自分で試してみたい欲求に勝てず、昨年Sigma 35mm F1.4 DG HSMを買ってしまいました。それから半年ほど純正（Nikon AF-S NIKKOR 35mm f/1.4G）とSigma（35mm F1.4 DG HSM）を併用して、自分なりの評価が固まってきたので書いておきます。
（つづく）
Windows8.1のVPN（L2TP/IPsec）接続でownCloud（認証が必要なページ）にアクセスできない
自宅LAN内にLinuxサーバーを立てて、webサーバー、ファイルサーバーなどとして使っています。外には公開しておらず自宅内でアクセスするのみです。
そこで、外からもVPNで自宅LANに接続し、自宅と同じようにサーバーにアクセスできるようにしました。
外からVPNで自宅に接続するにあたり、PPTPはセキュリティの問題があり、L2TP/IPsecにしたかったので、それをサポートしている安いルーターを探して、バッファローのVR-S1000を買いました。
BUFFALO IPsec対応 VPNルーター VR-S1000
- 出版社/メーカー: バッファロー
- 発売日: 2013/12/14
- メディア: Personal Computers
- この商品を含むブログを見る
Macbook Air（MacOS X Yosemite）やiOSからはモバイルルーターを通してL2TP/IPsecで問題なく接続できていました。
その後、新たにWindows8.1搭載のNEC Lavie Z (LZ550/T)を買ったので、同様に接続しようとしたけれど、どうもうまくいきません。サーバーには繋がるのですが、ownCloudなどの認証が必要なページにはタイムアウトで入れないのです。
現象をまとめると次の通りです。
- L2TP/IPsecのVPNでルーターまでは接続できている。
- サーバーのローカルIPに対してpingが通る。
- サーバーのapacheのトップページ（デフォルトだとIt works!）は表示できる。
- ところが、サーバーのownCloudなど認証を必要とするページにアクセスすると、ずっと応答待ちの状態になり、最後はタイムアウトになる。
- 認証が必要なsambaのファイルにもアクセス不能。
自宅サーバーはubuntu 14.04LTS。apacheでWebサーバーを立ててownCloudを使っています。
VPN接続はできていても、使いたいのはownCloudなどの機能なので、実際には使いものにならない状態です。
Macbook Airでは問題なく使えているので、Windows8.1の問題ということになります。
最初は接続設定の問題かと思い、あちこち変更しましたが、状況は変わらず。
緊急避難的にPPTPで接続してみると、こちらはownCloudにも繋がります。
ほとんどあきらめかけていたとき、ネット検索でひっかかったのがMTU値の変更です。
元記事はこちらです。
http://cathval.com/network/3847
この記事を元に、MTUを1258に変更したら問題解決しました。
作業過程を記録しておきます。
VPN接続した状態で、管理者権限でコマンドプロンプトを起動して、次のようにデフォルトの状態を確認します。
>netsh interface ipv4 show interfaces
Idx Met MTU 状態 名前
--- ---------- ---------- ------------ ---------------------------
1 4275 4294967295 connected Loopback Pseudo-Interface 1
3 4250 1500 connected Wi-Fi
44 20 1400 connected L2TP-IPsec
5 4265 1500 disconnected Bluetooth ネットワーク接続
7 4230 1500 disconnected ローカル エリア接続* 1
L2TP-IPsecのMTUが1400になっています。これはPPTP接続をして確認した場合も同じでした。でもL2TP/IPsecではこのままではダメらしい。
これを次のようにして、1258に変更します。
なぜ1258になるのかは、元記事を参照して下さい。コマンド引数の44という値は、上のnetshコマンドで確認したIdx値を入れて下さい。
>netsh interface ipv4 set interface 44 mtu=1258
本当に変わっているのか確認します。
>netsh interface ipv4 show interfaces
Idx Met MTU 状態 名前
--- ---------- ---------- ------------ ---------------------------
1 4275 4294967295 connected Loopback Pseudo-Interface 1
3 4250 1500 connected Wi-Fi
44 20 1258 connected L2TP-IPsec
5 4265 1500 disconnected Bluetooth ネットワーク接続
7 4230 1500 disconnected ローカル エリア接続* 1
ちゃんと1258になっていますね。
この変更をしたとたん、ownCloudにもsamba上のファイルにも問題なくアクセスできるようになりました。
Windows8.1のVPN接続のデフォルトではMTU=1400になっているので、このままL2TP/IPsec接続するとうまくいかないようです。
no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory
見出しの変なエラーメッセージ、ubuntuを14.04LTSにバージョンアップしてから出るようになりました。
ターミナルでsudoで何かコマンドを打ったときに出ます。
すごく気持ち悪いメッセージですが、PC自体は別に何事もなく動きます。本当は何か問題があるのかもしれませんが、メッセージを見ない振りをすれば実用上問題ないので（笑）、ついついそのまま過ごしていました。
ubuntu 14.04LTS
samba 4.1.6
ところが、このメッセージで検索するとそのものずばりでかなりヒットします。
例えばこんなところ。
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1257186
いつもながら英語でよく分かりませんが、どうもsambaがらみのエラーらしい。libparam-smbpassが悪いので、これがインストールされているのならばremoveするらしい。
user@myserver:~$sudo apt-get remove libpam-smbpass
ということで、これを実行した後の確認。
user@myserver:~$ dpkg -l | grep smb
rc libpam-smbpass:amd64 2:4.1.6+dfsg-1ubuntu2.14.04.4 amd64 pluggable authentication module for Samba
ii libsmbclient:amd64 2:4.1.6+dfsg-1ubuntu2.14.04.4 amd64 shared library for communication with SMB/CIFS servers
ii python-smbc 1.0.14.1-0ubuntu2 amd64 Python bindings for Samba clients (libsmbclient)
ii smbclient 2:4.1.6+dfsg-1ubuntu2.14.04.4 amd64 command-line SMB/CIFS clients for Unix
libpam-smbpassは削除前の「ii」から「rc」に変わっており、削除されたようです。
見出しのエラーメッセージはsudoでコマンドを打ったときに必ず出るわけではないので、本当に直っているのかしばらく様子を見ます。
ownCloud 8にアップデートしたら、しばらくすると接続不能になる
自宅サーバーでownCloudを使っています。
先日ownCloudのサーバー側ソフトがバージョンアップしたので、7から8にアップデートしました。私の環境は以下の通りです。
ubuntu 14.04LTS
ownCloud 8.0.2 (stable)
Apache 2.4.7
PHP 5.5.9
当初は問題なく動いているように見えましたが、しばらく運用しているとownCloudに接続できなくことに気づきました。apache自体は動いていて、サーバーのトップページにはアクセスできるので、ownCloudがハングアップ？しているような感じです。apacheを再起動すると、再びownCloudにアクセスできるようになります。でも数時間すると、またアクセス不能になっているのです。
1週間、2週間とそんな状態が続き、気づいたときにapacheの再起動をするという姑息な手段でしのいでいました。
で、ようやく同じトラブルの記事を見つけて解決方法が分かったので書いておきます。
元記事はここです。
https://forum.owncloud.org/viewtopic.php?f=31&t=26331
英語なので、ざっと読んだ限りPHP APCというのがownCloudのコードと干渉している？みたいです。なので、PHP APCを外してしまうというのが解決策のようです。確認してみると確かにphp5-apcuというパッケージがインストールされています。
user@myserver:~$ dpkg -l | grep php5-apcu
ii php5-apcu 4.0.2-2build1 amd64 APC User Cache for PHP 5
そこで、元記事にあるようにこのパッケージをpurgeします。実行するのは赤字のコマンド1つだけです。
user@myserver:~$ sudo apt-get purge php5-apcu
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下のパッケージは「削除」されます:
php5-apcu*
アップグレード: 0 個、新規インストール: 0 個、削除: 1 個、保留: 21 個。
この操作後に 313 kB のディスク容量が解放されます。
続行しますか? [Y/n]
(データベースを読み込んでいます ... 現在 342623 個のファイルとディレクトリがインストールされています。)
Removing php5-apcu (4.0.2-2build1) ...
php5_invoke prerm: Disable module apcu for apache2 SAPI
php5_invoke prerm: Disable module apcu for cli SAPI
php5_invoke prerm: Disable module apcu for cgi SAPI
Purging configuration files for php5-apcu (4.0.2-2build1) ...
あとはapacheを再起動するだけです。
user@myserver:~$ sudo service apache2 restart
* Restarting web server apache2
今のところ、これで順調に動いているようです。
はじめに
趣味のPCやカメラなどで困ったときネット検索するわけですが、自分と同じトラブルにあって解決している方のブログを参考にしています。
ブログを書いている人にとっては、すでに解決した問題なわけで、わざわざブログに書くなんて面倒なことをしなくてもいいはずなんですが、それを書き残してくれているからこそ、私が解決できているんです。ありがたいことです。
そんなわけで、私もたまーーに、解決できたトラブルを書き残しておいて、誰かの役に立てばいいなと思います。
