画像処理ライブラリ

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

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