デジタルネガを使った暗室プリント体験

通常、暗室におけるプリントではフィルムを現像したネガを用いる。しかし、デジタルデータからネガを作成してプリントする技法があることを知り、東京都写真美術館が開催している「モノクロ銀塩プリントワークショップ(ハイブリッド方式)」で体験してきた。

以前からデジタルネガに興味はあったのだが、自分で試すには敷居が高い(プリンタ、専用の紙(ピクトリコ)が必要)ため、写真美術館のワークショップへの参加を狙っていたのだ。

今回は2枚プリントすることができた。ボランティアスタッフの手で印刷されたデジタルネガは4×5のサイズだった。このサイズのネガを見るのは初めてだっため、なかなか新鮮だ。そのままでも結構見られるため、ポジフィルムだともっとすごいのだろう。

IMG_1135

印刷されたネガは、片面にインクが乗っているため、乗っていない側から見るとボンヤリとしている。上の写真はインクが乗っている面を下にしている。

ネガのサイズが大きいが、プリントでやる事は35mmと変わらない。暗室でのプリントは4〜5年ぶりだったが、結構体が覚えているもので、すぐにサクサクとプリントできるようになった。

IMG_1137

RCペーパーにプリントされた写真。1カットにつき5〜6枚プリントした。ボランティアスタッフの方にアドバイスを頂きつつ完成に追い込んでいく作業は楽しいもので、あっというまに時間が過ぎてしまった。

プリントの質だが、ネガからプリントした写真を最後に見たのがかなり前なので比較するのは難しい。が、やはり黒色は綺麗に出ていると思う。同じ画像をネットプリント等で出力して、見比べてみたい。

久しぶりの暗室作業だったが、PCでやるのに比べ、やはり作業自体が楽しい。紙に絵が浮び上がる瞬間や、暗室から出て光を当てる時間を検討したりするのは、PCでは味わえない。年に一度位、レンタル暗室で作品を作るのもいいなと思った。

そうそう、今回は引伸機を使って印画紙に焼いたのだが、実際にはデジタルネガを印画紙に密着させて焼き付ける方が主流らしい。この方法だと引伸機が必要ないので、自宅でプリントする敷居が下がる……うっかり機材を揃えたくなるので注意しないといけない。

Go言語の構造体でタグを使う時のメモ

型の後ろに「xml:"hoge"」と書けば,Marshal・Unmarshal時に対応づけてくれる.

[go]
type Foo struct {
Hoge string xml:"hoge"
}
[/go]

jsonもOK.

[go]
type Foo struct {
Hoge string json:"hoge"
}
[/go]

xmlとjson両方設定する場合はスペースで区切る.

[go]
type Foo struct {
Hoge string xml:"hoge" json:"hoge"
}

type Foo struct {
Hoge string xml:"hoge" json:"hoge"
}
[/go]

DockerのストレージバックエンドにBtrfsが使えるようになってたので試した

みなさんこんにちは。 最近Docker Meetup in Tokyo #1の参加を逃したりImmutable Infrastructure Conference #1の参加申し込みに出遅れたりしてがっくりしている@r_takaishiです。

さて、今回はDockerのv0.8でストレージドライバに新しくBtrfsが追加されたので、これを試してみました。

Btrfsをストレージとして使うための準備

まずは、DockerがBtrfsをストレージとして使えるようにします。 なお、環境ですが、Vagrant + Ubuntu13.10 を使用しました。 Dockerのインストールは公式ドキュメントに従っています。 Btrfsを使うための手順は以下の通りです。

  1. Btrfsなパーティションを作成 & マウントする
  2. Dockerデーモンの起動オプションでストレージドライバとデータ保存先のディレクトリを指定する
  3. Dockerデーモンを再起動する

Btrfsなパーティションを作成 & マウントする

適当にストレージを追加して、mkfs.btrfsでファイルシステムを作成、任意のディレクトリにマウントするだけです。 今回は、「/opt/docker」にマウントしておくことにします。

Dockerデーモンの起動オプションでストレージドライバとデータ保存先のディレクトリを指定する

Dockerのデーモンは標準だとストレージドライバにaufsを、データの保存先には「/var/lib/docker」を使用します。 これを、ストレージドライバにbtrfsを、データの保存先には「/opt/docker」を使用するように設定してあげます。 サービスとして起動しているので、その設定ファイルである「/etc/default/docker」内の「DOCKER_OPTS」を以下のように書き換えます。

[bash]
DOCKER_OPTS="-s btrfs -g /opt/docker"
[/bash]

Dockerデーモンを再起動する

再起動しましょう。これで、ストレージドライバにBtrfsを使うようになります。

[bash]
sudo service docker restart
[/bash]

aufsとbtrfsで、コンテナのビルド速度を比較する

Btrfsストレージドライバを触っている時、ビルドに時間がかかるような気がしたので、aufsと比較してみることにしました。 比較する操作は以下の通り。

  1. ubuntu:13.10をベースにイメージを作成(ubuntu:13.10はあらかじめpullしておきます)
  2. 1で作成したイメージをベースにイメージを作成
  3. 2で作成したイメージをベースにイメージを作成
  4. 2〜3を100回繰り返す

これらの操作を行うスクリプトをRubyで書き、1〜4に要する時間を測定しました(測定回数は一応5回)。 その結果、以下のように大きな差がありました。

  • Btrfs:平均256秒
  • aufs: 平均47秒

実に5倍の差があります。現時点で、Btrfsストレージドライバは実験的なものではあるのですが、これ程差があるとは思いませんでした。 仮想マシンを作成する事に比べるとはるかに高速ですが、それでもインフラをCIするような、ビルドを何度も繰り返すことになるケースだと遅く感じる事がありそうです。 今の所aufsの使用で困っている事はないので、Btrfsストレージドライバをメインに使うのはしばらく先にしようと思います。 Btrfsストレージドライバが遅い理由までは今回は調べることはできていません。現状の実装の影響なのか、そもそも仕組みからして遅い、という可能性もあります。 後、これもきちんとは調べていないのですが、aufsで100個近くヒストリを繋いでいると、後半にいくにつれて若干ビルドに時間がかかるようになっていたような気がします。 今後、調べてみたいですね。

備考

測定に使用したスクリプトは以下の通りです。出力が汚いけど気にしない。

 

[ruby]
— coding: utf-8 —

require ‘benchmark’ require ‘systemu’

5.times do |count|
# Btrfs用。作成したイメージ等を全削除する。 #sudo service docker stop #cd /opt/docker && sudo btrfs subvolume list . | awk ‘{print $9}’ | xargs -I{} sudo btrfs subvolume delete {} #sudo rm -rf /opt/docker/*
# aufs用。作成したイメージ等を全削除する。 sudo docker images | awk ‘{print $3}’ | xargs -I{} sudo docker rmi {} sudo service docker stop sleep 2 sudo rm -rf /var/lib/docker
# サービスの起動と初期イメージの取得 sudo service docker start sleep 2 systemu "sudo docker pull ubuntu:13.10"
# ビルドの繰り返し(ここの時間を測定) Benchmark.bm do |x| x.report("#{count}: ") { base_id=” status, stdout, stderr = systemu "echo ‘FROM ubuntu:13.10\nRUN echo init >> /log’ | sudo docker build -t base -" stdout.each_line do |line| if line =~ /Successfully built (.*)\n/ base_id=$1 end end

100.times do |num|
status, stdout, stderr = systemu "echo ‘FROM #{base_id}\nRUN echo #{num} >> /log’ | sudo docker build -t #{num} -"
stdout.each_line do |line|
# puts line
if line =~ /Successfully built (.*)\n/
base_id=$1
end
end
end
end
[/ruby]

センサー付きLEDがライフチェンジングだって話

センサーがついているLED電球を購入して、小さいけど生活が改善した。

今住んでいる部屋は玄関に照明があるのだけど、暗くなってから帰ると手でつけなければいけない。
だけど、スイッチがちょっと離れた所にあって、手を伸ばす必要がある。
じゃあつけっぱなしにしておけばいいかというとそれはそれでもったいないような気がするし、使わない時はやはり消しておきたい。

ということで、センサーがついた電球はないかなと思って探してみるとやはりあった。
結構いろんなメーカーが作っているのだけど、玄関の照明はE16口径で、しかも斜め取り付けタイプなので選択肢がなく、アイリスオーヤマのこれを購入。

{% amazon text B006IHKRDY %}
{% amazon medium_image B006IHKRDY %}

昨日届いたので設置したけど、手を伸ばしてスイッチをつける、という動作が必要ないって素晴しい。

org-modeのアーカイブ先ファイル名を変更する

org-modeでタスクを管理していると、だんだんファイルサイズが大きくなる。 そのため、「org-archive-subtree」を使って完了したタスクをアーカイブしてファイルのサイズを小さくするのだけど、数年使っているとアーカイブ先のファイルサイズが大きくなる。 そこで、このアーカイブ先のファイル名を変更して肥大化を防ぐ。

ファイル名は標準では「%s_archive」である。「todo.org」の場合は「todo.org_archive」だ。 この名前は「org-get-location-archive-location」で決定される。 バッファ内に「#+ARCHIVE: 文字列」というオプションを設定している場合はその名前が使われる。 設定していない場合は「org-archive-location」変数が使われる。 そこで、次のように設定する。

scm
(setq org-archive-location (concat "%s_archive_" (format-time-string "%Y" (current-time))))
接尾辞として「_archive_2014」のように、その年をつけることで、毎年違うファイルにアーカイブできる。