양고네 연구노트

처음에 OpenCV 2.0 빌드라고 잘못 제목을 적었으나, 결국 1.1 재설치로 밝혀짐 ㅜㅜ

프로그램 → OpenCV → OpenCV Workspace MSVC6를 열어 batch build 하면 된다고 하나 빌드 중에 VC6가 멈춘다.
VC6 자체가 맛이 간 것 같아서 일단 VC6 SP5를 깔고...
그 다음은 순차대로 전부 빌드.

cvd.lib와 cxcored.lib 등은 배치 빌드 과정에서 생성되었고,

highguid.lib 빌드
  libjasperd.lib 빌드 (C:\Program Files\OpenCV\otherlibs\_graphics\src\libjasper)
  마찬가지로 libjpegd.lib, libpngd.lib, libtiffd.lib, zlibd.lib를 빌드.

빌드는 모두 VC6만 사용했고, 일단 잘 되는 것 같다.

그런데...
원래 있던 facedetect 데모가 실행이 안 된다.
highgui110.dll이 없단다. 아마 아까 배치빌드 과정에서 버전 충돌로 파일 몇 개를 지웠는데, 그 안 에 포함됐나보다.
어쩔 수 없이 C:\Program Files\OpenCV\otherlibs\highgui에 있는 highgui 프로젝트를 다시 열어서 active configuration을 release로 바꿔서 컴파일 - 에러. 아까의 잡 프로젝트들을 전부 다시 컴파일해줘야 한다.
libjasper, libjpeg, libpng, libtiff, zlib를 모두 release로 빌드하고 다시 highgui.lib를 빌드 - 성공.

그런데 facedetect.c 내용을 복사해서 빌드한 테스트 프로젝트는 실행이 되지 않길래 보니...

의외로 classifier 관련하여 xml 파일을 불러오는 부분이 있었다.

아마도 Haar feature로 cascade를 구성하기 위한 데이터가 들어있는 듯하다. 자세한 내용은 조사할 시간이 업ㅂ다!~~

매뉴얼 일부 발췌:
The whole hierarchy can be constructed manually or loaded from a file using functions cvLoadHaarClassifierCascade or cvLoad.

해당 폴더 설명:
haarcascades - the folder contains trained classifiers for detecting objects
               of a particular type, e.g. faces (frontal, profile), pedestrians etc.
               Some of the classifiers have a special license - please,
               look into the files for details.
오오... 다른 것도 있다. 예제에서는 haarcascade_frontalface_alt.xml과 haarcascade_eye_tree_eyeglasses.xml 두 개가 사용됨.

어쨌든, 결과는 나쁘지 않다.

마지막으로, cvaux110.dll 또한 문제가 되었는데, cvaux를 빌드하려면 다음과 같은 에러가 발생한다.

이는 다음과 같이 정의돼있는데, 굵게 표시한 글자깨진 부분이 문제이므로 수정하자.

 opencv를 이용한 최소 캡처 프로젝트를 첨부하니 잘 활용하도록 하자!

얼마전부터 도무지 이놈의 랩톱이 대기모드로 갈 생각을 않는다.
하는 일도 없이 몇 시간 째 열을 내며 켜져있는 노트북을 보며, 환경을 생각하는 '녹색삽질'이 정부의 모토인 만큼 나도 한삽을 떠야겠다는 생각이 들었다.

Xnote 자료실에서 최신 드라이버로 업데이트...할려고 했으나 이미 최신 드라이버 상태이고, 네입어 Xnote 동호회를 다 뒤졌으나 비슷한 증상은 찾을 수 없었다.

비스타가 하도 뷁스러워서 XP로 다운그레이드한 것이 원인인가... 하며 나의 첫 녹색 한 삽을 포기할 찰나,
이 놋북은 비스타에서도 대기모드 진입이 안 되었던 사실이 뇌리를 스쳤다.

이런 경우와 관련하여 마이크로소프트에서 하는 이야기는 http://support.microsoft.com/kb/310601 와 같이 CPU가 10% 이상 점유중일 가능성이 있다는 것인데, 작업관리자를 보면 왔다 갔다 하지만 대체로 5% 정도.

마지막으로 구글 데스크톱을 죽여봤더니? 오호~ 설정해놓은 시간인 1분 만에 잠든다!
구글 인덱싱도 죽여놨는데 가젯들 중에 뭐가 그리 많이 차지할래나?
확실하진 않지만 범인은 저 LaptopCheck (0.8e - 이미지는 개발자 홈페이지에서) 인 것 같다. refresh rate를 10초로 하니 예정 시간에 바로 대기모드로 진입했다. 그런데 네트워크 모니터링이 정확하지 않은 것 같긴 하다. 이건 적절한 타협점을 찾아야 할 듯...


어쨌든 나도 첫 녹색 삽을 떠서 뿌듯하다.^^

처음에는 플래시가 작동하지 않았다.
그 자체가 바이러스 같은 거머리 맥아피를 삭제하면서 이것저것 마구 지워버린 것이 문제였다.
플래시를 제거 - 설치 반복하길 수 차례, 결국 플래시 자체가 아닌 자바스크립트가 동작하지 않는 것을 알았다.
IE를 6,7,8 버전 별로 지우고 새로 깔고 했지만 스크립트 사용 불가 현상은 그대로... 스크립트 엔진이라는 것이 있다면 IE 내부가 아닌 윈도에 설치된 것으로 판단됐다.

그러나 이 스크립트 엔진에 해당하는 것을 도저히 찾을 수가 없어서 결국 포맷 밖에 답이 없나 하는 고민에 빠졌을 때 (업무 때문에 도저히 포맷과 그 수많은 어플들 설치는 감당할 수 없는 상황), 다음의 링크를 찾게 되었다.

Windows Script 5.6 for Windows XP and Windows 2000

이걸 깔면 된다.

디버깅이 아예 안 되는 것은 아니고, '자동'이나 '조사식'에서 보여야 할 변수가 보이지 않는 상황일 때,



.ncb  파일을 삭제하고 rebuild all 해도 효과가 없다.
여러 옵션 조정 끝에 얻은 해결책은, 프로젝트 속성 > 구성 속성 > C/C++ > 최적화 옵션에서 /O2 (속도최대화) 를 /Od (사용 안 함)으로 바꾸는 것이다.

OpenCV에서 간단한 이미지 로드와 표시조차도 안 되는 걸 보면 魔가 끼었나보다... -_-

(추가) 최적화 시 디버그가 제대로 되지 않는 이유는, 최적화를 위해 코드에 변형을 가하기 때문으로 생각된다. 원래 디버그모드에서는 최적화가 off되어 있었어야 하는게 아닌가 하는 생각이 들지만.
어제 밤부터 오늘 오전까지 이어진 OpenCV 삽질의 전말은 다음과 같다:

1. 처음에 cv에서 이미지를 로드했는데, 이미지 포인터가 null이었다. 이 때문에 경로를 재차 확인하고 이미지 파일의 포맷을 바꾸는 등 삽질을 했지만 무효.
2. 그리고 디버그를 하다 보니 위의 문제가 발생하여 디버거에 뭔가 문제가 있음을 알았다. 즉 cvLoadImage 후에 이미지 포인터가 null로 설정됐던 것도 알고 보면 디버거의 문제였다!
3. VS 2005에서 프로젝트 속성의 최적화를 off하여 디버거 문제 해결.
4. 이제 이미지는 제대로 load되나 여전히 cvShowImage는 효과 없음.
5. 원인은 마지막의 getchar()로, 대신 cvWaitKey(0); 를 사용해야 한다. cvShowImage의 화면 그리기 구현과 관계가 있을 것으로 추정된다.

즉 문제의 원인에 디버거 부분과 cvWaitKeys 부분이 함께 있었기 때문인데, 이럴 경우 가장 힘든 troubleshooting이 되는 것 같다!

일부 DirectShow 필터 제조자들이 리버스엔지니어링을 막기 위해 디버깅을 차단하는 것으로 생각된다.
이 때문에 디버거를 사용하지 못해 프로그램 디버깅에 중대한 애로사항이 꽃피게 되었다.

dshow질 중 위와 같은 에러가 뜬다면...
닥치고 네로7을 삭제하자.
네로7과 연루된 필터를 쓰든 말든 상관 없는 것 같다.

네로7을 삭제했음에도 디버거를 사용하지 못할 경우, 콘솔창을 이용하여 디버거 흉내를 내는 방법이 있다.
MFC 프로그램에서 std::cout이나 printf 등을 쓰고 싶다면, 다음의 코드를 App의 InitInstance에 집어넣는다.

#include <iostream> #include <io.h>    AllocConsole();    int outHandle;    FILE *outFile;    outHandle = _open_osfhandle((long)GetStdHandle(STD_OUTPUT_HANDLE), 0x4000);    outFile = _fdopen( outHandle, "w" );    *stdout = *outFile;    setvbuf( stdout, NULL, _IONBF, 0 );    std::cout.sync_with_stdio();

나중에 FreeConsole을 한번 해줘야 하는 듯하지만... 문제가 되기 전에는 그냥 대충 쓰는... -_-;
다음과 같이 콘솔창을 활용할 수 있다.

결국 프로젝트 속성 - 링커 - 디버깅에서 '디버그 정보 생성' 옵션이 '아니오'로 되어 있는 것을 발견, '예'로 바꿔 주었다. 도움을 주신 Shadow Jeon에게 감사...


그러나 저 프로젝트 만료 대화상자는 여전히 빌드할 때마다 나타나는데, 그냥 표시 안 함에 체크하면 될래나??

증상: Maya 2008에 포함된 plug-in wizard를 VS 2005에 사용할 경우 에러가 발생하며 프로젝트가 생성이 되지 않음

원인: VS 2005의 path를 인식하지 못하기 때문으로 추정됨

해결방법: MayaPluginWizard.vsz에 다음 행을 추가:

Param="ABSOLUTE_PATH = C:\Program Files\Microsoft Visual Studio 8\VC\VCWizards\MayaPluginWizard"

(추가)

다음의 wizard 버전도 8.0으로 바꿔 주어야 한다.

Wizard=VsWizard.VsWizardEngine.8.0

(또 추가)

위의 path가 아니라 (추가)의 VsWizards 버전이 문제인 것으로 밝혀짐. path는 없어도 되는 것으로 밝혀졌다. ㅜㅜ

 

 

word에서 작업 파일을 만들 수 없습니다. 임시 환경 변수를 확인하십시오.

이 지긋지긋한 에러를 경험한 건 2007년말 쯤 빠른 파일 입출력을 위해 램디스크를 설치한 후부터이다. 좀 더 정확하게 말하자면, 램디스크를 제거한 후부터라고 해야겠다.

처음 램디스크를 설치한 목적은 SD급 라이브 비디오를 마야 텍스쳐에 빠른 속도로 입히기 위한 것이었다. 그러나 램디스크 소프트웨어를 두어 개 써본 후에는, 악랄한 윈도 XP의 디스크 읽기/쓰기(특히 csrss와 lsass)를 조금이라도 줄여보고자 하는 마음에 시스템의 Temp 폴더를 램디스크로 설정하여 사용했다.

512MB(특정문자열이 포함되어 정부로부터 조사를 받을지도?) ~ 1GB 정도를 할당하여 사용하다 보니 결국 Temp 저장소가 모자라기도 하고 여러 가지 문제가 발생하여 결국 서너 달 사용 끝에 램디스크 사용은 포기하게 되었다.

그러나 램디스크를 언인스톨한 이후 알 수 없는 에러에 빠지게 되었는데, 처음에는 아웃룩이었다. 아웃룩에서 작업 파일을 만들 수 없다는 메시지...
이것이 실은 아웃룩이 편집기로 사용하는 워드 때문이라는 사실을 알아내는데도 꽤 걸렸다 ㅜㅜ

결국 문제는 워드와 램디스크로 설정해놓은 Temp 폴더라는 심증은 있었으나 시스템의 Temp 폴더를 원상복구하는 것만으로는 해결되지 않았다.

언제나 해답을 제시하던 Microsoft의 knowledge base도 이번에는 삽질만을 크게 가중시켰고...

결국 인터넷에서 찾은 해결책은 어이없게도 Explorer와 관계된 레지스트리를 편집하는 것이었다.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders/Cache

위 폴더에 램디스크 경로가 남아있었고 이걸 실재하는 경로로 바꿔주면 된다.

그런데 웃긴 것은 회사 컴 뿐 아니라 집에서도 램디스크 때문에 똑같은 문제가 발생했고, 집 컴에서는 오피스를 거의 쓰지 않던 나는 위 솔루션을 기억에서 지워버린 것이다.

다시 인터넷 검색질 끝에 해당 레지스트리를 찾아냈지만 이번에는 멍청하게 "User Shell Folders"가 아닌 "Shell Folders" (이것도 있다) 를 편집한 나... 이건 백날 바꿔봐도 먹힐리가 없고 워드놈이 실행되면서 해당 레지스트리 값을 비워버린다. 또 한번의 눈물겨운 삽질 끝에 "User"를 붙여서 이 워드 작업파일 삽질극은 대단원의 막을 내리게 되었다.

긴 시간 나를 괴롭힌 문제를 기록해놓지 않으면 언제 또 당할지 몰라서... 이렇게 남긴다.

POINTER_64가 정의되지 않아서 생기는 에러인 듯하다.
winnt.h에 다음 한 줄을 추가하면 해결된다.

#define POINTER_64 __ptr64 // 추가
typedef void *PVOID;
typedef void * POINTER_64 PVOID64;

그 외 잡다한 변수선언 관련 컴파일에러들은 Microsoft가 지키지 않던 C++ scope 관련 표준들을 최근에 와서 지킴으로써 발생하는 것들이 많아보인다.
무조건 선언해주도록 하자. -_-

몇 번 씩 당했던 문제들이지만 그 솔루션을 외우고 있지는 않고... 다행인 것은 다시 구글에서 찾는 시간이 매번 조금씩 짧아져간다는 것이다. ㅜㅜ

결국 DirectShow 관련 일은 개발환경 세팅이 반이라는 결론에 다다른다 (뭐 다른 일들도 크게 다르지 않지만).