mieki256's diary



2024/06/06(木) [n年前の日記]

#1 [perl][prog] Perlを再勉強中

ふと思い立って、Perlスクリプトを書こうとしてるところ。言語仕様をすっかり忘れているのでググりながら再勉強中。

この日記ページの各記事にはカテゴリ名を付けられるけれど、cat.txt というファイルにカテゴリ名を書いておかないとページ左下のカテゴリ一覧に出てこない。cat.txt に手作業でカテゴリ名を追加してアップロードするのが面倒なので、この日記ページの元ファイル、*.hnf 群をスキャンして cat.txt を作るスクリプトを書けないものかなと…。

何の言語で作ろうか悩んだけれど、この日記ページを見せているWeb日記システム hns が Perl で動いてるので、Perlで書いておけば、ひとまず動くことは動くだろう、と。まあ、処理が遅いかもしれないけれど。

Perl Navigatorをインストール :


2024/06/05(水) [n年前の日記]

#1 [prog] 自作スクリーンセーバを修正した

以前作ったOpenGLを使うスクリーンセーバと同様の描画処理をするデモプログラムを、Lenovo IdePad S10-2上でも動くように修正した。

_mieki256/ssp3droadgl

元のプログラムは、4096x4096のテクスチャ画像を使っていたけれど、IdeaPad S10-2 (Intel Atom N270, Mobile Intel 945GSE Express)の最大テクスチャサイズは2048x2048だったので、テクスチャが読み込めなくて正常な描画にならなかった。今回、1024x1024のテクスチャ画像も用意して、GL_MAX_TEXTURE_SIZE が 4096 より小さい場合はそちらのテクスチャ画像を読み込むように修正してみた。

動作確認したところ、小さいテクスチャを拡大しながら描画してるせいか、カメラに近いビルボードや路面はボケボケになってしまった。でもまあ、描画されないよりはマシかなと…。

ちなみに、30 - 50FPSぐらいで動いてくれた。結構善戦している。20FPS に固定すれば処理落ちせずに済む感じ。

1024x1024以下しか使えないGPUはあるのだろうか :

GL_MAX_TEXTURE_SIZE が 2048 どころか 1024 を返してくるハードウェアはあるのだろうか。以下のページを眺めてみたけれど…。

_OpenGL capabilities report: GL_MAX_TEXTURE_SIZE

大半のGPUは最低でも2048を返してくるように見える。1024を返してくるGPUは数えるほどしかない。

ただ、VIA/S3G UniChrome Pro が1024を返すようではある。ググったところ、VIA K8M800チップセットに統合されていたGPUらしい。

_S3 Chrome - Wikipedia

一応、MSI K8MM-V という、VIA K8M800 + VT8237R が載ってるM/Bを持ってるから、テストしてみようか…。

でも、あのM/Bは Linuxのデスクトップ環境すら真っ当に表示できないほどに動作が遅かったはず。ウインドウを移動するだけでも、ベロンベロンと書き換えてる様子が分かるぐらいに遅かった。あのハードウェアでOpenGLを動かそうと思う人はもう居ないんじゃないか…? そもそも今の時代に使ってる人はどれほど居るのか…。いや、それを言ったら、今の御時勢、スクリーンセーバ自体を動かす人が一体どれだけ居るのかと言う話にもなりそうだけど。

#2 [nitijyou] ヤマダ電機に行ってきた

夕食を食べ終えてから、ヤマダ電機まで電動自転車で行ってきた。一番近いルートを選んで走ったので片道20分ぐらいで到着。

ここ最近、親父さんがホイールの壊れたマウスをずっと使っている点が近気になっていて…。PC操作を教えるときに自分もちょっと触ったりするのだけど、ホイールを回したらスクロールがめちゃくちゃになって、コレを使い続けるのはもう無理だろうと。代替品を購入したいけど、親父さんが使っている BUFFALO BSMBW500LWH (ワイヤレス, Lサイズ, 色は白, 5ボタン)は、もうどこにも売ってない。

_BSMBW500LWH : マウス : Premium Fit | バッファロー

LサイズじゃなくてMサイズでもいいからどこかに売ってないものか、各店舗の店頭で探すしかないかなと…。

幸い、ヤマダ電機の店頭に、同じシリーズの製品が少しだけ残ってた。BUFFALO BSMBW300MBK。ワイヤレス。Mサイズ。色は黒。3ボタン。

_BSMBW300MBK : マウス | バッファロー

LサイズとMサイズの違いがあるので若干小さくなるけれど、形状はほぼ同じだから、そこまで違和感は無いだろう…。色は白から黒になってしまうけど、親父さんは色にこだわりがあるわけでもなさそうだし…。親父さんは4-5ボタンを全く利用していないので3ボタンのほうがありがたいはず。そんなわけで、購入。税込2,164円。

帰宅後調べてみたところ、ヨドバシなら 1,290円だった…。失敗したかな…。というかヤマダウェブコムですら1,278円だし。いやまあ、後者は送料がかかるけど…。

2024/06/04(火) [n年前の日記]

#1 [cg_tools] 画像処理の膨張、収縮、dilate、erodeについて調べてた

_昨日、 画像の透明部分に、不透明部分のRGB値を引き延ばす処理をGIMPでできそうかどうかを調べてたけど、ガウスぼかしを使って処理するのは何か違うのではないかと思えてきて、引き延ばす(?)感じのフィルタ処理は他にないのか、そういった画像処理は何と呼ばれているのか、そのあたりを調べてた。

おそらくだけど、膨張、収縮(または侵食)と呼ばれる処理がソレなのかなと…。

膨張、収縮 :

一般的に画像処理の世界では、背景は黒(=0)、前景は白(=1)として扱う場合が多いらしい。

そして…。
  • 白い部分を大きくする/面積を増やす処理を「膨張」「dilate」「Dilation」と呼ぶ。
  • 白い部分を小さくする/面積を減らす処理を「収縮」「侵食」「erode」「Erosion」と呼ぶ。

処理内容日本語英語
白い部分を大きくする/面積を増やす膨張dilate、Dilation
白い部分を小さくする/面積を減らす収縮、侵食erode、Erosion

_モルフォロジー変換 - OpenCV-Python Tutorials 1 documentation
_【画像処理】膨張・収縮処理の原理・特徴・計算式 | 西住工房
_2値画像の膨張・収縮 1 | 画像認識の技術ブログ | マクセルフロンティア株式会社
_【画像処理ノウハウ】膨張とは - Pixelup
_2値画像処理

GIMPの場合 :

フリーで使える画像編集ソフト GIMP にも、同様の処理を行うフィルタがあると知った。
  • フィルター (Filters) → 汎用 (Generic) → 明るさの最小値 (Dilate)
  • フィルター (Filters) → 汎用 (Generic) → 明るさの最大値 (Erode)

GIMP 2.10.34 Portable Windows版で試してみた。たしかに、白い部分が膨張したり、収縮したりしている。

gimp210_dilateerode_ss01.png

その昔、争いがあった。らしい :

ただ、この Dilate と Erode については、今から20年前、GIMP 2.4 より前のバージョンでは処理が逆だったらしくて…。

_Bug 156545 - dilate/erode mis-named (refer to opposite operations)
_Bug 768741 - Filter -> Generic -> erode / dilate are reversed

「eordeは黒を増やして、dilateは白を増やすのに、GIMPでは逆になってる。これはバグやろ」
「そうかもしれんけど、関数名を変更すると今まで書かれたスクリプトの動作がおかしくなる。修正したくない」
「ErosionとDilationの言葉の定義を考えたら、この動作はやはり逆だ」
「背景を黒、前景を白と捉えるとそう見えるが、背景を白、前景を黒と捉えればこの動作は正しい。お前の捉え方がおかしいんじゃね?」
「あのなあ…。自分は画像処理の博士号を取得してるんだよ。あらゆる画像処理の文献と照らし合わせてもGIMPの動作は逆だ。これはさすがにおかしい」
「俺は後方互換性を重視して変えないほうがいいと思うけど、一応パッチは書いてみたよ」
「GIMP 2.4でそのパッチを取り込んでみようか…」

(この議論をしている間も「dilate/erodeは逆じゃね?」「またソレかよ! 既出なんだよ。このスレ見ろよ」というやり取りが何度も何度も…)
(そしてGIMP 2.4でDilateとErodeの動作が逆になった)
(そこから数年後)

「おい! この Dilate と Erode は動作が逆だろ。これはバグだ!」
「俺もバグだと思うんだけど『これが正しい』と言い張る連中が居るんよ…。この過去スレを眺めてくれ…」

みたいな。

これは想像だけど…。画像処理の世界では、背景=黒=0、前景=白=1が前提条件になっているけれど、一般人の間では Dilate と Erode から連想される処理内容が真逆なのかもしれないなと…。

この混乱は、結構長い間続いていた(続いている?)っぽい。例えば、GIMPのヘルプドキュメントを眺めると…。

_https://docs.gimp.org/2.8/en/plug-in-dilate.html (GIMP 2.8)
_https://docs.gimp.org/2.10/en/gimp-filter-dilate.html (GIMP 2.10)

_https://docs.gimp.org/2.8/en/plug-in-erode.html (GIMP 2.8)
_https://docs.gimp.org/2.10/en/gimp-filter-erode.html (GIMP 2.10)

_https://docs.gimp.org/2.10/ja/gimp-filter-dilate.html (GIMP 2.10 日本語版)
_https://docs.gimp.org/2.10/ja/gimp-filter-erode.html (GIMP 2.10 日本語版)

お分かりいただけるだろうか? GIMP 2.8 と GIMP 2.10 で、Dilate/Erode の動作が真逆になって説明されてる。更に日本語版に至っては、ページの見出しが「明るさの最小値」なのに、ページ内で「明るさの最大値フィルタは〜」と記述されちゃってる。君は一体どっちのフィルタについて説明してるのだ…?

まあ、そのぐらい、この2つのフィルタについては、扱いが混乱してるのだろうなと…。自分もこうしてメモしてまとめてみるまでは、どっちがどっちなのかちょっと分からなくなってたし…。

「明るさの最小値」「明るさの最大値」ってなんやねん :

それはともかく、GIMPのフィルタ名の「明るさの最小値」「明るさの最大値」って意味不明だよなと…。どんな処理をしてくれそうなのか全く分からない。どうして、画像処理の世界で普及しているワードに ―― 「膨張」「収縮」、あるいは「膨張」「侵食」にしなかったのだろう。何か理由があるんだろうか。

そのあたりググってみているうちに、なんとなく理由が分かってきた。そもそも、Photoshopが「明るさの最小値」「明るさの最大値」という訳をしていたのだな…。おそらくGIMPは、Photoshopのソレに倣って、そういうフィルタ名を選んだのではなかろうか。たぶん。

しかし、この珍妙(?)な訳のおかげで、功を奏した面もありそうだなと…。「一体なんだろう、このフィルタ…。何ができるフィルタなのか名前から想像できないから、とりあえず触らないでおこう…」という状態になって、結果的には、「このフィルタは動作が逆だろ?」「いや、これで正しいんだ」「いやいや、やっぱりおかしいって。逆だって。バグだよコレ」というバトル(?)が日本国内では起きずに、我々は平穏な日々を過ごせてこれたのかもしれない…。なんちてぽっくん。

余談。不透明部分のRGB値を引き延ばせるかどうか :

さておき。GIMPの「明るさの最小値」を使って、「膨張」「Dilate」を ―― 透明部分に、不透明部分のRGB値を引き延ばせるかどうか試してみたけれど…。

元々のRGB値をそっくりそのまま膨張してくれる点はいいけれど、数回実行してみると、妙なところまで色が回り込んだ見た目になってしまう時があるなと…。例えば以下の事例では、右下のあたりに不自然な緑色が回り込んでしまっている。

gimp_dilate_ss01.gif

まだ、ガウスぼかしを使って引き延ばしたほうが、自然な見た目になりそうな気もしてきた…。

以上、3 日分です。

過去ログ表示

Prev - 2024/06 -
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