Quantcast
Channel: \ay diary
Viewing all 174 articles
Browse latest View live

2011年のまとめ

$
0
0

本年もお世話になりました。来年もよろしくお願いします。

以下、ぐだぐだととりとめなく。自分用に。

今年一年をふりかえってみたところ、8月の写真がまったくなかった。flickrにアップロードしていない写真すらほとんどなかった。7月と9月はそれでも数枚あり、10月以降はいくらか写真が残っていた。7月あたりから外出していなかったのを実感した。

街路樹 横浜アイランドタワー 大通り公園 みなとみらい
人も車もいないね たたずむペンギン 村上のあんみつ  
大通り公園 イスが壊れた 元町オープン前後 雪だるま飛んだ

今年は仕事でもプライベートでも本当にあわただしかった。忙しいときとそうでないときの差が大きかった上に、忙しくなる時期をうまく予見できず実際の仕事量よりも疲労をためこんでしまった。また、浅浮き深沈みを何度か繰り返してしまい、どーんと落ち込んで無気力に陥いった。その度に迷惑をかけてしまったり、頼りまくったり、した。お世話になりっぱなしの一年だった。

今年、新たにやりたいと考えていたことはおおむねできなかった。そのうちの一つについて、なんとかとっかかりだけでもつけようと、この時期になって気力をしぼり出そうとしているような状況。来年は、と考えるのも少々つらい。

でも来年は、というよりできるだけ早い時期にあたりをつけて、その後のことを具体的に考えられるようにしようと考えている。


CAFE☆STAR → atelier 4fuku + cafe

$
0
0

CAFE☆STARが2月20日で閉店。3月末にatelier 4fuku + cafeとして新たにオープンとのこと。(ソース)

今なら36%オフな「徳丸本」PDF版を買った

$
0
0

「体系的に学ぶ 安全なWebアプリケーションの作り方」のDRMなしのPDF版が10/17までお安くなっているということで、紙版を持っていたのだけど購入した。

PDF版も買ったのは、なんせ紙版はでかくて重いから。ボリュームたっぷりなので検索できるのはうれしいし。紙版を買うタイミングでPDF版もあれば(別に安くなくても)PDF版を買っただろうと思う。もちろん今と同じくDRMなし、つまり特定デバイスしばりなしならば、という条件は付けたろうけど。

ところで、この本を手にすべきかどうか迷っている人は、まずこの本の目次なり紹介なりに目を通してみて、その上で「これは読まなくてよい」と確信できないならば読んだほうがよいと思う。(あ、もちろん、このテーマに興味があるとか業務で関わっているとかというのが前提だけど。)

これから買うなら、PDFで「読書」する環境をすでに整えている人はPDF版がお得だろう。特に今は、ってまあ言うまでもないけど。他方、紙以外での読書になじみがなく、かつ、通読したいという場合にはもしかすると紙のほうが扱いやすいかもしれない。

やはりいったりきたりしながら読み進めるときは紙のほうがまだ楽かな。指三本くらいはさんでたりとかできるし。もっとも、この本を読むときにそんなに指をはさんでおかなければならないかというと、そうでもないんじゃないかなとも思うけど。

Web系の開発を独学する人に: RailsによるアジャイルWebアプリケーション開発 第4版

$
0
0

レビューに参加させてもらったので発売よりも少し早く読むことができた。と、いうものの、仕事のスケジュールがかなりきびしい時期だったので部分的に。というよりもほんの少しだけ、といった程度の協力になってしまった。

それはともかく。レビューするとなると、普段ならざっくり飛ばし読みにしてしまうところまでじっくり読むことになる。そういうところも含めて読んでみていてふと思った。この本はwebアプリケーションの「開発」を始めたいという人のための入口にちょうどよいのではないか。

プログラミングの入門書でもweb系の題材が出てくることはおそらく珍しくないだろうと思う。ただ、そういった本の目的は、コードの一行一行を理解させること。だから、と言ってしまうと短絡的すぎるかもしれないが、多くはアプリケーションとして書いたことがきちんと動くというところが到達点になるのだと思う。

この本では、コードの一行一行の理解というところに焦点をあてていない。あ、これは前半のチュートリアル的なパートは、ということなのだけど、この部分においては、具体的なコードの細部について「きっとこのように動かすためのコードだろう」というあたりを付けられれば十分、それよりももう少し広い範囲を理解しようといった雰囲気がある。

本書は430ページほどあって、その半分ちょっとの240ページほどがチュートリアルと、本書を読みこなす上で必要となる最小限のRubyの解説に振り向けられている。そして、その前半部分のおよそ1/3あたりまで(Ruby自体の解説を除けば)コードらしいコードが出てこない。Railsのお約束に従ってアプリケーションを構築するばかりである。そして最初に書くコードはテストだった。

test "product attributes must not be empty" do
  product = Product.new
  assert product.invalid?
  assert product.errors[:title].any?
  assert product.errors[:description].any?
  assert product.errors[:price].any?
  assert product.errors[:image_url].any?
end

あなたが作るアプリケーションは、あなたの手を離れた環境で動作する。コードが単体で動くわけではなく、フロントエンドのHTTPサーバとか、CSSなどの外部ファイル群とか、キャッシュとか、そういった関連の中にあって運用される。そんな中で、Railsを使ってする開発というのは、どんなもので、どういうふうにすればいいのか。それを学ぼうとするのがこの本なのではないか。

このような印象となったのは、この本で扱っているRailsのバージョンが3.1だという点にもよるところがあると思う。Railsが注目されだした当初、フルスタックであるという言い方をされることがあった。その面はより実務的に進んできているように思う。その分、旧来からのRailsユーザの一部(私のような時々Rails者)にはしばしば戸惑いを感じたりもするのだが、それらを拾い集めていくと、最先端ではないにしても、また詳細に理解できるとまではいかないにしても、実際のサービスの場面で必要とされる、あなたの目の前のコード以外の様々なものの様子をとらえることができる——んじゃないかな。と、そんなふうに思った。

オーム社eStore(β)
PDF版 2,560円(+税)
PDF版+紙版 4,800円(+税)

amazon.co.jp
【送料無料】RailsによるアジャイルWebア...

【送料無料】RailsによるアジャイルWebア…
価格:3,360円(税込、送料別)

Origamiを使ってPDF中の画像を調整する

$
0
0

ScanSnapで検索可能なPDFにしたとする。このとき、せっかくだから検索可能なまま画像の調整をしたくなる。だが、その種のことができるツールというのをどうもうまく探せない。いかにも何かありそうなものなのだけど。

それなら作ればよい。PDFを扱うライブラリはたくさんある。最終的にできるかどうかはともかくとして、ちょっと試すくらいならやりようがあるだろう。

そう思ってあれこれやっていたのが2010年12月くらいのこと。その当時の環境ではこれが意外にめんどうで途中までやりかけたものの放ってしまっていた。その時使っていたライブラリのバージョンが上がってリリース版が出たというのを先日知って、もう一度やってみることにした。すると意外にもこれが結構簡単にできてしまった。

当時でもPDFを扱うライブラリは簡単にいくつも見付かった。代表的なのはPDF::WriterやPrawn。その他のいくつかのライブラリとともに試してみた。しかし、それらにはPDFファイルを新たに作成する機能はいろいろとあるものの、既存のPDFファイルを改変する機能がほとんどなかった。

しかたないのでPDFファイルを直接編集するものを作り始めたのだが、すぐにPDFの自由さ知ることになる。というのはScanSnapが出力するPDF、Acrobatで編集したPDF、Preview.appで編集したPDFと、みな構造が異なっていたのである。これではまともにPDFを解析しなければ対応しきれない。

そうして改めて探し直して見付けたのが、開発中だったOrigamiである。

現在までにバージョン1.0がリリースされ、gemでのインストールも可能となっている。現時点でのバージョンは1.2.3。2010年末の時点ではドキュメントもサンプルもほとんどなかったが、このバージョンにはいくつかの有用なツールが含まれている。手軽にPDFをいじりたいというときにはすぐに手本にできるものが揃っているといえるだろう。

  • pdf2graph - Generates a Graphviz DOT or GraphML file out of a PDF document
  • pdf2pdfa - Enforces a document to be rendered as PDF/A
  • pdfcop - PDF document filtering engine using Origami
  • pdfdecompress - Uncompresses all binary streams of a PDF document
  • pdfencrypt/pdfdecrypt - Encrypts/Decrypts a PDF document (Supports RC4 40 to 128 bits, AES128, AES256)
  • pdfextract - Extracts various data out of a document (streams, scripts, images, fonts, metadata, attachments)
  • pdfmetadata - Prints out the metadata contained in a PDF document
  • pdfsh - OrigamiによるPDF操作にカスタマイズしたirb
  • pdfwalker - PDFの構造を表示するGUIツール(Ruby/Gtk2)

このうちのpdfextractを参考にして、PDFに含まれる画像をImageMagickで編集するスクリプトを作ってみた。PDFの仕様は公開されているものを拾い読みした程度なので適切ではない部分があるかもしれないが、evinceやPreview.app、i文庫で参照できることを確認した。

動作確認には、紙が薄いことがよく知られている角川スニーカー文庫をスキャンしたものを使ったた。同文庫は紙のまま読んでいてもよく透ける。スキャン結果もそれに応じたものとなる。下は生成されたPDFと処理したPDFをi文庫で参照したときのスクリーンショットである。

処理前 処理後

このように文章ページではスッキリしたものとなった。ところが、ちょうどこの裏のページにある挿絵では以下の切り抜きのようにやりすぎてしまっている。なかなか難しい。(なお、動作確認に使ったのは以前紹介(?)したことのある「子ひつじは迷わない 泳ぐひつじが3びき」の15〜17ページ。)

処理前 処理後

手元では挿絵ページやカラーページはエクセレントで、それ以外はスーパーファインでスキャンして、Preview.appでマージしている。よってdpiをキーに調整内容を変えればもう少しよい結果を得られるだろう。また、ページの内容に応じて処理を変えるようにしたり、ページを指定しての画像差し替えを可能にすればツールとして実用的になるかもしれない。ただ、そのためにはページ構造を扱えるよう作り込まなければならない。

ともあれ、2010年当時には、こういう単純なコードだとメモリをどんどん食いつぶしていってくれたのだが、リリース版で改善されたのか、Ruby 1.9.3を使っているからなのか、200ページちょっとの文庫本を特に問題なく処理できた。なかなかよい。

2011年のまとめ

$
0
0

本年もお世話になりました。来年もよろしくお願いします。

以下、ぐだぐだととりとめなく。自分用に。

今年一年をふりかえってみたところ、8月の写真がまったくなかった。flickrにアップロードしていない写真すらほとんどなかった。7月と9月はそれでも数枚あり、10月以降はいくらか写真が残っていた。7月あたりから外出していなかったのを実感した。

街路樹 横浜アイランドタワー 大通り公園 みなとみらい
人も車もいないね たたずむペンギン 村上のあんみつ  
大通り公園 イスが壊れた 元町オープン前後 雪だるま飛んだ

今年は仕事でもプライベートでも本当にあわただしかった。忙しいときとそうでないときの差が大きかった上に、忙しくなる時期をうまく予見できず実際の仕事量よりも疲労をためこんでしまった。また、浅浮き深沈みを何度か繰り返してしまい、どーんと落ち込んで無気力に陥いった。その度に迷惑をかけてしまったり、頼りまくったり、した。お世話になりっぱなしの一年だった。

今年、新たにやりたいと考えていたことはおおむねできなかった。そのうちの一つについて、なんとかとっかかりだけでもつけようと、この時期になって気力をしぼり出そうとしているような状況。来年は、と考えるのも少々つらい。

でも来年は、というよりできるだけ早い時期にあたりをつけて、その後のことを具体的に考えられるようにしよう。

CAFE☆STAR → atelier 4fuku + cafe

$
0
0

CAFE☆STARが2月20日で閉店。3月末にatelier 4fuku + cafeとして新たにオープンとのこと。(ソース)

TypoからOctopressに移行した

$
0
0

Typoのバージョンが5.xや6.xになってからというもの、ところどころで不審な動きをすることがあった。そこで、Jekyll上に構築されたOctopressに移行した。

今回の作業では、これまでにいただいたコメントを移行できなかった。いきなり消えてしまうことになってしまって、申しわけないです。

ところで、不審というのは、たとえば、何かのタイミングでパスワード入力を求める表示になってしまうこと。キャッシュがおかしくなること。また、タグに英数字以外を使おうとすると手間がかかること(「”」でくくるだけのことなのだが、再編集をしようとすると「”」なしの編集画面となってかなりめんどくさい)。ほかいろいろ。

だましだまし使ってきたのだが、追及するにはコードをしっかり読まないとならない。また、タグの件からしてもわかる通り、マルチバイトをきちんと扱えるようになる感じがしない。(以前は素通しだったのだが、最近のバージョンで排除するような挙動が見られるようになった。)

移行に際してはrefinerycms、lokka、enki、など、blogエンジンやCMSを試した上でOctopressにした。Octopress/JekyllはHTMLを静的に生成するツールであり、CMSなどとは異なる。手書きからtDiaryになり、さらにTypoに移行してからのOctopressなので、ある意味一周したことになる。

Octopressの始め方についてはこちらが参考になる。

Typoを含む他システムからのデータ移行はJekyll側で手順が用意されている。が、この手順に従うとTypoのテキストフィルタを通らない出力になってしまう。そのため、Typo側でOctopress/Jekyll用のテキストファイルを出力するコードを書いて対処した。TypoのテキストフィルタについてはLiquid書式に変換するなどして対処するやり方もあったかもしれないが、めんどうなのでTypo側でHTMLに展開したものを取り込むことにした。

設定をあれこれして以前と同じような内容にできたのではないかと思う。変だったらそっと教えてください。ぼちぼち直していきます。


喫茶コマドリ

$
0
0

気になるお店がまた一つ → 喫茶コマドリ

白楽あたりには行ってみたいお店がいくつかある。喫茶コマドリで使っているというTERA COFFEEもその一つ。時間とってまわりたいな。

まだあった1.9.3-p0化にともなうトラブル

$
0
0

Ruby 1.9.3に移行したところ不正なマルチバイトシーケンスであるという例外が発生するようになった。

というのはtypoのバグを放置していた自分のせいである。

最近どうだったのかは分からないが、以前のtypoはtrackbackなどの処理で長い文字列をマルチバイトシーケンスを無視して切り詰めていた。このため不正なマルチバイトシーケンスが生じることがあり、それらの文字列はそのままDBに入れられていた。こうした状況に気付かないままRuby 1.9系に移行してしまったため、特定のページを表示させようとすると不正なシーケンスであるという例外が発生する結果となる。

具体的には"あいうえ\xE3…"といったもので、エンコーディングはUTF-8。不正部分を取り除いて保存し直してやればよいのだが意外と手間取った。

Rubyの多言語機能を使えば、不正なマルチバイトシーケンスを無視してエンコーディング変換させることができる。これにより正しいシーケンスのみを残した文字列を生成できるのではないかと考えた。だが、これは単純には実行できなかった。次のようになる。

str = "あいうえ\xE3..."
str.valid_encoding? #=> false
str.encode('UTF-8', 'UTF-8', :invalid => :replace, :replace => '') #=> "あいうえ\xE3..."

変換前のエンコーディングがUTF-8なのだが、UTF-8→UTF-8では変換が行われないということだ。次のように一度他のエンコーディングに変換すると期待通りとなる。

str.encode('EUC-JP', :invalid => :replace, :replace => '').encode('UTF-8') #=> "あいうえ..."

今回のケースでは、日本語であることが分かっており、まずまずUTF-8→EUC-JP→UTF-8でも問題なかろうという予想もついていた。件数も少ないし、これでもよいといえばよいのだが——やっぱりちょっと手を抜きすぎているように思える。

そこで、同じやり方をIconvで行うとどうなるかを試してみた。

require 'iconv'
Iconv.iconv('UTF-8//IGNORE', 'UTF-8', str).first #=> "あいうえ..."

こちらは期待通りの結果が得られた。Iconvについては「iconv will be deprecated in the future, use String#encode instead」とサポート終了が予告されているのだが、このようなケースではまだ使いでがある。(あまり一般的なケースではないだろうが。)

次に正規表現を使うことを考えた。鬼車のドキュメントによれば[[:print:]]により正しい文字にマッチさせられるはずだ。

str.sub(/\A([\s[:print:]]+).*/, '\1...') #=> ArgumentError: invalid byte sequence in UTF-8

残念。入力に不正なシーケンスが含まれていると扱えないようだ。だが、これに関していろいろ試しているうちに次の動作に気付いた。

str.encode('UTF-8','UTF-8').sub(/\A([\s[:print:]]+).*/, '\1...') #=> "あいうえ..."

変換元、変換先に同じエンコーディングを指定してencodeすることでvalid_encoding? #=> trueとなる。(少なくとも今回のケースでは。)ちなみに変換元を指定しないと「ArgumentError: invalid byte sequence in UTF-8」が発生する。

とまあ、そんなような経緯の後、Iconvを使ってエラー状態から復帰することにした。

追記(一夜明けて)

EUC-JPではなくてUTF-16あたりを介せばよかっただけではないかと今になって気付いた。

"あいうえ\xE3...".encode("UTF-16", :invalid => :replace, :replace => '').encode("UTF-8") #=> "あいうえ..."

それにしてももう少し簡単にできないだろうか。

ScanSnapした画像のレベル調整

$
0
0

昨日の記事はブックマークのつもり書き始めた。しかし脱線していって自分でやってみたことのほうが多くなってしまったので記事を分けることにした。

きっかけは以下のページ。

Desire for wealth : ScanSnap の自炊 pdf を自動で美白化(レベル補正)する

convert -density 150x150 -type GrayScale \
  -linear-stretch 10%x35% \
  -geometry 512x -compress jpeg -quality 80 a.pdf b.pdf

このページや他のページで解説されているのはconvert-linear-stretchの使い方である。だが、似たようなオプションに-levelというのがあって、これらの関係がよくわからなかっい。そこでいろいろと試してみた。

結果を言うと-levelもこの目的では同じように利用できる。

どちらもまっ黒、まっ白にする水準を指定して画像加工を行う。ただしパラメータの指定には違いがある。-levelは入力画像の明度で指定するのに対し、-linear-stretchでは入力画像の明度に対するヒストグラムの値で指定する。(……ということで合っているだろうか?)

明度の値は0〜255(0〜100%)である。たとえば0〜51(0〜20%)を黒く、230〜255(90〜100%)を白くしてしまおうと考えたとする。

-levelを使うなら-level 20%,90%のようにパラメータを指定する。このような方針に対して-linear-stretchを使うのは難しいが、あえて使うなら明るさレベルが二つの範囲に収まる画素数をカウントして指定してやることになる。

たとえば、下の「元画像」とした画像には明るさが0〜51の範囲の画素が676、230〜255の範囲の画素が106,169ある。よって-linear-stretch 676,106169とすれば-level 20%,90%とおおむね同じ結果が得られる。

与えたパラメータの値から分かる通り、-levelは数直線上の位置を指定するのに対して-linear-stretchは白黒それぞれの端からの範囲を指定するという違いもある。これらをGimpのレベル調整との対応させると、三つならんだ「▲」の位置を指定するのが-levelであり、ヒストグラム中の面積(図中で赤くした部分と青くした部分)を指定するのが-linear-stretchである。

元画像
-level
-linear-stretch

なお、ここで示したヒストグラムの生成もconvertで行った。元画像からのヒストグラムの抽出は次の通り。

convert orig.jpg -fromat %c histogram:info:-

そしてレベル補正後のヒストグラムのグラフ生成は次の通り。せっかくなので出力ファイル名の展開を使ってみた。

convert orig.jpg level.jpg linear-stretch.jpg \
  -set filename:bn %t \
  'histogram:%[filename:bn]_histogram.jpg'

ヒストグラムについてはこちらを参照した。

ここでは例示のためにあえて甘めの白飛ばしにしたが、レベル補正だけでもconvert -level 20%,80%くらいにすると(この画像の場合には)かなり読みやすくなる。ついでなので以前作った、というより作りかけのまま放置しているGimpスクリプトで加工した結果もならべておく。

-level 20%,80%
Gimpスクリプトでレベル補正
Gimpスクリプトでレベル補正のほかいろいろ

ところで、大本の一ページまるまるの画像は4,183×6,154ピクセルある。上の例で示しているのはそこから切り抜いて加工し、その結果を約1/6に縮小したものである。大本画像を同じ要領で縮小すると684×1,006ピクセルとなり、これはiPad1/2を横向きにして見る場合のサイズとほぼ同じ。そう考えると、レベル補正だけでもわりあいいいところまでいけそうな気がする。

よく見るとGimpでいろいろやったもののほうがいくらかきれいなのだけど、その差以上の処理時間の違いがある。我が家のPCで大本画像を処理しようとすると数十秒かかってしまい――ちょっと使いものにならない。Gimpでがんばるのもなかなか楽しいのだが、別の方法を考えたほうがよいのかなという気がしている。

ここで大切なお話: 上の例でとりあげているのはまんがタイムきららミラクで連載中の柊ゆたか著「Good night! Angel」第一話の一コマ(ミラク創刊号75ページ)。きらら系他誌とはちょっと毛色が違っていて、この作品をはじめ他作品も含めて面白い。

どこがどう違うのかというのは難しいのだけど、物語が重視されている作品が多いこと、だろうか。

日々の中の一日をちょこちょことつまんで全体的な物語を構成するのは他4コマ作品でもみかける。ミラクではもう少し長めにとられることが目立つように感じる。点を連ねるのに対し、線とまではいかないかもしれないけれど線分ではあるかな、というところ。

それから絵の書き込みが他誌よりも細かい気がする。みなさん妙に気合いが入っているというか。読み返していて「おっ」というところをみつけることがしばしば。

まあ、うまく言えないんだけど、ともかくおすすめ。


楽天市場でもっと探す
7ネットショッピングで探す

外に出てひきこもった一日

$
0
0

家の中は誘惑が多いので。そんな気分になってきたので久しぶりに外出することにした。スターバックスでお仕事。

日曜だということもあってか、全体的にさわがしくて気が散らなくてよかった。電源があるかどうかは確認しなかったけど、思いのほかはかどったので電池切れになる前に一段落つけることができた。

いや、実のところ、もう少しで一段落というところで、きつーい香水をこれでもかってほどふりかけてきたらしき中年女性が入ってきて、しばらく気付かなかったのだけど、リアルに噎せかえるというのをやらかしてしまったのだった。もう少し、もう少し、と言いきかせながら息を止めぎみでcommit。一段落させた。

帰りについでに本屋に寄ったら気になる本が三点ばかり。

  • 鎌倉・横浜・湘南今昔歩く地図帖 - 古い地図や風景写真と今とを並べて紹介、解説しているという内容。ぱらぱらめくるだけでも楽しかった。今度鎌倉に行くときには買っていこうかな。
  • 日本人はなぜ日本のことを知らないのか - 帯に「ここが最古の国って知ってた?」というようなことが書いてあって気になった。前書きをざっとながめたところではあおるようなトーンでもなさそうな感じだった。
  • コーヒーもう一杯 - 小説。カフェを開業することになった女性の話、みたい。帰ってからずんずん気になってきて、中身をたしかめてから帰ればよかったなと今になって。
楽天ブックス
鎌倉・横浜・湘南今昔歩く地図帖
楽天ブックス
日本人はなぜ日本のことを知らないのか
楽天ブックス
コーヒーもう一杯
Amazon
Amazon
Amazon

帰りにちょっとだけぶらついてみた。ゆっくり歩く。二の酉が明日ということで準備をしているようだった。

空 関内の夕方 二の酉準備中

Octopress/Jekyllの実行時間をもう少しなんとかする

$
0
0

前回のとったプロファイルについて、Jekyllの内部で記事リスト(site.posts)に何度も何度もsortをかけているようなのが気にかかっていた(Jekyll::Site#site_payload)。しかしコードをもう少し読まなければ手を入れられるものか判断できなかったのでそのままにした。

今回はその部分にも手を入れてみた。改めてJekyll本体を読んでみたところ、sort済みの記事リストを使いまわしても問題ないように思えたので。

そのついでにPostListのコードをいくらかマシなものにしようとしてみた、のだが、これはマシになっているだろうか?

ともあれ、sortを呼び出す回数が減ったことで、もう少しだけ実行時間が短くなった。まずは前回の状態での実行結果:

87.50s user 7.78s system 99% cpu 1:35.31 total
88.26s user 8.07s system 99% cpu 1:36.35 total
87.93s user 7.95s system 99% cpu 1:35.90 total

新しいプラグインを使ったときの実行結果:

65.29s user 7.98s system 99% cpu 1:13.30 total
65.62s user 7.92s system 99% cpu 1:13.57 total
65.35s user 8.14s system 99% cpu 1:13.52 total

平均で1:35.83→1.13.46となり、前回の最終段階から約23.4%減となった。

コードはともかく改修内容は本体に取り込んでほしいところだけど、うーん、これではまだ難しいかなあ……。

jpeg画像のlossless回転

$
0
0

久しぶりにScanSnapしていると、どうしても部分的に歪んでしまうページが出た。上下逆にしてもダメ。横向きにすることでようやく回避できた。

実のところ、ある一ページだけで歪が出たわけではなく、ある本一冊の奇数ページすべてに歪が出ていた。紙に変なクセがついているわけでもないように見えるし、偶数ページには出てないしで、原因はよくわからない。

横向きでスキャンすると、画像を回転させなければならない。最初、Acrobatで奇数ページだけ回転というのができたなと思いやってみたのだが、そこから画像を抽出すると回転されていない横向き画像が出てきた。そりゃそうだ。

ImageMagickで処理しようとして、ふとlosslessで回転できないのかなと調べてみたところ、jpegtransというツールで可能なことが分かった。このツールは、jpegファイル中の圧縮データを直接扱っている。これに対してImageMagickのconvertでは一度デコードしてから処理をしているためlosslessではない。

だが、しかし。もう少し調べてみるとjpegtransおよび同種のツールでは問題が出るケースがあると述べられているのに気付いた。

Also note that lossless JPEG rotations have some limitations. Specifically it will roate the image but if partical blocks are present along the bottom or right edges, these will not be rotated!

However these commands are NOT recommended for general use, as they are limited to the block boundaries (8 or 16 bit) of the JPEG image. That is to say That is you can only crop, rotate, or drop-in at a JPEG compression cell level, not at the actual pixel level.

jpegでのデータ処理の際に8×8ピクセルのブロックを最小単位として扱う。block boundaryというのはこのことを指しているようだ。小さな画像を作って試してみた。

16×1620×20
元画像
convertで90度回転
jpegtransで90度回転

8×8で割り切れない20×20ピクセルの画像についてjpegtransではおかしな結果となっている。

convertがlosslessではないといっても高圧縮でなければパッと見て分かるような劣化は生じない。そういうわけで、一般的にはconvertを使っておくほうが無難だと言えるだろう。

Octopress/Jekyllの実行時間をなんとかする

$
0
0

Octopressに移行してさっそくつまづいた。HTML生成にうんと時間がかかる。どのくらいかかるかというと4分ちょっと。

本文がHTML(拡張子が.none)のファイルが2,188個、markdownファイルが1個。それとその他の記事以外のファイルが10個前後。あとはOctopressの標準的な構成のまま。

一つの記事を書いて、その変換結果を確認して、それから公開する。誤字の修正のようなちょっとした変更のたびに4分ちょっと待つのは辛い。最新の記事だと分かっているときならjekyllコマンドに--limit_posts=1を付けて実行すればある程度回避できなくはないが。

そういうわけで、多少なりとも改善できないものかと調べてみた。

まずはruby-profでざっとプロファイルをとってながめる。メソッド名や呼び出され方などからして、コードを読み込まなければならないところは大変そうなのでとりあえず外す。ロジックを見直さなければダメそうなところも同様に外す。それでも手を入れられそうなところがいくらか残った。

手を入れ始める前に、素の状態での実行時間を測っておく。簡単にtimeコマンドを使う。

242.56s user 7.95s system 100% cpu 4:10.51 total
242.12s user 8.05s system  99% cpu 4:10.53 total
246.98s user 8.13s system 100% cpu 4:15.11 total

平均で4:12.05。

まずは正規表現の生成に時間をとられているらしいRubyPants#educate_quotesとLiquid::Variable#initializeに手を入れていく。ただ、Liquidのほうは別プロダクトなので、ひとまずモンキーパッチで実装することにした。

いずれも正規表現を生成する//にオプションoを付けただけ。その効果は:

188.43s user 8.07s system 100% cpu 3:16.50 total
186.97s user 8.11s system  99% cpu 3:15.31 total
191.49s user 8.00s system  99% cpu 3:19.80 total

平均で3:17.20となり、ざっと20%ほど実行時間が短くなった。

もう一つ、こういう手の入れ方はちょっとどうかなーと思いつつ、もっと効果的なところがOctopressではなくJekyll::Siteの中にある。全記事を集めた配列を使って、その前後の記事を探している部分で、記事数が多くなると効率の悪さが目立ってくる。

Liquidと同様、モンキーパッチで実装してみた。ただ、この部分、もう少しコードを読み込んで、きちんと構造を理解してから手をつけたほうがよさそうだ。よって、以下のパッチは、ちょっとどうかなー、である。

ここに手を入れることにしたのはJekyll::Post#<=>の呼び出し回数がかなり多かいのに気付いたため。

<=>が使われるのはまずはsortだが、sortが使われている部分ちょっと手を入れるというわけにはいかないように見えた。(正確にはロジック見直しになりそうな感じの部分と、なんだか一見するとおかしなコードに見える部分とがあった。後者は手を入れられるかもしれないが、まだ手をつけていない。)

ただ、それ以上にArray#indexからの呼び出しのほうが割り合いが大きい。そこで<=>を使わせないように強引な手をとった。これには以下の二つを仮定している。

  • sortのときとは違って、オブジェクトの一致を見ればよいはずだ(==ではなくequal?で判定できるはずだ)
  • 問題の配列postsは、いったん記事を読み込んだら変更は行われないはずだ

結果は次のようになった。

87.51s user 8.01s system 99% cpu 1:35.53 total
87.31s user 8.19s system 99% cpu 1:35.52 total
88.71s user 8.00s system 99% cpu 1:36.73 total

平均で1:35.93。素の状態からすると60%強の短縮ができた。念のため生成されたHTMLを素の状態と、最後の状態とで比較して、その内容に違いがないことを確認した。


裏写りの少ないチャネルを選ぶ

$
0
0

ScanSnapのような両面を一度に読み取るスキャナを使っていると、まんが雑誌などで裏側の陰影が透けてしまうことがある。雑誌だけでなく、少年まんがや少女まんがでも同じように透けることが多い。

こういうのはあきらめが肝心だろうと思う。

ふり返ってみると、紙のまま読んでいるときでも裏写りしていることが少なくない。似たような状態を画像として見ると気になるのは、スキャン後のチェックをしているからのように思う。実際、通して読む段になると、チェック時には気になったはずのところをひっかかりなく読み進めていたりする。

とはいうものの、あまり手間をかけずにできることがあるならばとも思う。

多くのまんがは白・黒の二色で印刷されていて中間色はない。よって理想状態のヒストグラムでは両端に二本の線が立つことになる。ところが実際の印刷物には汚れ、折れなどの変形、インクのかすれ、紙そのものの凹凸があり、さらに印刷そのものの質の影響もある。それを読み取るスキャナには解像度の限界がある。そうしてヒストグラムには二つの山ができる。

そうしてみると、ヒストグラムの偏りが大きく、山が鋭く切り立っているほうがよりよい画像といえるのではないだろうか。そこで少し試してみた。

普段はグレースケールでスキャンしているのだが、間違えてカラーでスキャンしてしまった画像がある。その中から比較的はっきりと裏写りしているものを一つ選んだ。(こうした紙面の場合、裏写りがまったくない画像はほとんどない。)

ヒストグラム(RGB)を見ると、青か緑の山が赤よりも細身であることがわかる。通常のグレースケール化(明度)、赤チャネル、緑チャネル、青チャネルのそれぞれに対してレベル調整を行った。(gimpスクリプトによりいずれも同程度の調整結果となるようにした。)

白地の部分に違いはないが、トーンがかかった部分については青チャネル(右端)の程度がもっともよい。同じ紙面の他のページについても同様に確認してみたところ、やはり青チャネルの程度が他と比べてよいようだった。

黄ばみのある紙面についても同じように確認してみた。この例では赤チャネルがもっともよく、逆に青チャンネルが残念な結果となっている。(これは単行本であり裏写りはほとんどない。)

今回のお試しの結果からすると、裏写りがきついものや黄ばみのあるものについてはカラーでスキャンしておいたほうが後処理での調整をきかせやすいといえる。

ただし今回確認した範囲はたかだか数ページのみ。一部を切り出して比較するだけではなく、一冊まるごと、あるいは複数からある程度の量を処理して読み比べてみたほうがよいだろう。また、裏写りがそれほどきつくない場合には通常の明度からのグレースケールに対するレベル調整で十分な処理ができることも少なくない。

サンプルに使わせてもらったまんが

TEI OH-! - 庄司二号さん
まんがタイムきららミラク2012年3月号から (3〜5月号でゲスト掲載、現在発売中の6月号から連載開始)
楽天市場でミラクを探す
7ネットショッピングでミラクを探す

[ももいろシスターズ 2 (ジェッツコミックス) / ももせ たまみ]
ももいろシスターズ(2)
- ももせたまみさん

まんが雑誌の読み方

$
0
0
  1. アンケート用紙を切り離す
  2. 自由記入が求められる項目の要件を把握する
  3. ペンを用意する
  4. アンケートを書き込みながら読み進める
  5. 読み終える
  6. 投函する

好きなまんががちゃんと続いてくれるためにはやっておいたほうが良いのだなと、かなり今更なのだけど思うようになったので。いつもいつもでなくても「これだけは」という連載や読み切りがあったときには送ろうと思う。

ただまあイス取りゲームなんだよね。やっぱり。

Ruby 1.9.3-p0化にともなうトラブル

$
0
0

変に早起きしてしまったためか急にぽっかり時間があいてしまった。そこで、ずるずる先延ばしにしていたtypoのバージョンアップを行うことにした。

コードそのものはCapistranoでdeployできるようにしてある。でも、久しぶりのことなので念のためdeploy:update_codeなど試しておく。typo自体のテストも通してみる。いくつかfailしているが、ざっと見た上で、リリースされていることでもあるから問題ないのだろうということにした。順調。だったから。ここで、ふとRuby 1.9.3化もやってしまうかと考えたのだった。

Ruby Enterprise Edition 1.8.7-2011.03から1.9.3-p0へ。軽く考えていていたのだが、まあ実際のところ、全体的にはそう大変な作業ではなかったと思う。とはいえトラブルはあった。

最初のトラブルはRuby 1.9.3 & Passenger 3.0.9 で「Unexpected end-of-file detected」(ITS: Passenger Ruby)だった。まったく同じ状況になった。が、その分、同じ方法で回避できた。

ただ、こちらの環境はPassenger+Nginxであったため、Passengerの再インストールはNginxの再インストールにもつながり少々めんどうである。Passengerの修正を見てみたところ、ラッキーなことに、Ruby用の拡張ライブラリに対する変更だけであった。そこでこの変更を直接適用し、拡張ライブラリのみrebuildすることにした。(このことを忘れて後ではまるかもしれないが……。)

次のトラブルは文字エンコーディングに関するもの。ほとんど問題なかったのだが、管理画面のうちのサイドバーの設定の部分で例外が発生した。(サイドバーが消えさってしまったので、どうなっているか見ようとしたときに気付いた。)

ビューの中でエンコーディング非互換の例外が起きている。ビューの中にロジックがあるわけではなく、メソッド呼び出しがそのまま埋め込みになる部分だった。そのため何が起きているのか逆に把握し難い。ひとまずその場でforce_encodingして表示できるようにし、何がどのように混じっているのか見てみることにした。すると、typoのサイドバー用のレコードの一部がASCII-8BITになってしまっていること、文字化けが発生していることが分かった。

これらのレコードは1.8.7で運用していたときに保存されたものである。当然、記事データなども同じなのだが、そちらでは問題は発生していない。両者の違いはserializeされているかどうかにあり、つまりYAMLの挙動にもよるようだ。文字化けのほうは、YAML上の"\xE3\x81\x93"のような表現の解釈の違いによる。(この形式のYAMLデータがDBに保存されていた。)

YAMLの挙動を確認してみる。

Ruby 1.8.7
irb(main):001:0> YAML.load("--- \ntitle: \"\\xE3\\x81\\x93\"\n\n")
=> {"title"=>"\343\201\223"}
Ruby 1.9.3
irb(main):001:0> YAML.load("--- \ntitle: \"\\xE3\\x81\\x93\"\n\n")
=> {"title"=>"ã\u0081\u0093"}
Ruby 1.9.3 (YAML入力が!binary形式だった場合)
irb(main):001:0> YAML.load("--- \ntitle: !binary |\n  44GT\n\n")
=> {"title"=>"\xE3\x81\x93"}

問題が発生していることは確かなのだが、その場合でも、文字エンコーディングはUTF-8になる。これがASCII-8BITになってしまったのは、どこでどうしたからなのかよく分からない。はて。(!binary形式の場合、文字化けせず、ASCII-8BITになる。)

と、そうこうしているちに空き時間を使い切りそうになってしまい——結局、問題が起きたレコードがそれほど多くはなかったので、あらかじめとっておいたMySQLのダンプからコピー&ペーストにより上書き再設定を行った。

その後

もう少し調べてみようと思ったのだけど、二つの環境をいったりきたりが意外にめんどうで追求できていない。ただ、YAMLに関してはデータを移行できないケースがあることがわかった。

$ ruby1.8 -r yaml -ve 'YAML.dump("あいう", $stdout)'
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]
--- !binary |
44GC44GE44GG

(Ruby 1.9.2)
$ ruby1.8 -r yaml -e 'YAML.dump("あいう", $stdout)' | ruby -r yaml -ve 'p YAML.load($stdin)'
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]
"\xE3\x81\x82\xE3\x81\x84\xE3\x81\x86"

(Ruby 1.9.3)
$ ruby1.8 -r yaml -e 'YAML.dump("あいう", $stdout)' | ruby -r yaml -ve 'p YAML.load($stdin)'
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
/home/akira/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych.rb:154:in `parse': (<unknown>): couldn't parse YAML at line 3 column 0 (Psych::SyntaxError)
	from /home/akira/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych.rb:154:in `parse_stream'
	from /home/akira/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych.rb:125:in `parse'
	from /home/akira/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/psych.rb:112:in `load'
	from -e:1:in `<main>'

マルチバイトというか!binaryだとまずいみたい。また、!binaryであっても配列やハッシュの中にあれば例外にはならない。

ssh、socks、proxy.pac、spidermonkey、johnson

$
0
0

特定のホストからのみ接続できるwebサイトにアクセスしなければならない。しかし自ホストからの直接アクセスはできない。

こうしたとき、まず考えるのはproxyの利用だ。目的のwebサイトにアクセス可能な別のホスト(中間ホスト)でproxyサーバを動作させる。そしてそのproxyを経由して目的のwebサイトにアクセスする。この方法でめんどうなのは、アクセス元(自ホスト)、アクセス先(目的のwebサイト)とは本来関係のないホストで管理・運用作業が発生する点である。今後ずっと、というのでなければ採用しづらい。

次に考えるのはSSHによるポートフォワードを使った方法だ。こうした一時的な状況では、関係各ホストにSSHでならアクセスできることが多い。SSHの機能を使い、自ホストと中間ホストにトンネルを作る。webサイトへのアクセスを、このトンネルへのアクセスに代えることにより関接的なアクセスが可能となる。

ssh -L 20080:www.example.com:80 proxy.exmaple.jp

この例では自ホストの20080ポートへのアクセスが中間ホスト(proxy.example.jp)を経由して目的のwebサイト(www.example.comの80ポート)へとつながっていく。中間ホストで特別な作業は発生せず、手軽でよいのだが、一般的なブラウザでアクセスする際に「http://www.example.jp」でなはく「http://localhost:20080」を指定しなければらない問題がある。単純なところではリンク切れが起きる可能性がある。

通常通りのURLを指定して、かつ、SSHのトンネルにアクセスを導くには、SSHおよびブラウザのSOCKS対応機能を使う。

sshにはSOCKSサーバとして動作する機能がある。また、多くのブラウザは、proxy機能の一部としてSOCKSクライアントとしての動作ができるようになっている。proxy機能であるから、通常通りのURLを指定しても実際のアクセスはSOCKSサーバに振り向けられる。よってURLを「localhost」などと変えなくてもすむ。

ssh -D 21080 proxy.example.jp

ブラウザではSOCKSサーバをlocalhost、ポートを21080とする。この設定したブラウザは、すべての通信を指定のSOCKSサーバを介して行うようになる。となると、目的のwebサイト意外へのアクセスまで含めて中間サイトからアクセスする状況に陥いってしまう。これは通常やりすぎである。

SOCKSサーバの使用をアクセス先によって選択することができないか。FirefoxならFoxyProxy、ChromeならProxy Switchy。これらはまさにそのための拡張だ。ところが、現在のProxy Switchyには問題があるようで、こうした動的なproxy選択の機能が動作しない。この問題の回避方法もあるようなのだが、そのためにはシステムのproxy設定を変更することになる(そもそもそうした動作をするものであるようだ)。そして、そのための設定にはPACと呼ばれるファイルを用いる。

PACには、ブラウザがproxyの使用が必要かどうかを判定するための要件を記述できる。これまでほとんど縁がなかったため考えから抜け落ちていたのだが、前述した拡張を使うまでもなく、適切な内容でPACを作成してシステムに適用すればよい。

PACの書き方については検索すればいくつもの情報が見つかる。けれども、それらの多くで参照している大本のnetscapeのサイトが消失しておりなかなか追求できない。そのため現在ではWikipediaを参照するのがよさそうだ。日本語ではプロキシの自動設定方法PacファイルによるProxyの指定などを併わせて読むと参考になる。今回のケースでは次のような記述をすれば十分であろう。

function FindProxyForURL(url, host) {
  if (shExpMatch(url, '*://www.example.jp/*')) {
    return 'SOCKS localhost:21080';
  }

  return 'DIRECT';
}

この程度の簡単な内容であれば動作確認は簡単である、と言いたいところだが、実際のところ「()」の書き忘れをするなどということをしてしまい書き換えと確認を何度か繰り返し行った。そこで、w3cのHTML validatorのようなものはないものかと探してみたのだが見付からない。次に、結局のところPACはJavaScriptであるためコマンドラインから実行するツールを探してみたところpactesterが見付かった。

pactesterはJavaScriptの実装であるSpiderMonkeyと、PAC記述のためのサポートスクリプト(JavaScript)およびコマンドそのものとなるPerlスクリプトからなる。SpiderMonkeyとPerlを接続するためにJavaScript::SpiderMonkeyというライブラリを使っている。問題はこのライブラリのパッケージが手元の環境にはない点である。もちろんCPANを使うなどすればよいのだろうが……。

別の実装はないかと探してみたがこれというものを見付けられない。SpiderMonkeyのほうで何かないかと検索範囲を広げていったところ、JavaScriptのテストというテーマの中で発表されたさいきんのJavaScriptテストの資料に行きあたった。同資料の中ではAjaxを含む、というよりそれをメインのターゲットにしたJavaScriptのテストを支えるテスティングフレームワークの興味深い内容に触れられている。そんな中に、今回の状況、PACのテストに使えそうなものがあった。

JohnsonはRubyとSpiderMonkeyを結び付けるライブラリである。前述のJavaScript::SpiderMonkeyがPerlとJavaScriptの中間に立ったように、このライブラリはRubyとSpiderMonkeyの中間に立つ。資料の本題ではEnvjsと組み合わさることでブラウザ上でのJavaScriptコードの動きをコマンドライン上で検証できる様子が示されている。もちろん、ここではそこまで高度なことは必要ない。PACを実行し、その動作が想定通りであることを確認するのが目的である。

前掲のPACのような簡単なものでもJavaScriptの組み込みではない関数が登場する。一般的なJavaScript実装においてPACの動作を検証するためには、これらの関数を何らかの形で実装しなければならない。だが、これを独自に実装するのでは本末転倒である。幸い、先に紹介したpactesterにそのためのJavaScriptコードが含まれている。pac_utils.jsがそのコードであり、もともとはmozillaのコードの一部をもとにしたものだそうだ。

pac_utils.jsがあれば十分かというと、もう少し足りない。Wikipediaの解説にもある通り、さらに二つの関数、dnsResolve()とmyIpAddress()を実行系で使用できるようにする必要がある。pactesterではこの部分をPerlコードとして実装しており、Johnsonを使うのであればRubyコードで実装することになる。このようにしてできたのが以下のPACテスト用スクリプトだ。

pac_file = 'proxy.pac'

tests = [
  # {:url => 'http://example.jp', :expect => 'proxy spec', ... }, ...
  {
    :url => 'http://www.example.jp/',
    :expect => 'SOCKS localhost:21080',
  },
  ...
]

hosts = {
  # hostname => '10.1.1.1', ...
}

require 'uri'
require 'socket'
require 'rubygems'
require 'johnson'

def dns_resolve(host)
  Socket.gethostbyname(host)[3].unpack('C4').join('.')
rescue
  nil
end

runtime = Johnson::Runtime.new
runtime.load('pac_utils.js')
runtime.load(pac_file)
runtime['dnsResolve'] = proc do |host|
  map[host] || dns_resolve(host)
end

failed = false
tests.each do |hash|
  runtime['url'] = hash[:url]
  runtime['host'] = hash[:host] || URI(hash[:url]).host
  runtime['myIpAddress'] = hash[:client_ip] || '10.0.0.1'

  expect = hash.delete(:expect)
  proxy = runtime.evaluate('FindProxyForURL(url, host)')
  unless expect == proxy
    puts "failed: #{hash.inspect} #=> #{proxy} (expected #{expect})"
    failed = true
  end
end

exit 1 if failed

ScanSnap後の画像処理

$
0
0

スキャンした画像を読み易くするための後処理が世の中でどのように行われているか調べてみた。自分用のブックマークでもある。

jarp,より

150 dpiでスキャンするより300 dpiでスキャンして16階調にしたほうがサイズが小さい - jarp,

convert in.png -deskew 40% -level 30%,100% -sharpen 5 \
  -density 150x150 -colorspace gray -resize 514x751\! -depth 4 out.png

-deskewにより傾き補正をかける。その際にぼけるため-sharpen 5でぼけ補正もしておく。

スキャンは横向きで - jarp,

r=90
for i in *.png;do convert $i -rotate $[r*=-1] r90-$i; done

縦長の紙面を横向きでScanSnapにかけるとスキャンにかかる時間が短くなる。このときの画像は横向きかつ互い違いとなるため、これを縦向きに変換するためのコマンドライン。

ImageMagick convertで連番処理 - jarp,

convert '*.png' -type grayscale -depth 4 d4/%03d.png

ImageMagickには独自のワイルドカード処理がある。また、出力ファイル名にprintfに似た形式の文字列展開ができる。この例のように出力ファイル名に%dがあれば、その部分は0から始まる連番に展開される。たとえば*.pngにマッチするファイルが三つあればd4/000.png、d4/001.png、d4/002.pngに変換結果が出力される。

-scene 1のようなオプションを付加すると連番が指定した値(この場合は1)から始まる。

この他、画像自身の属性値からファイル名を構成するなどいろいろなことができる。参考:

Desire for wealth : ScanSnap の自炊 pdf を自動で美白化(レベル補正)する

convert -density 150x150 -type GrayScale \
  -linear-stretch 10%x35% \
  -geometry 512x -compress jpeg -quality 80 a.pdf b.pdf

PDF中の画像データに対して、いわゆる白飛ばしをかける方法が紹介されている。ここで-linear-stretchのパラメータの意味が重要となる。このパラメータについての詳細はUbuntu Weekly Recipe 第102回 ImageMagickでコマンドラインから画像加工で解説されている。(二ページ目へのリンクだが一ページ目から読んだほうが分かりやすい。)

これらの記事で解説されている-linear-stretchの他に-levelというよく似たオプションがある。両者の違いと適用した結果がどうなるかについてもう少し調べた内容を別記事にしてみた。

スキャンした書籍や書類の余白をImageMagickで除去する | anobota

convert \
  \( -size 320x400 xc:white \) \
  \( -level 0%,75%,0.8 -fuzz 50% -trim original.jpg \) \
  -gravity center -composite out-5.jpg

344×292の余白のある画像から文字部分だけを切り抜いて、それを320×400の中央に配置するためのコマンドライン。

-trimによる文字部分の切り抜きの際、-fuzzを指定することで紙質によるムラなどの影響を小さくすることができる。小説などではかなり使えそう。技術書でも、といいたいところだが、ページ端にマークがついていたりするので最初に-cropしないとならないかも。

Kindle3向けdot by dotな自炊PDFを(真面目に)作成する - ただのにっき

様々に調整された手順をパッケージ化されている(kindlizer)。私自身は同端末を持ってはいないのでそのまま使うことはないが、その内容は参考にさせてもらえるのではないかと思う。と、いいつつ、まだあまり内容を読んでいないけれど。

scansnapで自炊した本をkindleで読めるように補正する(2)

ImageMagickがよく使われるなか、OpenCVで後処理を行っているという話。OpenCVを使った処理に興味があるので時間をとって試してみたいと思っている。が、これまたなかなか手をつけられをいままでいる。

しばらく開発が止まっていたRuby/OpenCVが動き出しているようであり、手を出すのにちょうどよい時期かもしれない。(参考: 第5回 Ruby/OpenCV進捗報告ruby-opencv)

Gimp Script-Fuによる処理

ここからGimp関係の記事になる。

Script-fu: 矩形選択範囲からImagemagick crop用のgeometry表現を得る

これは直接的なものではないが、GimpのScript-Fuを使っていて興味をひく。Script-Fu自体の情報がなかなかないので参考になる。(参考: Gimp記事のもくじ)

Gimp Pythonでスキャンした画像を一括修正

GimpからPythonスクリプトにより画像処理をするという話。トリミングやトーンカーブ調整などが行われていて、詳しく読んではいないが参考になるのではないかと思っている。

Viewing all 174 articles
Browse latest View live




Latest Images