きまぐれライダー日記

OpenCV1.0でのお話．

MFC上でOpenCVを描画する方法は，あまり紹介されていない気がする．
カットシステムから出版されている「実践OpenCV」では
IplImageの画像データ領域に，BITMAPINFO等を付けて
DIB形式とし，StretchDIBitsメソッドでDCに対して描画を行う方法を紹介している．
手法としては間違ってはいないが，正直面倒である（笑）

※ DIB（デバイス独立ビットマップ）
メモリ上の任意の領域をRGB形式（またはカラーテーブルで指定される色の配列）の画像データを格納した
ビットマップ（フレームバッファ）として扱い、画面などに描画する機能

あまり知られていないが，OpenCVには
C++用にIplImage構造体をラッピングしたCvImageクラスが存在する．
その中でも，CvvImageクラスはWindowsのGDIをサポートしており，
DCに対して描画を行う事が出来るという素晴らしさ！！
画像のリサイズも自動で行ってくれるため，コードの無駄をかなり減らす事が出来，
ダブルバッファリングを組み合わせればほぼ完璧！？

実際の使い方としては，以下の通り．

// 画像データを既に保持している IplImage* m_img がDocumentクラスに定義済みと仮定
void C**View::OnDraw(CDC* pDC)
{
	// TODO: ここに特定なコードを追加するか、もしくは基本クラスを呼び出してください。
	CAttitudeEstimationDoc* pDoc = this->GetDocument();
 
	// 描画対象の領域サイズを取得
	CRect rect;
	GetDlgItem(ID)->GetClientRect(&rect);
 
	CvvImage cvvImage;
	cvvImage.copyOf(pDoc->m_img);
	cvvImage.DrawToHDC(pDC->GetSafeHdc(), &rect);
}

このCvvImageクラスには，DrawToHDC()メソッドの他にShow()メソッドもある．
正直，GDIを扱う人であればhighgui.hにあるCvvImageクラスの定義を読めば理解出来るハズ．

注意すべき点としては，cvvImageクラスをCImageクラスとして定義しているため，
ATLのCImageクラスと名前が被ってしまう点であろう．
同時にATLのCImageクラスを扱う場合は，ATLのCImageクラスの名前を別の名前に定義し直す方が良いと思われる．

記事の続きにhighgui.hのCvvImageクラスが定義されている箇所を提示しておく．
続き▽

本日、オイル交換を行った。

自分でオイル交換をしようと思っていたが・・・
いつも行く「しゃぼん玉」が、毎月0日はオイル交換工賃0円であったため作業をお願いした。

前回入れてたオイルはWAKO’Sの4CR 10W-40だったが
最近、RESPOのオイルが良い意味で期待を裏切ってくれていたため、RESPOのR-TYPEを入れる事にした。
なお、R-TYPEのオイル粘度の設定は10W-50しか無いそうだ。
更にオイルフィルター交換タイミングだったため、
マグネット入りのものにしようと思ったが・・・売り切れのため、標準タイプを購入。
そして、SUPER ZOILを250ml投入（笑）

ちなみに、サービスマニュアル上でのオイル交換量は以下の通り。
・ オイル交換 ： 3.0L
・ オイル＋フィルター交換 ： 3.3L
・ オーバーホール時 ： 3.6L

交換した物をまとめると以下の通り。
・ RESPO R-TYPE (10W-50) 約3.0L
・ SUPER ZOIL 250ml
・ kijima オイルフィルター（標準タイプ）
・ アルミドレンワッシャー（M14）

そして、作業をお願いする際に、抜いたオイルの目視確認をお願いしておいた。
作業はお願いしていても、やはり自分の目でバイクの状態を把握する必要がある。

作業が終わるまでの間、仲の良い店員さんと雑談して時間を過ごし
車両の受け渡しの際に、予定通りオイルを確認させて頂いたが
鉄粉が紛れ込んでいる感じは無く、状態としては良い感じ。

エンジンを掛けてみて、メカニカルノイズの感じに驚く。
刺々しいメカニカルノイズが減って、全体的に丸みの帯びたメカニカルノイズとなっていた。

SUPER ZOILが凄いのか？それとも、RESPOのオイルが凄いのか？

とりあえず、前者であることを願いつつ、乗って帰ってきたが、
エンジンのレスポンスは、荒々しさが消えているような感じで確実に良くなっている。

そのまま走りに行きたくなるエンジンとなった。（寒いから諦め



次回オイル交換は、状態が良かったため
3,000km～2,500kmで行うとして、58,000kmを目安とする。
そして、次回こそは自分でやろうと思う。

正直，研究でのプログラムはMFCで開発することはあまり無い．
ただ，計算値の監視とかするのにコンソール出力では
流れてしまってあまりにも現実的では無い時や
形として残しておきたい時はMFCを使う．

で，久しぶりにMFCのDocument-Viewerアーキテクチャーを使って開発してみたところ
ツールバーのグリップ部分がちゃんと描画されないバグに出会った．
過去に修正した事はあるが，覚え書きとして以下に記載しておく．

CMainFrame::OnCreate()のツールバーを作成している部分を修正

以下の部分を

if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE
    | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS 
    | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) ||
    !m_wndToolBar.LoadToolBar(IDR_MAINFRAME))
{
    TRACE0("Failed to create toolbar\n");
    return -1;      // 作成に失敗
}

以下の通りに修正

if (!m_wndToolBar.CreateEx(this, 0, WS_CHILD | WS_VISIBLE
    | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS 
    | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) ||
    !m_wndToolBar.LoadToolBar(IDR_MAINFRAME))
{
    TRACE0("Failed to create toolbar\n");
    return -1;      // 作成に失敗
}
// TBSTYLE_FLATを改めてセット
m_wndToolBar.ModifyStyle( 0, TBSTYLE_FLAT );

ソース
・ 気まぐれソフトハウス >> VC++6.0でXPビジュアルスタイルを使うには

先週末の話。
台風18号が過ぎて、台風一過という事で晴天だったため
久しぶりにサスセッティングをしようと矢作ダムに行ってきました。

で、早速結論。

台風直後の峠には走りに行くものではない！

吹き溜まりというか・・・道路の上は落ち葉だらけで
まともに走ることさえ難しい（＾＾；
そんな中、とりあえずダムまで行ってきました。

そして、ダムにて
日頃からリアサスが高速時に落ち着かない感じがしていたため
もうちょっと圧側の減衰を強めようと思い、圧側の調整ノブを回したところ・・・

「あら？カチカチ感が明らかにおかしいｗｗｗ」

回しても回しても、一向に止まらない・・・これはまずい
状況が状況なため渋々峠を安全運転で帰宅。


で、昨日調べてみたら・・・アジャストノブなめてました。
まぁ 樹脂 v.s. 金属 じゃあ仕方ないだろうし
下手に硬いノブなんかついてたら、減衰調整を回し過ぎでぶっ壊しそうだから
こういう仕様なんでしょうな（笑

まぁプラリペアと型取り君で直すとして
悪戯された可能性が高いな・・・大学で。


圧側減衰はあまり調整しないから、ノブごと取り外しておくのも手かな。

先週あたりから自分のドメインに
またアクセス出来なくなっていました。

原因はDynamicDNSUpdateClientであるDiCE for Linuxが更新せずに止まっていました。
（今までの経験上2ヶ月ぐらいすると止まっている様な気がする・・・。
とりあえず、DynamicDNSが更新されないことには
外部からアクセスする事が出来ないため
安定化のためにcronを使って毎週DiCEを再起動するようにしました。

ついでに、メモリを512MB増設して
１GBにしたため、スワップメモリをほとんど使用しなくなりました。
（メモリの消費量の原因は、ウィルス対策ソフトなんですけどね・・・

これで改善されなければ、また考えようっと（笑