画像処理 その２

よーわからんけどGraphicsMagickはなんでダメなの？

GIMPのを使うとかな。

>>895
OpenCVは？

ippでDIB扱う部分は自分で作る必要あるの？

画像処理だけどさ、基本的なフレームワーク何使ってる？
GEGLとかTEOとかImlibとかImageMagickとかGDとか腐るほどあるみだいだけどさ。

画像処理業界って求人少なくないですか？
転職を考えているんですが
募集してる件数がかなり少ないように思えるのですが。

>>902
画像処理にもいろいろあるが

>>902
医療機器の開発とか、大手写真メーカーや電機メーカーがいつも募集しているぞ。
ただし、「いい人がいれば採りたい。人がいないなら欠員でも仕方ない」というタイプの
求人だから、常時募集していても簡単には入れないけどね。

回転の話題がありましたがアンチエイリアスを適応する回転のコードとか
ありませんか。

>>902
ロボット・車両関係の画像認識関連も大いに人不足。
ただし、やぱーり採用は >>904 だが。

>>902
あと、色んな工場向けの検査装置の需要も結構ある。地味な分野だけど、日本の製造業は
人件費で中国に勝てるわけないから省力化は必須で、人間の目視検査でやっていたものを
コンピュータ化するというのは、それなりに需要があるよ。工場が生産するものそれぞれに
応じて、画像処理のカスタマイズが必要だから、時として、その場しのぎのヤッツケ仕事に
なってしまうことも多いけどね。

今後の需要で期待されているのは、やっぱりセキュリティ関連。ステレオカメラとか
動画像から特徴抽出とか、いろんな案件がある。工場の検査機器と同じで、同じものを
画像処理装置を量産するんじゃなくて、たいていは顧客の要望に即したカスタマイズが
必要になるから、これまた仕事はいろいろある。テーマパークなんかで、お客さんたちの
流れを計測してあれこれ案内を流す装置みたいな、目立たないものが多いけどね。

残念ながら、この手の仕事は、大企業なら研究所で細々とやっていて転職者の募集は
あまりやってない。世間一般には全く名前を知られていない中小企業（しばしば大企業
から独立した人が作った会社）が、大企業から仕事を請け負っている場合が多いし、
中途採用をやっているのもそういうところだったりする。

大企業にこだわるなら、家電メーカーやカメラメーカーのデジカメの開発部門でもあたって
みては？　そういえば、サムソン横浜研究所がデジカメの技術者を求めていたなぁ
コダックも、デジカメの開発は日本に集中させると言っていた。

これ以上はマ板だな

「新編 画像解析ハンドブック」ってどこで買えるの?
どこにも売ってないよ…

http://www.utp.or.jp/index.html
版元で買える。

と思ったら、まだ未刊らしいよ。

おまいら、PCカメラの映像から、物体の移動を検知する手法を教えてください。

発言元
http://pc5.2ch.net/test/read.cgi/tech/1088022524/272-274

このへんとか
http://www.malib.net/api/ja/node44.html

なるほと、フレームの前後をマスクして割り出すのですね
とてもよくわかりました。ありがとうございます

GTK+ とか GDK とかの説明を読んでいて、急に思い出したのですが、
昔、GKS とかの graphics interface ？がありましたが、今、どう
なっているか、なになにに生きているとか、無くなったとか、ご存知の
方いらしゃいませんか。（1985 年頃、Nova Graphics International,
Austin, Texas でやっていたと google では出てくるのみ）

顕微鏡などの被写界深度の浅い画像の
全焦点画像の合成って、どうやってやるのでしょうか?

顕微鏡でピントをずらしながら複数フレームの画像をとりこんで、
全フレームの中で周辺8近傍との差分の絶対値の和がいちばん大きい画素を、
一枚のフレームに集めこんだら、できるだろうと思ってやってみました。

まぁまぁ予想した感じにはなったのだけど、
キーエンスとかオムロンとかの合成ソフトの画像ほど、
きれいに合成されませんでした。

やっぱり、こんな単純なアルゴリズムでは、だめなのでしょうか。
空間領域ではなくて、周波数領域とかで処理したりするんでしょうか？

>915
>全フレームの中で周辺8近傍との差分の絶対値の和がいちばん大きい画素を、

もうちょっと頭を使えｗ

>>916
915ではないが、もうちょっと頭を使ったアルゴリズムｷﾎﾞﾝﾇ

各画像のベンチマークとかあったらおせーて。
あと解凍アルゴリズムも。

２値画像のラベリングを再帰をつかってやりたいのですが
わかりません。どなたかソースもってませんか！？
教えていただけるとうれしいです

>>919
なんで再帰限定なの？宿題？

リアルタイム処理したいので高速なのが必要なのです。あとちょっと時間ないので特殊な
データ構造とかいらない簡単なものだと再帰がいいのかなと。
もちろん論文よめば複雑なアルゴリズムあるんでしょうけど・・・。

↑919です

>> 921
image MLの1998年8月くらいにラベリングに関するQAがあって、ソースもでていた
ので探してみ

>>921
「再帰」がいいのなら、トランジスタ技術2003年2月号P.201にあります。
"USB接続のパソコン用カメラで物体認識と動き検出"という章。

紹介したはいいけど、再帰って、いまいち気持ち悪いんですよねー。
リアルタイムでキャプチャということですから、
そんなに画像サイズがでかくないんでしょうけど、
再帰コールによるスタックオーバーフローにご注意です。

ついでに再帰を使うアルゴリズムは激遅ですよ、いいのかなー。

Floydが1976年に書いたError Diffusionの論文
"An adaptive algorithm for spatial grayscale", Proc. of the S.I.D, vol17, no.2, pp.75-77
がPDFで見れるとこ探してるんですけどどこかにないでしょうか？

末尾再帰になるならコンパイラによる最適化もじゅうぶん望めて、
スタックも食わないが。

末尾再帰ってなんですか?

927 です、web検索したら、わかりました。

>>925
それ俺も探してたけど結局見つかんなかったなぁ．
極論だけどもし参考文献に引く程度なら読まなくても大丈夫なんじゃない？ｗ
今でもまだ読んでみたいし，見つかったら教えるよ．

RGB表色系からCIE L*a*b*表色系への変換方法ってか
RGB→XYZの変換行列が色々あってよくわからないのですが，
RGBからフォトショのLabを得るためにはどうやったらいいのですか？
教えていただけると助かります．

面積平均法って、英語で何て言うんですか？
日本語の文献が少ないようで、海外の文献を
調べようと、ぐぐりたくても、名称が分かりません

> 931
> 面積平均法って、英語で何て言うんですか？

area averaging method

>>915
こんなのもあるけど。
ttp://www.vector.co.jp/soft/win95/edu/se113943.html
何とかってソフトほど綺麗には出来ないかもしれないけど、フリーだしソース付きだから、見てみたら?

ベースラインJPEGの画像縦横サイズを取得したい場合、
まずマーカ「FFC0」を探すことになります。しかし実際に
JPEGファイルをバイナリエディタで開いてみたところ、
JPEGファイルによっては、マーカ「FFC0」が2つ存在する
ことが判明しました。しかも、最初に見つかった「FFC0」
のところに書かれている画像縦横サイズは間違った値で、
2回目に見つかった「FFC0」のところに書かれている
画像縦横サイズは正しい値でした。
正しい画像縦横サイズのみ取得するには、
どうしたらよいのでしょうか？

後にくるもので上書きすればいい

>>935
確かにそのようにすれば、2回目に見つかった「FFC0」の値が
取得できますが、後に見つかった「FFC0」の方が必ず正しい値
であるかは分からないので、ちょっと不安です。

>>934
こんなアルゴリズムでどうよ？
これは厳密な BaselineJPEG のデコードの考え方のはずなんだ。
これがダメなら、よければ漏れにも問題の JPEG ファイルをくれるか。

unsigned short get_marker () {
　return (0xff で始まる 2 バイトをストリームから探し、読み、返す)
}
void get_jpeg_image_size () {
　unsigned short marker;
　do {
　　marker = get_marker();
　　switch (marker) {
　　　case 0xffd8: // start of image
　　　　break;　// 何もせずに次のマーカを処理する。
　　　case 0xffda: // start of scan
　　　　// これより前に画像の大きさは得られているはず。
　　　　break;
　　　case 0xffc0: // start of frame 0
　　　　// 本物の start of image 0 のはず。
　　　　process_start_of_frame_0();
　　　　break;
　　　default:
　　　　// セグメント長を得てストリームをスキップ
　　　　// もしくは、無視してはいけないはずのマーカならば
　　　　// エラーを報告してループを抜ける等。。。
　　}
　} while (marker != 0xffda); // start of scan でループを抜ける
}

>>937
うーむ、そのアルゴリズムでも駄目かも。
問題のJPEGは、「Windows XP.jpg」で
OSインストール後、↓のフォルダに入ってます。
「C:\WINDOWS\Web\Wallpaper」

漏れ XP 持ってNEEEEEEeeeeeeeee
ちょうだいヽ(；´Д`)ノちょーだい

サブピクセルレンダリングとアンチエイリアスの比較やってみたんですが、
ピクセル補完に二次補完を使った場合は明らかに前者のほうが優れていますが、
三次補完になるとほとんど差がありません。

二次のサブピクセルレンダリングと三次のアンチエイリアスだと、
後者のほうが明らかに画質が高く計算量も少ないのに、なぜAdobeReaderとか
XPでは二次のサブピクセルレンダリングが使われてるんでしょうか？

>>939
はい。

ttp://age.tubo.80.kg/age01/img-box/img20040719122143.jpg

>>941
ｻﾝｸｽｺ。
つーか見てみたけど、20バイト目から始まる「セグメントApplication13」を
指示通り 2280 バイトスキップして、さらに 2302 バイト目から始まる
「セグメントApplication2」も指示通り 3160 バイトスキップして、
さらに 5464 バイト目からの「セグメントApplication14」も指示通りに
14 バイトスキップすればいいんだよ。
つまり　>937 のアルゴリズムでいいじゃん。
「セグメントApplication-N」なんて、ほとんど無視して大丈夫。

ちなみに >937 のダメなところは start of frame 0 しか処理していない事。
web上にはプログレッシブJPEG、つまり start of frame 2 を持つものも多くあるよね。
そいつらも処理できた方が cool だ。
もっとも、セグメントの構造はどちらも全く同じだから、
画像サイズを得るには何ら難しい事は考えなくて良いけど。

>>940
漏れの予想だけど、サブピクセルレンダリングの方が
・メモリは必要だけどアルゴリズムが簡単
・細い線をレンダリングできる
からじゃない？間違ってたらスマン

>>933

915です。どうも、ポインタをありがとうございます。
Delphiのソースですね、さっそくDelphi6 Personalをインストールせねば。
(でも *.pas だけテキストエディタで読めばいいのか)

いろいろ資料を探しておりました....
フォトロン社&&産総研の共同研究にブチあたりました。
それを読むと、あんまり頭つかうアルゴリズムではないような気がします。
(NTSCレートで実現しようとしているので、そうなのかもしれませんが)

>>942
>>943

934です。
大変参考になりました！
ちゃんとセグメント長を得てストリームをスキップ すれば
問題ないと言うことですね。
どうもありがとうございます。