2009-05-27

16:9の構図についてのお話を読んだ

アニメ

16:9の構図の分類　〜けいおん！，タユタマ，大江戸ロケット〜 - WebLab.ota
こちらを読んで、だいぶ感じ方が違うなと思ったので。

これは，右のキャラが左の２人のオバサンたちの世間話を盗み聞きする…という場面である．
一目瞭然だけれど，4:3で表現しようと思ったらパンさせるしかない構図になっている．
16:9の構図の分類　〜けいおん！，タユタマ，大江戸ロケット〜 - WebLab.ota

「16:9でしか表現できない構図」として例示されているんだけど、まだカメラを引く余地があるのでパンさせる必要は無いと私は思う。
（引用元の画像を利用させていただいています）
こんな具合で。欠けている部分は当然絵が入ります。脳内補完。元がだいぶ寄り気味の画なので、4:3に収まるまでカメラを引いても人物の大きさは確保できるし、引いたことによって破壊されてしまう要素は特に無いんじゃないかな。元々が人物と背景のカメラがまるで違うという、ゆるいカットだし。

これは，右のキャラが左の２人のキャラに文句を言って，それに対して一番左のキャラ（主人公）がリアクションするシーンなんだけれど
これも，4:3で表現しようと思ったらパンさせるしかない．

これもまだ引けると思う。

実際に4:3で画作りするなら、人物の配置も調整する余地があるんじゃないかな。

で、思ったんですけど、上の二つって「16:9でしか表現できない構図」というよりは「16:9から4:3にパン＆スキャンしたときに問題の出る構図」って感じですよね。でもそういう前提には読めなかったんだけど、どうなんだろう。私の誤読かな。

追記 5/28

一応自分の考え方を補足しておくと、「16:9をうまく使っている構図」の例については確かに4:3では難しいと思う。カメラを引くとか、桶をもっと奥において人物の配置も調整するなんて選択は有り得ない。それでは桶を中央に配した意味が弱まってしまう。

2009-05-21

ドコモのおさいふケータイ対応端末の内臓ICカードはドコモショップに設置のDOCOPYで初期化できる

雑記

おさいふケータイに対応したFOMA端末を譲ってもらったが、ICカードに前オーナーのデータが残っていたために「FOMAカード(UIM)情報が一致しない」云々とのメッセージが表示され、おさいふケータイ用のアプリが起動できない・削除できない・ダウンロードできないという状態になっていて困る→ググる
→ドコモショップに持ち込め→え、窓口持ってかなきゃダメなの。手数料かかったりしないの？→もう少しググる
→それ、DOCOPYで自分で出来るよ。
というわけで、ドコモショップに行ってDOCOPYを使って初期化してきた。所要時間1分。よくよく調べたらドコモのサイトにもしっかり書いてある。

・iCお引っこしサービス（ICカード内データの移行）
・ICカードフルフォーマット（ICカード内データの消去）
DOCOPY（ドコピー） | お客様サポート | NTTドコモ

DOCOPYの利用はもちろん無料。操作も自由にさせてもらえるので、初期化の理由を詮索されるなんてことは無し。というのは、この問題にはまるのはオークションで白ロムを手に入れた人が多いみたいで、ググった先では何だか心配している人が多かった。ビクビクしすぎだと思う。

2009-04-19

jpegで保存を繰り返す

雑記

新規保存で劣化していくJPEG形式の画像の様子をとらえたムービー - GIGAZINE
すでに追記があるけど、件のムービーは前回保存時よりQualityを落としながら読み込み保存を繰り返してるんだと思う。試しに似たようなことをやってみた。

use Imager;
use strict;
use warnings;
my $base = 'test';
my $ext = '.jpg';
my $file = 'test.jpg';
my $img = Imager->new;
for(0..99){
    $img->read(file=>$file);
    $file = $base . $_ . $ext;
    $img->write(file=>$file, jpegquality=>100-$_);    #前回保存時よりQualityを減らしていく
}

　test0.jpg
　test49.jpg
　test99.jpg
ムービーと似た画像ができたよ。

今度はQualityは落とさずに固定。読み込み〜保存を1000回繰り返す。

use Imager;
use strict;
use warnings;
my $base = 'test';
my $ext = '.jpg';
my $file = 'test.jpg';
my $img = Imager->new;
for(0..999){
    $img->read(file=>$file);
    $file = $base . $_ . $ext;
    $img->write(file=>$file, jpegquality=>80);    #qualityを固定
}

　test0.jpg
　test999.jpg
フォトライフは再圧縮しちゃうので比較画像のアップロード先としては適切じゃないけど、ムービーみたいな酷いことにはならないことは分かるかな。

Name         MD5                               Bytes
-----------  --------------------------------  -------
test0.jpg    505831637146568AFE85EC37C3949141   24,713
test1.jpg    8D4CFB1337F7F95F0EE21DD68A243BC3   24,715
test2.jpg    526D1EFBADDD81A6B1EAB6346F2E59BE   24,719
test3.jpg    D49CFDCE6ACAE9E22E15ED81B594D452   24,720
test4.jpg    DC667B9AEBD5424E53122E00C63F62BD   24,715
test5.jpg    25F0C995688B8042F8A4022B21BB9B35   24,715
test6.jpg    25F0C995688B8042F8A4022B21BB9B35   24,715
.
.
.
test999.jpg  25F0C995688B8042F8A4022B21BB9B35   24,715

md5とったら test5.jpg以降は完全に一致してた。（ただこれは同一エンコーダー同一設定で画像には一切手を触れずに保存を繰り返すというあまり現実的では無い実験なんで、これをもってjpegで保存を繰り返しても劣化は進まないと思ってはいけない）

2009-01-17

■

2009-01-02

アニソン三昧の放送曲を垂れ流す twitter bot を作った。

web

大晦日のことでとっくに終わった話ですが、12/31にNHK FMにて放送された「今日は一日アニソン三昧ファイナル」の放送曲を垂れ流すbotを作って放送時間中に運用しました。やり方は、Web::Scraperで曲リストを取って、Net::Twitterで投稿するというperl スクリプトをVMware上のCentOSでまわしてただけです。
Twitter / aniSonZanmai
放送当日に急に思いついて、動かし始めたのはお昼前くらいだったでしょうか。公式サイトの曲リストから拾って流すだけの存在意義の微妙なbotでしたが、最大で六十数名の方がフォローしてくれていた様です。

2008-12-12

マクドナルドの簡易包装

食

自転車のカゴは別のもので埋まります、だから手提げ袋ないと自転車乗れません。だけど出てきたのは手提げ出来ない紙袋です。
というわけで手提げ袋くれと頼みました、店員のオバサンが「お客様、大きいのしかないんですよ！次からご協力ください！」と説教口調で言ってきて大きい袋くれました。
いやー俺も出来る限りご協力したいんですけどね。仕方ない場合ってのあると思うんですけど。
マクドナルドで持ち帰り頼んだ

マックは持ち帰り時に袋が一つの時は手提げ袋を付けない対応をするようになって、自転車の都合で手提げ袋を要求したら説教口調の対応をされたって話。ちょうど4,5日前に私自身がマックで手提げ袋についてのやり取りを目撃したばかりだったので興味深かった。
マクドナルド、12月より、簡易包装を開始全国約3,700店で持ち帰り用レジ袋を全廃へ
 This is ECO STYLE。簡易包装、はじめます。 | 企業情報 | McDonald's Japan
ちょっと調べたら、12月1日から簡易包装を開始し、2袋までは手提げ袋に入れないという対応になったようだ。但し、客が手提げ袋を要求すれば、2袋まででも手提げを付けてくれるとのこと。

http://www.mcdonalds.co.jp/company/eco/campaign/vol01.html

This is ECO STYLE。簡易包装、はじめます。 | 企業情報 | McDonald's Japan via kwout

これを見て私は「嘘だあ〜」と思った。何故なら記事の話では説教口調の対応をされながらも、手提げ袋を手に入れることが出来たようだが、私が目撃した件では手提げ袋を手に入れることが出来なかったから。手に入れることが出来なかった客。マックに隣接するスーパーの手提げ袋で両手が塞がっていた女性は、紙袋二つを目の前に出され、「袋に入れてもらえますか」と要求したが、結局手提げ袋に入れてもらうことなく、左手にスーパーの袋を二つ、右手にマックの紙袋二つという状態で帰っていた。細かいやり取りは聞こえなかったが、最後に聞こえた「分かりました、もういいです！」という言葉と、レジから出口に振り返った瞬間に見せた女性の鬼の表情……が大変印象に残っている。
と、こういう経験があったので、「嘘だあ〜」と思ってしまったのだが、全国のマックについて一般化出来る話では無いというのは理解している。多分、基本的には柔軟な対応がされているのだと思うんですけどね。だから特にこれが問題だとか大げさに言うつもりはないけど、簡易包装導入にあたって少々不適切な対応をしているお店もごく一部にあるみたいですよというお話でした。終わり。

2008-09-27

はてなフォトライフの困った仕様

web

昨日、Microsoft Image Composite Editor - kABok を書くにあたり画像をはてなフォトライフにアップロードしたが、アップロードした画像が上書きされるという現象に遭遇してはまった。後で調べたら、既にはてなアイデアで散々話題になってることだったけどメモしておく。

困った仕様1

フォトライフの設定で「画像の表示順」が「撮影順」（デフォルト）になっていると、Exifに同じ年月日時分秒を撮影日時に持つ画像はフォトライフ上に複数存在できない。同じ撮影日時のファイルがアップロードされた場合、先に存在したファイルは確認すること無く上書きされる。

何でこんなことになっているかというと、アップロードされた画像のファイル名を撮影日時で作っているからだと思われる*1。試しに2123/11/22 12:34:56 という撮影日時を持つファイルを作ってアップロードしたところ、21231122123456.jpg (JPEG 画像, 640x480 px) というファイルが出来た。
この仕様、一人のユーザーに限れば撮影日時はユニークだろうという発想で決めたと思うんだけど、撮影日時は全然ユニークにならない。ユニークにならないケースは色々想定出来るけど、可能性が高くて自分もはまったのが画像を編集してアップロードしようとした時。デジカメで撮影された画像を編集するようなソフトは、編集後の画像に元となった画像のExifをコピーするものが非常に多い。つまり、編集前と編集後の画像は同じ撮影日時を持つことになる。ということは、編集前と編集後の画像は同時にフォトライフにはアップロード出来ないことになり、実際アップロードすると上書きが行われどちらか一つの画像しか存在できない。以下は編集前と編集後のファイルをアップロードしたサンプル。二つの魚拓を見比べると、同じurlで表示される画像の中身が入れ替わっている。
魚拓リスト - http://f.hatena.ne.jp/kobak/21231122123456

困った仕様2

フォトライフの設定「画像の表示順」を変更すると画像の表示順だけでなく、アップロード時のファイル名の作り方も変更される。既に述べたように「撮影順」の時は撮影日時でファイル名を作っているが、「アップロード順」に変更するとアップロードした日時でファイル名が作られるようになる。実は「撮影順」の時も撮影日時の情報が無いファイルについてはアップロードした日時でファイル名が作られているが、「アップロード順」に変更すると撮影日時の情報が存在するファイルでもそれを無視するようになる。
そして不思議なことが起きる。それは「画像の表示順」を再び「撮影順」に戻した時。この時、「アップロード順」の時にアップロードしたファイルは撮影日時の情報が存在しても、アップロード日時を撮影日時として表示が行われてしまう。
どうしてこんなことになるのか。「撮影順」の時にアップロードしたファイルは「アップロード順」に変更した時でも、きちんと並び替えが行われるのに。自分の予想だと撮影日時はファイル名から、アップロード日時はファイル自身のタイムスタンプから取得して並び替え処理を行っているんじゃなかろうかと考えるが実際はどうなんだか。

*1:実態は異なる可能性もあるが、ユーザーから観測出来る挙動として