どこかでイベントとかが起こって時間束の破砕とかが起こってるんじゃないかと思ったりしますけど、そういう、円城塔を読んでいない人にはわからないことを書くのはやめて、とりあえず「完結編」のつもりで書き始めることにします。
このへんで、「勝負あった」という感じだと思います。
D7000の時計はかなり正確だけど、D5100は１日１秒くらいのペースで進んでしまいます。２ヶ月では１分も違ってしまうわけで、ちょっとひどいです。
たまたまの個体差なのかもしれないけど、中級機（D7000）と入門機（D5100）では内蔵されている時計の性能まで違うのかなぁ・・・などと思いました。
まあ、そんな結論で「完結」というつもりだったわけです。
ところが、蛇足だろうけど・・・というつもりで連写した写真の話を始めたら、とんでもないことになってきました。
２～ ６枚目 15:45:52
７～１１枚目 15:45:54
１２～１７枚目 15:45:56
１８～２０枚目 15:45:58
それから、１枚目と２枚目、６枚目と７枚目、１１枚目と１２枚目、１７枚目と１８枚目の間に２秒ものタイムラグがあるというのがおかしいです。２０枚の画像は、すべて等間隔で撮られているように思えます。間違っても、その間に１秒以上のタイムラグがあるとは思えません。
一体、何なんだ？？と思って、他の写真も見てみたら、すべて・・・と言ってもカエサルが見てみたところはすべて・・・ということになりますけど、秒のところが２秒刻みになっているということを発見してしまいました。秒のところはすべて偶数で、５１秒とか５３秒という写真は１枚もないのです。
一体、何なんだ？？？？と思って、いろいろと見てみたら、「画像処理ソフトのサムネイルでポップアップして表示される時刻」と「画像情報として記録されている時刻」が違うということも発見してしまいました。
これのサムネイルをクリックすると、あるいはマウスオーバーすると、ポップアップで、ファイル名・画像サイズ・撮影日時などが表示されます。
ここに表示されているのが「画像処理ソフトのサムネイルでポップアップして表示される時刻」ということになります。略して「サムネイル時刻」と呼ぶことにします。これが、すべて２秒刻みなんですよ。
これが「画像情報として記録されている時刻」ということになります。略して「画像情報時刻」と呼ぶことにします。これが、さっきの「サムネイル時刻」とは違うんですね。
連写した２０枚の写真の「画像情報時刻」は、次のようになっています。
７～１２枚目 15:45:50
１３～１７枚目 15:45:51
１８～２０枚目 15:45:52
問題は、サムネイル時刻の方にあるということになります。
ここで、完結したはずの置時計を撮影した写真についても調べてみました。やはり、「サムネイル時刻」と「画像情報時刻」は違いますが、調べてみた範囲では、１秒だけの違いでした。１秒だけなら許してやってもいいかなという気がするので、この記事の前半に書いたデータ（すべてサムネイル時刻）はそのまま使うことにしました。「中級機と入門機では内蔵されている時計の性能も違う」という結論も変えないことにします。
たぶん、サムネイルを作成するときに、独自の「サムネイル情報」みたいなものをつくるんだと思います。そういうのがあると、いちいち「画像情報」を読み込まなくても、サムネイルの並べ替えとかができるということになります。あくまでも推測ですが、ここまでは納得できます。
サムネイル情報は、当然、画像情報をもとにしてつくられることになるはずなので、基本的には、画像情報と一致するはずです。しかし、時刻が２秒刻みになっているということからすると、データのサイズをできるだけ小さくしているんだろうということが考えられます。そのため、画像情報をそのまま用いるのではなく、画像情報→サムネイル情報の変換をしているのだろうと思います。データの圧縮です。だとすれば、１秒のズレが出てしまうのは当然のこととさえ言えます。あくまでも推測ですけど、このへんについても納得してやっていいかなと思っています。
でも、連写した２０枚目の写真では、６秒ものズレがあります。このことについては、今、考えているところなんですよ。
その考えているところを書きたいと思うのですが、「さんすう」の苦手な方には理解不能な文章になると思います。文体も、テキストの色も変えておきますので、無視してやってください（笑）
ここで、まず考えたいことは、表示されるのは１秒（あるいは２秒）単位であるけれど、記録も１秒（あるいは２秒）単位ということではないということある。
このことは、まったく同じ時刻に５～６枚の画像があり、それが撮影された順番通りに表示されるということから容易に想像することができる。
２４時間は、24×60×60＝86400秒であるから、これを１８ビット（２の１８乗＝262144）で記録すれば、その最小記録単位は 86400÷262144=0.33秒 ということになる。１９ビットなら0.16秒、２０ビットなら0.08秒である。
画像情報が１９ビット（0.16秒単位）であるとすれば、１秒あたり５～６枚を記録することができる。
サムネイル情報が１８ビット（0.33秒単位）であるとすれば、２秒あたり５～６枚を記録することができる。
連写での実際の撮影時刻は、0.17秒きざみであったとする。時・分を省略して、0.00秒、0.17秒、0.34秒、0.51秒、0.68秒、0.85秒、1.02秒・・・3.23秒だったとする。
画像情報の最小記録単位は、0.16秒であったとする。端数を切り捨てる形で記録されるとすれば、0.00秒、0.16秒、0.32秒、0.48秒、0.64秒、0.80秒、0.96秒・・・3.20秒として記録されることになる。
サムネイル情報の最小記録単位は、0.33秒であったとする。画像情報をサムネイル情報に変換する場合、単純に端数を切り捨てれば、0.00秒、0.00秒、0.00秒、0.33秒、0.33秒、0.66秒、0.99秒・・・2.97秒として記録されることになる。しかし、これでは、同じ時刻に撮影した画像が何枚もあることになり、撮影した順番がわからなくなる。こうしたことを避けるため、直前にサムネイル化した画像と同じ時刻にはしないということにするのであれば、記録する時刻を繰り上げていくことになる。この場合、0.00秒、0.33秒、0.66秒、0.99秒、1.32秒・・・6.27秒として記録されることになる。
時刻の表示（画像情報時刻、サムネイル時刻）が端数切り捨てで行われるものであるとすれば、２０枚目の画像情報時刻は「３秒」であり、とサムネイル時刻は「６秒」ということになる。６－３＝３秒ずれることになる。このズレは、仮定する数値（実際の撮影時刻の間隔、画像情報・サムネイル情報の最小記録単位）によって、４秒、５秒となることもあり得る。
実際のデータを見てみると、画像情報時刻とサムネイル時刻には、１枚目から１秒のズレがあり、２枚目では３秒のズレがある。そうなった理由は不明であるが、このことを前提として考えると、それから１８枚後の画像に６秒のズレが生じるというのは必然であるとさえ言える。
つまり、どういうことかと言うと、マラソン大会があるのですよ。ゴールと同時に時間が記録されるのだけど、その際小記録単位は１秒です。２時間２４分５６．００秒でゴールした人も、５６．７８秒でゴールした人も、５６．９９秒でゴールした人も、２時間３４分５６秒として記録されるというのが原則です。ただし、この大会では、ゴールした時間の記録が順位の記録として使われるので、本当の同着でないのであれば、記録を同じ時刻にするわけにはいかないのです。そこで、最初にゴールした人はそのまま２時間３４分５６秒ということにしますが、その後の２人は５７秒、５８秒にゴールしたということにしてしまうわけです。実際の時間とはズレが生じてしまいます。１秒間に何人もの人が次々とゴールしたような場合は、そうしたズレがどんどん大きくなってしまいます。
そういうことじゃないのかな。もちろん、違うかもしれません。やはり、どこかでイベントが発生して、時間束が破砕してしまったのかもしれません。
← 応援クリック、よろしくお願いします。
※コメント投稿者のブログIDはブログ作成者のみに通知されます