画像処理ライブラリ

どうもJudaです。
画像処理ライブラリは汎用性が高くて、使用頻度も高く、なおかつ逐一スクラッチで作るにはめんどうで、それでいて速度が求められて、細かな仕様に左右されることの多いライブラリだと最近思います。
例えばOpenCVのRGBコンポーネントの内部的な配置はRGBではなくBGRであるなど（一応内部的にRGBへ変換する関数が存在するようですが）コンポーネントの問題があり、その画像がRGB24なのかRGBA32なのか、それともGrayScale１６なのかGrayScale32なのかYUIなのかHSVなのかなど色空間の問題もあります。
それらすべてに汎用的なものを用意するのは、非常に困難であり、通常画像処理ライブラリはRGBでの画像処理をもとに考えられています。もっともこれ自体は特にプログラマにとって問題なく読替を効かせることのできるものです。問題はそのライブラリは高速にすることや、面倒を回避するために汎用化することです。
一部細かな話しですが、.netでのImageの操作は通常はメソッド経由なので、オーバーヘッドが尋常ではないので、特定の一点から取得するなどのアクセス頻度の低い作業以外は、なるべく低レベルな操作で構築する必要性があり、BitmapのLock/Unlockは.net系の画像処理では必須であり、これはコンポーネントの構成に大きく左右されるので、通常のマネージドな感覚で行っていると速度の低下が発狂せんばかりになります。Lock/Unlock以外にもUnsafeでガリガリ行う方法もありますが、移植性が下がるので、なるべくそれはやめた方がよいです。それに性能もそれほど向上しないので、最終手段として覚えて置く程度でいいと思います。
話は戻りますが、画像処理は速度と精度と汎用性、多種多様性、移植性、利便性など多くの点が求められるので、なかなか構築が面倒なのですが、作ることは非常に有益だと考えます。
またコンセプト的な嗜好も混ぜ込めるので、個人的にはある程度以上のレベルからは自己のライブラリとして蓄積することを考えてしまいます。
そうするとオープンソースがとても魅力的ですが、仮にこれを業務で特定のアプリケーションに組み込もうと思うと商用ある程度のライセンス料が必要です。そもそも煩雑で有用な知識の集積は、その労力によって企業による上澄みの簒奪を唾棄し、その行為への怒りをこめて、オープン化する場合もあるので、有用なものを安く使いたいという心とライブラリの制作にかかるコストを最低限でも回収したいというジレンマがよくわかります。個人で開発しだすとよくわかります。
だから個人で開発しだしても、やはり企業に差し出すなどということは許容できないなぁと思います。

企業はもっとライブラリライセンスに金を払えやこらー！っていうのがある意味本音です。安くあがる分けねぇだろ、知識の集積を利用しようとしているのに。

JPEGって手のかかる子

どうもJudaです。
最近JPEGのDecoderを自前で用意しなくてはいけないので、大変な思いをしています。しかも特許がらみでなんだか情報も閉鎖的です。とりあえず、エントリをつくっておいて、後で情報を足しておきます。
もーめんどくせぇ。

ロボット開発

楽しそうに尽きる。
開発を試すにも費用の面でいくらか安くなってきているので、
楽しみが増えてきた。
またCAD,CAMの統合開発環境についてもずいぶん状況が変わってきているので、
ローコストで行えます。
とてもすばらしいことです。
近いうちにこの方面へも参戦予定です。

DICOM覚書

DICOMというメディア規格について。

1. 規格の書物の１，３，５，６，１４で画像をうまく復元できるようになると思う。
2. １は概括、３はオブジェクトの説明、５はデータ構造、６は定義集、１４はGrayScaleの色調補正。
3. 浜松医科大学は生家のある都市だが、DICOMの情報が一番整っていた。やるな、浜松
4. ビットデータをどうしても8bitにしなければいけないので、さまざまなフィルタが必要である。
5. GrayScaleはどうしても黒に対する人間の目の感応力が低いので、黒よりも白でより多くの諧調を表現すようなトーンカーブをつくる。
6. ほかの画像に関してもガンマ補正が必要
7. DICOMはもともとは通信の規格から発展しているので、画像関係のところは散乱している。１、を参考にされたし
8. １がMin白、２がMin黒、GrayScaleの話

まぁ仕事が回ってくるのは良いが、せめて業務の範囲を明白にしてください。最後までやるならやるでもっと設計と解析に時間をかけたいです。というか、先にDICOMの規格の書物を全部日本語に訳さないとあとあと二度手間、三度手間だけど、それをして良いのかも、訊かないと分からないのもなんだかなぁ…さらに重要な、業務の期日も明白にして。

話は変わるけど、オブジェクト指向プログラム環境下でGetValueというメソッドで個別の変数を返す処理をしたいとする時に、引数と戻り値をどうするのがもっとも効率的か分からない。特にC++にはクラスに型タイプがない…１つ考えたのは、型の列挙型：eType
eType getValue(void *dst , unsigned long *size);

このように関数を作れば、値をつめたものとそのサイズ、自分で設定した識別子が手に入るのだが…仮にこの引数などは結局はポインタで参照しているデータのアドレスとそのデータのサイズが一緒になっていれば、１つの引数で終わるのだ。さらに言えば、識別子も入れるなら、getできるか出来ないかということまで記述できる。

ただこれだとまったくポリモじゃない。たぶんswitch文で大量に分岐するのが目に見えている。それはそれで面倒です。

さらに話は変わって、C/C++でもっとも信頼できるライブラリって何？そしてライブラリの信頼性の評価/テストってどうなってんの？Boost　C++ をいれてみたいけど、導入がよくわからんｗドキュメントを早く読んで使ってみるお。はじめからスタティックライブラリつけてくれてもいいのに…。

画像処理

日々、吾ハ習ヒ試シ違ヒ試スナリ: 画像の補正
その後、該当するアルゴリズムを探す視点を変更。
すでに適応されている画像編集ソフトのフィルタの作者を探しに回った。
ＧＩＭＰ，Ｐａｉｎｔ．ＮＥＴにはＬｅｎｓＤｉｓｔｏｒｔｉｏｎというまさに探していたフィルタが存在する。
これらの作者を探して待っているとソースコードが出てきた。
今回見つけたのは、Ｐａｉｎｔ．ＮＥＴ用のフィルタです。
http://paintdotnet.forumer.com/viewtopic.php?f=16&t=21624
この掲示板の後半のほうにソースコードとＤＬＬを配っている方がいらっしゃいます。
この人が変数ｋを与えられたパラメータから生成してデータテーブル化して使っています。
これによって前回問題してしていた行列内の変数に対応していました。
今は、このソースを勉強し、自分のアプリケーションに合致するものに読み替えています。

この場合はソースコードをコピーしたことになるのでしょうか？
そもそも数式が存在するものに占有権を主張できるのかなぁ。
そしてぶっちゃけプログラミングは八割は誰かの模倣で成り立っていると思っています。
つまり占有権を認めてもらうと困ります。
ただアプリケーションになっているものについてはこの限りではないと考えます。
ブラックボックスになったものを解析するのはいいけど、
これを複製して自分のもののように主張してはいけないと思います。