”
YUV-RGB変換６（やったー、うまく行きました） ”でできたと思ったYUV-RGB変換。早速、先生に見せたら欠点を指摘されてしまった。でも確かにそう。。。
それは、輝度が急激に変わるところが飽和しているように見えるということだ。下の写真はCMOSカメラからディスプレイに表示した画面をデジカメで取ったものの一部を拡大している。それはどの部分かと言うと、パソコンの液晶ディスプレイの枠とその表示画面の間が問題となった。黒い枠と広く光る画面の境にピンクの矢印で示す白い線が入っているのがわかる。なぜこの白い線が出るのかが問題だ。
この線は輝度が極端に変わる部分に現れる。例えば黒いコードと白っぽい風景とか。下の写真はダウンロードケーブルのコードの周りにできた白い線だ。なんか飽和しているように見える。もしくはエッジ検出しているみたい。
どうしてこうなるのか？YUV-RGB変換がいけないのか？それとも元からなのか？
原因究明のため、Y信号だけを表示してみた。それが下の写真。カラーの時と同じ場所を写した写真だが、特に黒いケーブルの周りが白くなっているのがわかるとおもう。（下の写真をクリックして拡大してみると、良く見えます）
本当に輝度信号からおかしいのか、ChipScopeを入れてデータを見てみることにした。使用したのは、下の写真のような画像だ。どこがポイントかと言うと、VGA信号の最初に輝度がおかしい処を持ってくるようにした。そうすると、ChipScopeのトリガは最初の水平描画信号のスタートでかければ良いことになるからである。つまりディスプレイの枠と液晶表示画面のふちの境界の白く飽和している部分が左上端にある画像ということになる。
これをChipScopeでみたのが下の図になる。
cam_ydata_2d がCMOSカメラから来たデータとなる。r_w が0の時がYUVのうちのY（輝度信号）が出力されている。その部分をピンクの四角で囲んである。それは、VSYNCが来てから最初のHREFが1になった時の最初のデータから35個目のデータだ。そのなかで輝度データを見ると、86, FF, FF, 00, 00, 35, 35 となっていて、FFから00に飛んでいる部分がある。やはり、この部分が問題だと思う。CMOSカメラに原因があるようだ。
これは、SCCBバスのコントローラをやはり、早急に開発してCMOSカメラの設定をいじってみる必要がありそうだ。
＃そういえば、デバックの過程でRGBの飽和演算を外してみた。その時は、蛍光灯やその辺の輝度が高いところが黄色になった。黄色は赤と緑の混合色なので、青が飽和しているようだ。つまり青は飽和しやすいと思う。それは計算式を見ても言えるのではないだろうか？
（追記）
”
CMOSカメラから画像を入力してディスプレイへ出力１５（できた！！！） ”の下の画像は、輝度の変化が大きいところでも正常に表示されている。（でも、うっすらと見えるのかな？少なくとも、はっきりは分からない）
これは、基板も違うが、CMOSカメラもKBCR-M03VG (OV7760)だった。ここで使っているCMOSカメラは、KBCR-M04VG (OV7725)。
もし何か情報があれば、ぜひ教えて下さい。よろしくお願いします。
2009年12月11日 04:51 |
画像処理
| トラックバック:0
| コメント:15
コメント
いつもお世話になっております。
データの内容を見ると8bitで処理されているのですね。
カメラは10bitデータのようですが、MSB側8bitを使用されているのでしょうか？（カメラはデフォルトが10bitで8bitに設定可能？）
10bit中、LSB側8bitを使用されているのであれば辻褄が合いそうな気がします。
2009/12/11(金) 13:48:59 |
URL |
takepon256 #-
[ 編集 ]
takepon256さん、こちらこそ、いつもお世話になっております。
残念ながら、ちゃんとYUVデータ出力(bit9)～YUVデータ出力(bit2)までを入れているはずです。7 downto 0のデータですが、9 downto 2 のカメラデータにUCFでマップしてあります。
entityのカメラのデータ入力が下です。
cam_ydata : in std_logic_vector(7 downto 0); -- CMOSカメラからのYデータ
UCFの設定が下です。
NET "cam_ydata<0>" LOC = "V2" ;
NET "cam_ydata<1>" LOC = "U5" ;
NET "cam_ydata<2>" LOC = "U6" ;
NET "cam_ydata<3>" LOC = "U8" ;
NET "cam_ydata<4>" LOC = "V4" ;
NET "cam_ydata<5>" LOC = "V8" ;
NET "cam_ydata<6>" LOC = "R7" ;
NET "cam_ydata<7>" LOC = "T7" ;
回路図がこれです。
http://www.esp.co.jp/products/CQBB_IMG/cqbbimg.pdf
合っているはずなんですけど。。。
それに輝度の変化が大きいところというのが、おかしいような気がします。輝度の高いところでサチるのならば、わかるんですけど。。。
2009/12/11(金) 14:22:28 |
URL |
marsee #f1oWVgn2
[ 編集 ]
うーん、いや、CMOSカメラとかCCDもそうですけど、出力って結構いい加減ですよ。ノイズも大きいですし。それこそ一台100万以上もする放送用カメラで、これだというのならクレームものですけど。1個の原価数100円レベルなら、まあ、この程度かも知れません。
2009/12/12(土) 00:14:36 |
URL |
くり #mQop/nM.
[ 編集 ]
くりさん、こんにちは。
しょうがないかもしれないですが、もうちょっとゲインを落とすとかすると改善されるのでは？と思っています。ダメだっら、古いCMOSカメラ、KBCR-M03VG (OV7760)を購入できれば購入ですかね？
2009/12/12(土) 05:57:27 |
URL |
marsee #f1oWVgn2
[ 編集 ]
はじめまして。
Yデータを見ると0x0～0xFFの範囲で演算しているため飽和しやすいのではないのでしょうか？
Yデータを0x10～0xEBの間に変換するか0x0～0xFFに対応できるように演算を変更したほうがよさそうな気がします。
カメラにYの出力範囲0x10～0xEBを指定するレジスタは無いでしょうか？
また、輝度が0xFFから0x0になっているところを見るとカメラ内でsharpnessがかかっているような気がします。
ノイズ除去のためにaverage filterを掛けてボケさせた後、はっきりさせるためにsharpnessを掛けている可能性はありますね。
そのようなレジスタはありますか？
あるいはカメラのYCbCr演算があまりよくないかもしれませんね。
2009/12/15(火) 20:59:20 |
URL |
frafra #-
[ 編集 ]
frafraさん、こんにちは。
貴重なアドバイスありがとうございます。
アドレスACのbit5にSharpness (edge enhancement) auto strength control というビットがあるので、これを解除しようと思います。まだ、レジスタを設定する回路を作成中のなので、できてからやってみます。
輝度データの値の範囲は新、旧カメラとも一緒なので、とりあえずSharpness から先にやってみたいと思います。
2009/12/16(水) 05:45:12 |
URL |
marsee #f1oWVgn2
[ 編集 ]
もしかすると、ChipScopeのFF、00は ITU-R BT.601 の同期信号ではないでしょうか？
エッジの白飛びの原因までは分かりませんが・・・
2009/12/16(水) 22:04:14 |
URL |
takepon256 #-
[ 編集 ]
こんにちは。takepon256さん。お世話になっております。
ITU-R BT.601はテレビの規格ですよね？このビデオカメラは24MHzを入れるので、違うのでは？と思っています。データはYUYVというフォーマットで出てくるようです。画像は綺麗に写っていますが、エッジがかなり強調されている状態です。これが修正できれば問題は無いですが。。。
2009/12/17(木) 06:07:29 |
URL |
marsee #f1oWVgn2
[ 編集 ]
データシートが見れないのでどこまで本当なのか分かりませんが、こちらのカタログによるとKBCR-M04VGのYUV422はITU-656規格となっています。
http://www.shikino.co.jp/oosaka/pdf1/KBCR081107.pdf
ですので00とFFのところはSAV（もしくはEAV）だと思うのですが、いかがでしょうか？
2009/12/17(木) 10:38:20 |
URL |
takepon256 #-
[ 編集 ]
takepon256さん、こんにちは。
ITU-656規格はよくわからないのですが、下のサイトを見ると、SAVは映像信号の初めの時のブランク部分、EAVは映像信号の終りのブランク部分に入っているようですね。
http://arx.ee.utsunomiya-u.ac.jp/azlab/members/sinsaku/old/itu656.html
http://blog-imgs-35-origin.fc2.com/m/a/r/marsee101/YUV_RGB_conv_19_091211.png
上の図に示したタイミングではすでに映像信号が来てしまいっています。それはcam_hre... が1になっていることでわかります。
この辺のタイミングは下のタイミングチャートに書いてあります。
http://blog-imgs-36-origin.fc2.com/m/a/r/marsee101/YUV_RGB_conv_2_091128.png
なお、データシートはWeb上にOV7640のしか落ちていませんが、OV7725もだいたい、OV7640と一緒です。フレームは違います。レジスタも違いますが、HREFが1の時にYUVのデータが出ているのは一緒です。
http://www.alldatasheet.jp/datasheet-pdf/pdf/121707/ETC/OV7640.html
Figure 5 Row Output Timing Diagram などです。
従って、ITU-656規格のSAV, EAVとは違うのではないか？というのが私の意見ですが、いかがでしょうか？
2009/12/17(木) 11:09:35 |
URL |
marsee #f1oWVgn2
[ 編集 ]
なるほど…。
OV7640のデータシートを読むとデフォルトでは0x01～0xFEまでしか出力しないようにも見えるのですが、ITU-656を調べてみると00,FFが同期信号と仮定してもビットの並びからしてEAVになってしまうのでHREF論理と辻褄が合わなさそうです。
やはり自動で変にフィルタがかかっている線が有力ですかね。
役に立たない（逆に混乱を招いてしまうような）情報で申し訳ありませんでした。
2009/12/17(木) 19:00:50 |
URL |
takepon256 #-
[ 編集 ]
takepon256さん、いつもありがとうございます。
いつもアドバイスしていただいて、感謝しています。
OV7725のマニュアルの15番地COM10のOutput data range selection が0でFull range になっています。
1にするとData from [10] to [F0]になります。今のところ、SCCBレジスタに設定する回路を作成中です。
2009/12/17(木) 20:38:44 |
URL |
marsee #f1oWVgn2
[ 編集 ]
話しを蒸し返すようで申し訳ないのですが、BT.656のタイミングコードはUYVYに連続して現れます。Yにのみ現れるということはありません。
また最近のCMOSセンサーはクロック周波数に関係なくH/VSYNC信号の代わりにBT.656のタイミングコードで同期するものが多いです。これは個人で購入できるようなモジュールで販売されることは少ないと思いますが・・・
2009/12/17(木) 22:18:55 |
URL |
frafra #-
[ 編集 ]
こんばんわ。
＞BT.656のタイミングコードはUYVYに連続して現れます。Yにのみ現れるということはありません。
？？？なのですが、
http://documentation.renesas.com/jpn/products/mpumcu/apn/rjj06b1003_sh7262_sh7264ap.pdf
の図５のような感じ？
RGBから、どうYCbCr変換してるのかっていうのも問題かと思いますが（RGBは同一点のデーターでないため）、シャープネス自動調整で白飛びしちゃう性能っていうのも、まあ、あれかと・・・。
2009/12/18(金) 01:20:58 |
URL |
くり #mQop/nM.
[ 編集 ]
こんばんは。
はい、その図のようになります。
Bayerの状態でいろいろフィルタをかけて、最後にYUV変換でしょうか。
補間はさすがにNearest neighborはないと思うのでBilinearでしょう。
2009/12/18(金) 22:42:23 |
URL |
frafra #-
[ 編集 ]
コメントの投稿
トラックバック URL
https://marsee101.blog.fc2.com/tb.php/1319-bc87ad46 この記事にトラックバックする(FC2ブログユーザー)
