KODAK FZ45 マニュアルモード
20年ほど前にフィルムカメラにハマった/沼った時、一眼レフやレンジファインダーはもちろんだけど、インスタントカメラ、トイカメラもかなり面白かった。
中でも雑貨屋さん系で買ったプラモデルカメラはほんとチープで面白くて持ち歩いてた時期があった。
プラスチックのレンズは28mm、絞りはF9、シャッタースピードは1/125。
露出オーバーだろうがアンダーだろうが気にせず…というかおもちゃカメラだとそんなことは知ったこっちゃなかった。
という前置き。
KODAKのFZ45でも同じようなことをやってみようと、プラモデルカメラに近い感じに設定した。
FZ45の場合、絞りはF3.0かF10.4の2択。被写界深度を深くしてパンフォーカス狙いなので当然10.4。シャッタースピードは1/100か1/125。ISOは100か400。焦点距離は27mm。
絞り10.4が最優先で、これと27mmは固定。シャッタースピードは手ブレが怖いけど100をメイン。
ISOで露出を調整することになるんだけど、ザラついた写真にはしたくないんでできればISO100、最高でもISO400。
これでプラモデルカメラのようにパシャパシャ撮ってみたけど、露出がオーバーだろうがアンダーだろうが気にしないこの感じが懐かしい、楽しい。
F10.4 1/125 ISO100
F10.4 1/100 ISO400
F10.4 1/100 ISO100
F10.4で絞り込んだのでピントが合う範囲が広くて気持ちいい。
シャッタースピードやISO感度を多少調整して…でも、これぐらい撮れるなら全部固定にして露出アンダーやオーバーは気にしないということでやっても面白いかも。
プログラムモードでもあんまり変わらないっちゃ変わらないんで、気分で使い分け、かな。
昔プラモデルカメラで撮ってていざフィルムを現像してみたらさすがにちょっと…というのがかなりあって、それは現像代という費用がかかってるんだけど、デジカメの場合はメモリに記録するだけなので、実害はゼロ。失敗を気にせず撮ればいいのがほんと気楽だなあ。
[01/10 02:07:01] 追記。
デジカメと散歩するのは、お金もかからず、ウォーキングにもなって健康にも良い、ので還暦老人には良い趣味だわ。このへんもあとでホームページ On Golden Pond にページを作ろう
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
epubcheck が githubに引っ越ししていた
最近epubcheck のバージョンとか確認してなかったなあ、と見に行ったら、code.google.com から移転。
今、最新版は https://github.com/IDPF/epubcheck こちらでリリースしている。
以下は、ここ『ひまつぶし雑記帖』でのお問い合わせ「エラー」について。
去年10月下旬にこの雑記帖に問い合わせフォームを設置したところ、ポツポツ問い合わせをいただけるようになってきた。
「エラーでうまくできない」
EPUB3::かんたん電子書籍作成 はEPUBファイルに梱包するために、一時ファイル・一時ディレクトリを作って作業している（サーバーの容量のこともあるので、一時ファイル類は梱包後に削除している）
ファイルの入出力というやつで、処理は重い。わたしの契約しているレンタルサーバーのプランがショボイせいもあって、大きなテキストファイルや、小さなファイルでも小見出しがたくさんある＝ファイル数が多いコンテンツは、セッション切れを起こすことがある。
これはお手上げなので、 ローカル版かんたん電子書籍作成 か（ただ、ローカル版はコマンドラインでの作業、多少ハードルが高いので）実績もあるWEBサービスの でんでんコンバーター をご案内している。
「EPUBファイルを作った後、Sigilなどで編集したらうまくいかない」
EPUBCheckでエラーを確認して潰していけば、たぶん解決する。でも、メールで話をうかがうと、EPUBCheckのハードルが高い。
インストーラーがあるわけでもないし
・WINDOWSはJAVAのインストール・PATHの設定なんてことまで必要。
・Macもzipファイルをダウンロードしたはいいけどこれってどうするの？
・ターミナル、コマンドプロンプトを使ってコマンドラインにタイプすることになる。
ということで、オススメのEPUBCheckの紹介・解説・使い方ページ。
WINDOWS版
「epubcheckのラクな動かし方 for Windows 7」 ( @ryou_takano )
EPUBCheckの解説とMacアプリ紹介
「うわっ…あんたのEPUB、ダメすぎ…？ 検証とその対処」 ( @lost_and_found )
「k△△では登録できるのにi○○（電子書籍ストア名）に登録できない」
ストアごとで素材などのレギュレーションが違うので、ユーザーページなどで公開されているガイドラインPDFを確認してくださいと。
…でもなあ、たとえば画像にしても、画素数とかファイルサイズとか解像度とかファイル形式とか、そんなもん知らんがな、というのが正直なところ。EPUBでValidなものを作ったんだから、それ以外のところはストア側である程度は吸収して欲しい。
・kindleは登録時にコンバートされてそれっぽくなる（そのかわり画質は気にしない前提）
・ibookstoreはエラーで弾かれて登録できない（エラーメッセージを見て自己解決しろよ前提）
お問い合わせのほとんどがこの３つのケース。でも、それだけっちゃそれだけのこと。
EPUBのおかげで（策定・運営しているひとたちに感謝 https://idpf.org ）ツールやアプリも揃ってるので、電子書籍を作ること自体は簡単になっている。
上記したエラーも、面倒くさいだけで難しいことじゃない。ひとつずつ・一カ所ずつ試行錯誤すれば解決できるのでめげず挫けず。
タイトル数が増えて市場が膨らんで一般化して、メシのタネのひとつになってくれるととてもうれしい。
↓ちなみに、ツールもアプリもない状態でEPUBファイルを作る艱難辛苦（参考になります）
「エラーメッセージから学ぶ電子書籍EPUB - 最初の一歩」 （ @merborne ）
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
macでemacsとskk
昨日久しぶりにmacを立ち上げて、しばらくmacとおつきあい。とりあえずまともなエディタがないことには話にならないんで、評判を見ながら、いくつか試してみたところ、どうもしっくりこない。しかたないんで、Tiger版で動くCarbon Emacsをインストール。普段使いのドットファイルをもってきて、馴染みのキーバインド。テキスト処理限定ならmac miniも使いものになりそう、かな。
ついでにskkもインストール。こりゃスゲー。windowsでskkはちょっと使いづらくて、結局xyzzy上でしか使ってないんだけど、macならすんなりどのアプリでも使えるぞ。
仕事がらみで、なにか面白いものがみつからないかとネット徘徊するんだけど。
今年はリアルタイムweb元年、とか言われてもなあ。オープンが大前提なので、囲いこみたいショップサイトと馴染まないような気もするし。macの側から眺めればナニかあるかな、と思いつつ。NARUTOも中忍試験までだったら傑作だったなぁ、とアニメを見てぼーっと過す連休でありマス。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
モレスキン
いやもう去年末の年賀状ショックの反省からだ。書き順すら覚束ない阿呆さ加減に我ながら呆れた。
なので、今年はzaurusはちょっとやめて、手帳に手書きで字を書く。それも丁寧に書くことを心がけてみようかと。三日坊主で終わらなければ。
モレスキンは、タテ開きのラージサイズを持ってるんだけど、持ち歩きにするにはでかすぎる。手帳はタテ開き（レポーター）と決めてこだわってきたものの、タテ開きの場合、ほとんど片面（下側）しか使ってないので、もったいない。モレスキンは安いものでもない。量をこなすにはノーマルタイプで両面使ったほうが経済的にも効率的。というセコイ理由から今回はポケットサイズノーマルタイプのものを購入。
他の手帳もないわけじゃないけど、モレスキンは紙が優しくていいし、ハードカバーはホールディングがしっかりできるので、書きやすい。
せめて自分が呆れない程度の字になるまでは手帳に手書きをガンバル、かな。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
まだまだこれからだ。
ますますへろへろのグロッキー状態となる。いやもうスタイルシートの微調整は気力体力の消耗戦でうんざり。
まだまだこれからIE6対策を埋め込まにゃならん。しばらく休みも取れそうにない。初老目前のよれよれの身体にはキツイぜ、パンク寸前。
んで。ウチの読書SNSのリニューアルも。HOME画面で今まであまり使ってなかったテーブルを使うようにしたところ、レスポンスががっくり低下。こりゃ仕事の方のサイトと同じく速度をなんとかしないと、と気が重くなってた。ふと見るとテーブルのいくつかにindexをつけてない。まあ「お守り」程度だろうけど、とjoinのキーにしてるカラムにindexをつけてみたら、体感できるほど劇的に速くなってびっくり。…ていうか、常識なんだろうな。
prototype.jsを入れたことだしついでに scriptaculousも。ドラッグできるコンテナが欲しかったので試してみようと。
最初、perlのスクリプトのミスで同じidを複数、一枚のhtmlに書き出していて、まったくうまく動かなかったのは内緒だ。another lint にhtmlを投げて気づくまで小一時間もかかったのはさらに内緒だ。
それはともかく、簡単な、それこそ数行でドラッグのできるコンテナが書けるのでらくちんだ…けど、これはけっこう重いかも。ドラッグ中、コンテナが半透明になる効果なんていらないからもっと軽くならんもんか。そもそも protptype.js と合わせると200K近くにもなるし、読みこむのも大変じゃないか。うーん、どうすべか。
本棚を見ていてその場で気楽に手に取ってみる、という感じにするには、ドラッガブルなコンテナがもってこいだしなあ。
まだMy本棚のレイアウトや細工を考えなきゃいけないんだけど、こんな時間に電車の中でこうやってネットしてるようじゃ時間が作れないわな。しょぼ。
[01/10 01:51:46]
思いつきで、dragdrop.jsの中を覗いて。
starteffect: function(element) {
と
endeffect: function(element) {
の中のopacityを1にしてfrom、toを取ってみたら、もさもさ重かったdragが嘘みたいにシャキシャキ動くようになった。これなら使いものになるぞ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
utf8移行と自分メモその２
で、 趣味は読書SNS は、utf8環境となった、のかな。今まで全部eucだったんで、実際どんなところに影響するのかまだ把握できてない。jisにsjisにeucにutf8に、と。４つも違う文字コードがあるのっておかしいんじゃね。と語尾をちょっと上げてみる。utfに収斂されていく勢い、と思ってもどこかのベンダーが妙な拡張してまた違うコードが出てきたりして。
てのはともかく。
今さらだけど perl5.8は。
出入りするデータはただのバイト列として扱う。utf8を扱うにはutf8フラグを立ててperlにこれはutf8として扱ってね、と教える必要がある。encoding とか use utf8 なんかがフラグ立てに使われるらしい。
今後推奨されるのはスクリプトをunicodeで書いて use utf8 する書き方だそうだ。そうするとスクリプト内の文字列には utf8フラグがつくのでなにかと便利、なのかな。
わたしが混乱したところ。
文字コードとしてのutf8とperlのutf8フラグは「また別」。
postgresqlから取り出したばかりのutf8の文字「根性」とスクリプト内のutf8フラグの立ったutf8文字列「根性」をそのまま比較しても意図した通りにはならない
取れたての「根性」 != スクリプト内の「根性」
となる。取れたての「根性」にはutf8フラグが足りないのだ。
Encode::decode（'utf8',「根性」）などと「根性」にutf8フラグをつけてやれば
「根性」==「根性」
となる。それじゃせっかくだしprintしてみるか、と「根性」を出すと wide char うんぬんと脅される。utf8フラグのついた文字列を表に出すとケチをつけられるのだ。
Encode::encode（'utf8',「根性」）とやって今度はutf8フラグを落としてやると警告は出なくなる。
勘違いしてたんだけど、utf8フラグというのはperlの内部のフラグ。
これをくっつけて出力するわけではない。
リダイレクトすれば普通に「文字コード」utf8で書き込まれるだけ。データベースへのinsertも同じこと。
Encodeのdecodeとencodeてのは。
「jis、sjis、euc、utf8」で書かれた文字列にutf8フラグをつけるのがdecode（その文字列がどのコードで書かれているのか教えてutf8フラグをつける）
utf8フラグがついてしまえば自由自在でごにょごにょ。その後表に出すような時にエクセルで読むからシフトJISでお願いと言われたらencodeで「jis、sjis、、euc、utf8」に変換する。この時utf8フラグも落とすので上のwide char うんぬんの警告は出ない。
decodeでutf8フラグをつけて、内部処理が終わったらencodeでutf8フラグを落としましょう、ということかな。
unicodeで書かれたスクリプトにutf8フラグをつけると変数名に「日本語」が使えたりする。
use utf8
my $気合=10：
while（$気合--）{
print Encode::encode（'utf8','喝'）;
}
喝喝喝喝喝喝喝喝喝喝
となる。スクリプトがわかりやすいぞ。
my $除夜の鐘=108;
my $鐘の音='ゴーン';
my $おやじギャグ='カルロス';
というのを見るだけでなにをしようとしてるのか分かるでしょ。
て、ネタを続けるのはうるさい、な。
postgresqlからselectなりで読み込んだらdecodeする必要がある（全部が全部というわけじゃないけど）。スクリプトのあちこちに散らばるselectを探していちいちdecodeなんちゃらと書き込むのは勘弁してほしい。ので検索してみると、decode encode のための wrapperを自前で作るひともいたけど、perl DBI DBD-Pgと postgreql だと connectしたら
dbh->{pg_enable_utf8}=1
で text と varchar のフィールドから取り出すものに関してutf8フラグをつけてくれる。ありがたい話だ。
今までのスクリプトをほとんどそのまま使える。ただ、wide char うんぬんの警告がうるさいこともあるんで、utf8::is_utf8（文字列） でutf8フラグがついてるかどうかをチェックするようにした。
cgiのformでの文字コードの扱いでもひっかかる。
いやutf8にしたいんだけど、と。
文字コードを変換するためにEncode::encodeを使うにはEncode::decodeでutf8フラグをつけてやる必要がある。ところがdecodeにはその文字列がどの文字コードで書かれているか教えてやる必要がある。
冒頭に書いたように流れてくるコードはjisだなんだで４種類。どのコードなのかわからないので推測するしかない。文字どおりGuessというのがあるんだけど、試しに「アイウエオ」とだけかいたファイルをeuc、sjis、jisの３種類用意して試したところ'shiftsiji or euc'というエラーで死ぬ。ネットで見てると、Guessはできるだけつかわないでね、と。弱ったなあと思いつつ駄目元でJcode.pmを同じファイルに使ってみたところちゃんと判定するじゃありませんか。…？？？。Encode.pmのwrapperになってるはずなので、結果は同じ（判定に失敗）と思ってた。
ここはありがたくJcode.pmを使わせていただくことに。
標準入力から受け取ったら、
Jcode::convert（$str,'utf8'）
と文字コードをutf8に。（互換のために参照渡しでもいいけど、参照渡しにする必要はないっぽい）多分文字コードを変える時にutf8フラグを落とすので、Jcodeで文字コードを変えたら
Encode::decode（'utf8',文字）と、utf8フラグをつけてあげる。
もしかするとperlIOで上記の手間は不要かもしれないなぁ。
んで、urlエンコードする場合はutf8フラグを落としてやらないと、エンコードされす、日本語なんかがそのまま流れることになるので要注意。
昨日に続いて長文連載。どうせ忘れるに決まってるから、こうやってあちこちに自分メモ、だ。
こっちのページもutf8に移行するかなぁ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
