mieki256's diary



2004/06/23(水) [n年前の日記]

#1 [cg_tools] ImageMagick 6.0.1をインストール

今までは、Meadow2 との絡みで、WinXP に ImageMagick 5.5.3 を入れてたのだけど。 *1 その Meadow2 が ImageMagick 6.0.1 を要求するようになったらしく。せっかくだから ImageMagick 6.0.1 をインストール。
*1: Meadow2 が 該当バージョンを要求するから。でも、Meadow2 自体は、まだ入れてなかったのだけど>WinXP環境。

#2 [svg] SVG→PNG変換

mapbbs用のアイコン画像を、Sodipodiで描いてたのですが。svgからpngに変換するのが面倒臭い。コマンドラインでサクサク変換できないだろうか。

_Batik - SVG Rasterizer :

Batik という、Javaで書かれたツールを使えば、目的を果たせるらしい。試用してみた。java -jar batik-rasterizer.jar *.svg と打ったら、サラサラと SVG → png 変換された。素晴らしい。と思ったのだけど、なんだかページ外の余分な部分まで出力されてる。うーん。

ImageMagick 6.0.1-Q16 もSVGに対応してるのか :

convert hoge.svg hoge.png と打って変換してみた。ダメ。エラーメッセージが出る。とはいえ、結果画像は得られた。しかし、グラデーションが真っ黒に。完全に対応できてるわけではないらしい。残念。どうやら Batik で作業するしかないらしい。

試行錯誤 :

batik-rasterizer.jar に -a x,y,w,h オプションを渡して、「ここからここまでを出力せよ」と指定すればいいのだろうか。でも、そこで指定する浮動小数点とやらの単位は何だろう。pixelsか、mmか、inchか。

-w width、-h heightというオプションもあるけれど。それらは、最終的な画像サイズを指定するものらしい。その指定サイズの中に、ページ全体が収まるように拡大縮小されて変換される。特定の領域のみラスター画像にしたいという目的からは外れてしまう。

-a オプションを指定してみたけど、やはり単位がわからない。元となるSVGは、ページサイズを 210mm x 210mm にしている。SVGファイルをテキストエディタで覗いたら、width、height が 595.2756 point と書かれていた。Batik での変換時に、-a 0,0,595.2756,595.2756 と指定。一部分しか変換されない。つまり、単位は point ではないのだな。-dpi 72 or 96 を *1 指定してみても、出力画像のサイズが変わるだけで、一部分しか変換されないのは同じだった。

_単位換算計算スクリプト :

上記ページを使って計算すると、210 mm = 8.4 inch になる。72dpi、8.4 inch なら 604.8 dot になるはず。 *2 -a に指定してみた。…ダメ。一部分しか出てこない。

Sodipodiの単位換算 :

実験に使ってるSVGのページサイズは、210mm x 210mm 。Sodipodiの、ファイル → 出力 を選んで、単位を色々選んでみた。cm や、m は、10や100で割るだけだから間違いようがない。しかし、inch にしたら、8.27 と出た。前述ページの結果と違う。何故。…前述ページで、mm → inch → mm を繰り返すと、どんどん値がずれていく。どうやらかなり大雑把な計算をしてるらしい。Sodipodi のほうが正確かも。

1 inch = ? mm :

_国際単位比較チャート
_単位換算 長さの換算
1 inch = 25.4 mm (1 inch = 0.0254 m) らしい。ということは、210mm ≒ 8.27 inch となる。 *3 やはり、Sodipodi の計算結果のほうが合っている。たぶん。

_Pixel換算 :

_(via Fortunefield)
そのものズバリの換算スクリプトがあった。ありがたい。

計算してみた。 _Batik - SVG Rasterizer のページによると、デフォルトは 96 dpi。前述ページで、96 dpi、210 mm と打ち込むと、793.7007874015749 pixel になる。 batik-rasterizer.jar で、210mm x 210mm のSVGを、オプション無しで変換すると、793x793の画像が出力される。Pixel換算の結果と、バッチリ一致する。

ところが、その793x793の中には、ページ外にはみ出したパーツまで描画されてるわけで。…アレかな。Batik は、ページサイズに対応した画像サイズを、一度はしっかり求めておきながら、その後、その画像サイズにあらゆるパーツが収まるように、わざわざ画像を縮小して変換してるということか。…と思ったがそうでもないらしい。ページ外に、かなり盛大にパーツがはみ出してるSVGを作って変換させてみたが、そのはみ出したパーツ全ては出力されなかった。

オプション無しで出力した画像をフォトレタッチソフトで開いて、切り出す座標値を取得して、それを指定して再度変換してやればいいのですが。手作業・目視確認作業が入ってきてしまうわけで。何故、計算のみでズバッと指定値が求められないのであろうか。トホ。

_国によって長さが違うポイント単位 :

同じ「ポイント」といっても、実は各国によって微妙に長さが違う。JISポイントはアメリカン・ポイントに準じているが、ミリ換算の方式が日米で異なるので、ミリ表示では違った値になるが、実用上はまったく同じ長さとして扱われているようだ。
ナヌー。いや、それでも計算結果は合わないけど>Batikでの変換。

Sodipodiのページ表示範囲に沿うように四角を置いてみた :

SVGファイルの中をテキストエディタで覗くと、744.094482 x 744.094482 と書いてある。210mm x 210mm、96dpiなら、793 pixel になるはずだが。うーん。

線幅2mmの線を引いてみた。SVG中では、7.0866 と書いてある。 _SVGの単位指定 によると、この数字はピクセル単位らしい。2 mm = (2 * (1/25.4)) inch 。それが、7.0866 pixel になるためには…。7.0866 * 25.4 / 2 = 89.99982 ppi ≒ 90 dpi か?

つまり :

Sodipodi は、90dpi で各値を求めてるらしい。となると、例えば 210mm x 210mm のページサイズなら、 *4 744x744 dot のサイズになる。…なるほど。だから、793x793 dot の画像が出力されたけど、余分なところまでその中に入ってしまったのか。ということは、-a 0,0,744,744 を指定すれば…。

キター。ピシッと収まった。

ということで、Sodipodi で描いたデータを、Batik でラスターデータに変換するときは、90 dpi で計算して何dotになるか求めた上で、それを -a 0,0,w,h で指定してやればいいと。やっと判った。なるほど。

ちょっと待て。だったら、-dpi 90 を指定するだけでもいいんじゃないか。試してみた。…ピシッと収まりました(爆) -dpi 72 を指定するとどうなるだろう。…画像が切れてますな。つまり、-dpi 90 を指定するだけでいいわけで。ここまでの苦労は一体… orz

いやいや、ちょっと待て。大きなサイズでラスター画像を得たい場合はどうすればいいのか。…もしかして、そういう時に、-w や -h を使うのか。試しに、-dpi 90 -w 1600 と指定してみた。ピシッと収まった 1600 x 1600 の画像が得られた。正解だった。

まとめ :

Batik で Sodipodi のデータを、ページサイズでピッタリのラスター画像に変換したい場合は、
  • 必ず、-dpi 90 をつける。
  • 大きい画像サイズで出力したい場合は、-w 画像の横幅、あるいは、-h 画像の縦幅を指定する。(片方指定すれば、もう片方は勝手に計算してくれる)
という感じかしら。たぶん。

例: java -jar batik-rasterizer.jar -dpi 90 -w 1600 hoge.svg
… 1600 x ? dot の hoge.png を得る。

でもなんとなく :

90 dpi って、ウチの環境特有の値ではないのかという不安も… (;´Д`)

*1: この場合の dpi は、ppi みたいなものなんだろう。たぶん。
*2: 8.4 x 72 = 604.8 。
*3: 210 / 25.4 = 8.26771653… ≒ 8.27 inch 。
*4: 210 mm = (210/25.4) inch 。90dpi だから、(210/25.4) * 90 ≒ 744 dot。

#3 [zatta] _インチと型

インチ(inch)という単位の使用は計量法(第8条)が禁じているので
何故そんなことを。わざわざ法律で。何か意図があるのか。

この記事へのツッコミ

Re: インチと型 by けいと    2004/06/24 21:36
国際的な取引に使えないから・・・かなぁ?

SI単位以外は使っちゃいけないってところなのかも。
気圧のミリバールも使えなくなっちゃったのと同じなのかも。

EUは市場統合にあわせてSI単位系にそろえていったらしいんですが
(各国ばらばらだとおちおち買い物もできないしね)
アメリカあたりは意地になってヤード・ポンドを捨てませんな。
Re: インチと型 by mieki256    2004/06/24 22:52
> 国際的な取引に使えないから・・・かなぁ?

あ。なるほど。そういうことでありますか。

http://www5.cao.go.jp/otodb/japanese/mondai/subject/199700302.html
なんか色々面倒みたいですな。
華氏が併記されてるだけで、売っちゃいけないと言われるとは。
(いや、それは対象外になったみたいだけど。)

#4 [cg_tools] アルファチャンネルを持ったフルカラーpngを透明な部分を残したまま減色したいのだけど

アルファチャンネルを極力活用する方向で変換するには、どうしたらええねん。

事の発端 :

IEでは、アルファチャンネルを持ったpngを表示しようとすると、透明部分が正常に表示されない。そこで、インデックスカラー(256色以下)に減色した上で、透明色を指定しないといけない。つまり、gifと同じにしてやる必要が。しかし、通常の減色ツールを介してしまうと、せっかくアルファチャンネルという透明度の情報を持っていたのに、それらの部分は無視・廃棄されてしまう。 *1 さて。どうしよう。透明部分を、別の1色として扱いながら、減色してくれるツールがあればいいのだけど。そんなツール、あるのかしら。

使ってない色で塗っておくという手もあるけれど :

その場合、 _フリンジが発生しやすくなる のであります。どこにも使ってない色 = 背景色にした際に透明部分と透明でない部分の境界の色が怪しくなってくる色、なわけで。せっかく元画像がアルファチャンネルを持ってるのだから、少しは活用したいところ。

GIMPならイケるかも :

インデックスカラー化してみたら、結構いけた。しかし、GIMPの減色って、ディザにしなくて済みそうなところもディザにしてしまったりで。性能的にちと問題が。うーん。

_Hints and tips specific to Imagemagick :

convert -type Palette hoge.png fuge.png で 8bit PNG に変換できるらしい。試してみた。…なんだかディザにしなくていいところがディザになってるような。しかもIEで表示したらあらゆる場所が透明になってる。何故。

_pngquant :

_(via 海外フリーソフト紹介)
32bit-RGBAのpngを渡すと、そのまま256色で透明部分を持ったpngに変換してくれるらしい。素晴らしい。…と思ったのだけど甘かった。変換後の画像を見ると、なんだかよくわからないところがボコボコと透明になってる。減色処理結果自体は結構いい感じなのに。惜しい。あと少しなのに。うーん。

_png24 png8 conversion, problems with win32 ie :

これか?
-ordered-dither opacity 2x2  (or 3x3 or 4x4)
or -random-threshold opacity 10% (or other small %)
しかし、「opacity なんて指定はできない」と怒られるのだが。うーん。 _ここから始まるスレッド にも同じような記述が。うーん。

_-ordered-ditherの例らしい。 なるほど。この手法か。そういや、これで「半透明処理」と謳ってたのを、どこかで目にした記憶も。

_Internal Matte Channel :

アルファチャンネルのみを取り出す方法が書いてあった。
 convert drawn.png -channel matte -separate +matte matte.png
取り出してみて、気がついた。convert で縮小した画像のアルファチャンネルは、元画像のアルファチャンネルを縮小したものとは随分と異なる結果になってる。これで -type palette を指定したのでは、異常なデータが出てきて当然。

そもそもIEがPNGのアルファチャンネルに対応してくれてたら :

こんな苦労はしなくて済むわけで。トホホ。

妄想 :

pngからアルファチャンネルだけ画像として抜き出して保存。png画像はそのまま256色未満で減色。あくまで256色未満。1色分は透明色用に残しておく。アルファチャンネル画像を白黒2値画像に変換。減色済みのpng画像に含まれていない色を求め、アルファチャンネル画像をその色でpng画像に合成、かつ、色を1色増やす。増やした1色を透明色として指定して保存。というのはどうか。どうかと言われても。

*1: 背景色を「白」にして減色したら、人の白目や服の白い部分まで「白」になるし。背景色を「黒」にして行えば、黒目や輪郭線が「黒」になる。「白」あるいは「黒」を透明色指定すると、白目や黒目、服の白い部分、輪郭線なども透明になってしまう。

#5 [xyzzy] _kia's website - xyzzy関連 - Exciteで翻訳

英文をそのままコピペして自動翻訳サイトに渡すと、改行が入ってるところでおかしなことになってしまうようで。xyzzy上に貼り付けして修正して、とかやってるうちに、xyzzyから直接、自動翻訳サイトに渡せないものかと思い始めたり。ということで、この拡張はありがたいであります。…もしかして、ローカルに辞書データを置いて云々も便利だろうか。

_英語の辞書機能 :

edict って何だろう? (;´Д`)?

_辞書引きモードを使ってみる :

詳細な解説があった。

英辞郎ってどうやって入手するんだらう :

_本として買う のかな。でも、 _EDP なるサービスもあるらしい。どっちがいいのやら。 _書籍版を購入するとPDICの送金免除 になるらしい。なら、書籍版のほうがいいかしら。単語数は少ないみたいだけど。

_RS125.ORG: PDIC+英辞郎で快適辞書環境 :

英辞郎=2,200円、というのが気になった。どの入手方法のことだろう。 _ハイパー英語辞典 とやらがそれなのかしら。

#6 [digital] 親父さんが新しいデジカメを購入

昨日、買ってきたらしい。 _Canon EOS Kiss Digital だったか。一眼レフデジタルカメラ。元々親父さんは、Canon製の一眼レフ銀塩カメラを使っていたので、カメラのレンズを流用できるという点で選んだ模様。

なんでも、ヨドバシカメラで、6/24 までデジカメ安売りセールをやってたらしいですな。また、 _8/15までに買った人 は、256MBのメディアが1枚貰えるとかなんとか。なもんで、急遽欲しくなったみたい>親父さん。

撮った画像を見せてもらったけど、凄い解像度。CCDセンサではなく、CMOSセンサと聞いて、大丈夫なのかと思ったけど。同じCMOSセンサでも、そのへんのトイデジタルカメラを想像しちゃいかんのですな。(;´Д`)

以上、1 日分です。

過去ログ表示

Prev - 2004/06 - Next
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project