이재만 교수의 공간

앞으로 사용될 기본 코드이다

Visual Studio 2010을 사용했다

Console Application을 사용했고

Empty Project이고 Unicode에서 구현한다

다음 소스는 기본 틀이다

맨 위의 주석 두 줄은 GPL License의 기본 틀이다

OpenGL 기본 세팅은 생략한다 다른 사이트를 참고하기 바란다

크게 다른 프로그램을 만들지 않는 한 Region 으로 구분, 코드를 추가한다

다음은 실행 결과이다

코드와 일치시켜서 알 수 있는 것은

4-3과 4-4의 코드가 적용 되었다는 것을 확인

4-3 윈도우 사이즈가 800 x 600 이다

4-4 윈도우 타이틀 제목이 "OpenGL Basic Code Window~~!!" 이다

4-8 은 GLUT 프레임 워크를 실행하는 기능이다

4-5는 화면의 사이즈가 변할 때 호출되는 콜백함수(ChangeSize)를 등록한다

4-6은 화면이 그려질 때 호출되는 콜백 함수를 등록한다

다음에 할 일은 창에 나타난 부분이 배경화면인데

이 부분을 지우는 부분을 구현하도록 한다

즉 창 바탕 화면을 원하는 색으로 칠해보도록 하자

* 프로그래밍 연습

1. 윈도우 사이즈를 400 x 200으로 수정해보자

2. 윈도우 타이틀 제목을 "Hello, World"로 바꾸어 보자

5년 만에 제대로 다시 자료를 정리하고 어느 정도까지 기술을 오픈하고

라이센스를 걸어야 할 지 모르겠다

상업적으로 많은 돈을 벌 수도 있고

GPL로 오픈 하자니 상업 쪽에서 안 쓰면 활용 가능성이 없을 수도 있고

BSD로 하자니 막 갖다 쓸 수도 있고 해서

우선 GPL 라이센스로 오픈하고 정말 상업적으로

필요하신 분들은 lividious@naver.com 으로 연락주시면

BSD 허가 여부를 알려 드리겠다

그리고 대부분은 핵심 코드만 올려놓거나 추상적으로 이론만 올려 놓으면

아무 도움도 안 되고 공부도 안 된다

물론 머리 좋은 사람은 단박에 알아낼 수 있지만 나 같은 사람은

그렇지 못하다

소스 코드만 올려 놓는다.

다이얼로그나 솔루션은 알아서 하시고

그러나 너무 복잡한 프로그램일 때는 같이 올려 놓는다

OpenGL, OpenCV, CUDA, Image Processing, Augmented Reality, 3D Reconstruction 에 관해 일단 자료 정리 하고

도전 분야는 Network Programming, Pattern Recognition, 동영상 프로그래밍에 관해 할 생각이다

추가 분야로는 리눅스, C#이 될 것이다.

다시 열심히 하자

Code Craft 요약 – 좋은 프로그래머 나쁜 프로그래머

1.    방어하기

l  좋은 프로그래머

-      자기 코드가 튼튼한지 신경을 씁니다.

-      모든 추측을 방어적 코드안에 명시적으로 캡처해서 표현합니다.

-      가비지가 입력되었을 때에도 잘 정의된 동작이 실행되기를 원합니다.

-      코드를 작성하면서 그 코드에 대해 신중히 생각합니다.

-      다른 사람의 어리석음으로부터 코드가 자신을 보호하도록 작성합니다.

l  나쁜 프로그래머

-      자기 코드 안에서 잘못된 일이 발생할 수도 있다는 사실을 생각하고 싶어 하지 않습니다.

-      고장을 일으킬 수도 있는 코드를 통합하라고 내주고, 다른 사람이 대신 정리해 주기를 바랍니다.

-      코드의 사용법에 대한 중요한 정보를 자기 머리 속에만 넣어둠으로써, 쉽게 잊어버릴 수 있게 합니다.

-      거의 생각을 하지 않고 코드를 작성하기 때문에, 결국 예측할 수 없고 신뢰할 수 없는 소프트웨어를 만듭니다.

2.    최고의 레이아웃 계획

l  좋은 프로그래머

-      무의미한 논쟁을 피하고, 다른 사람들의 의견에 예민하게 신경을 씁니다.

-      겸손해서 자기가 항상 옳지 않다는 것을 압니다.

-      코드 레이아웃이 가독성에 얼마나 영향을 미치는지 알고, 가능한 한 명료한 코드를 작성하기 위해 노력합니다.

-      자기의 개인적인 기호와 다르더라도 하우스 스타일을 채택할 것입니다.

l  나쁜 프로그래머

-      마음이 닫혀 있고 고집이 셉니다.

-      아주 사소한 일을 가지고도 아무하고나 싸움을 합니다.

-      개인적인 코딩 스타일에 일관성이 없습니다.

-      다른 사람의 코드를 자기 스타일을 가지고 짓뭉갭니다.

3.    이름이 뭐길래

l  좋은 프로그래머

-      이름이 중요하다는 것을 알고, 이름을 소중히 다룹니다.

-      이름을 어떻게 만들지에 대해서 생각하고, 자기가 생성하는 모든 것에 적절한 이름을 붙입니다.

-      이름의 길이, 명료성, 콘텍스트 등과 같은 힘들의 균형을 맞춥니다.

-      더 큰 그림을 바라보고, 한 프로젝트 전체에 걸쳐서 자기가 만든 이름들이 조화를 이루게 만듭니다.

l  나쁜 프로그래머

-      자기 코드의 명료성에 대해 거의 신경 쓰지 않습니다.

-      일회서 코드를 생성합니다.

-      언어 고유의 관용구를 무시합니다.

-      이름을 짓는데 있어서 일관성이 없습니다.

-      전체론적으로 생각하지 않습니다. 자기가 만든 코드가 전체와 어떻게 맞물리는지 생각하지 않습니다.

4.    문서화 도구

l  좋은 프로그래머

-      스스로 문서화하는 명료한 코드를 작성하기 위해 노력합니다.

-      꼭 필요한 최소 분량의 문서를 작성하기 위해 노력합니다.

-      자기 코드를 유지보수할 프로그래머가 무엇을 필요로 할지 생각합니다.

l  나쁜 프로그래머

-      이해가 불가능한 스파케티 코드의 작성을 자랑스러워합니다.

-      어떤 문서 작성도 안 하려 듭니다.

-      문서의 업데이트에 신경을 쓰지 않습니다.

-      이런 생각을 합니다. “내가 작성하기 힘든 코드는 다른 사람도 이해하기 힘들어야 돼”

5.    가벼운 코멘트

l  좋은 프로그래머

-      정말 훌륭한 소량의 코멘트를 작성하려고 노력합니다.

-      왜에 대해서 설명하는 코멘트를 작성합니다.

-      과도한 코멘트가 아니라 좋은 코드의 작성에 집중합니다.

-      의미 있는 유용한 코멘트를 작성합니다.

l  나쁜 프로그래머

-      좋은 코멘트와 나쁜 코멘트의 차이를 모릅니다.

-      어떻게에 대해서 설명하는 코멘트를 작성합니다.

-      코멘트가 자기에게만 의미가 통해도 개의치 않습니다.

-      잘못된 코드를 많은 양의 코멘트로 보강합니다.

-      쓸데없이 중복되는 정보로 소스 코드를 채웁니다.

6.    사람은 실수를 하기 마련

l  좋은 프로그래머

-      자신의 좋은 의도를 좋은 코딩 습관과 결합시킵니다.

-      에러 처리 코드도 주된 코드를 작성할 때처럼 작성합니다.

-      코드를 철저히 작성해서 모든 에러 가능성을 커버합니다.

l  나쁜 프로그래머

-      자기가 하는 일에 대해 생각이나 검토를 하지 않고, 되는대로 식의 접근 방법으로 코드를 작성합니다.

-      코드를 작성하는 도중에 발생하는 에러를 무시합니다.

-      처음부터 에러 상황을 고려하는 일이 절대 없기 때문에, 나중에 고장 난 부분을 찾아서 오랜 디버깅 작업을 하게 됩니다.

7.    프로그래머의 도구 상자

l  좋은 프로그래머

-      지루한 일을 하고, 하고, 또 하는 식으로 반복하기 보다는, 적절한 툴의 사용 방법을 배우는 편을 택하려고 합니다.

-      여러 가지 툴체인(Toolchain)의 모델을 알아두고, 각각을 힘들지 않게 사용할수 있습니다.

-      자기의 생활을 더 편하게 만들기 위해서 툴을 사용합니다. 하지만 툴의 노예가 되지는 않습니다.

-      자기가 사용하는 모든 것을 툴로 봅니다.

-      생산성이 높습니다. 왜냐하면 툴이 제2의 천성이 되었기 때문입니다.

l  나쁜 프로그래머

-      몇 가지 툴의 사용 방법을 알고 있지만, 모든 문제를 그 툴의 관점에서만 바라보려고 합니다.

-      새로운 툴을 배우기 위해 시간을 보내는 것을 꺼려합니다.

-      어떤 개발 환경을 사용하기 시작하면, 그것을 종교처럼 받들고, 절대 다른 것의 사용을 시도하거나 검토조차 하지 않으려 듭니다.

-      가치 있는 새로운 툴을 마주쳐도 자신의 툴박스에 추가하지 않습니다.

8.    시험 보는 시간

l  좋은 프로그래머

-      자기가 작성한 모든 코드에 대해 테스트 코드를 작성합니다.(일반 코드를 작성하기 전에 작성할 수 도 있습니다.)

-      마이크로 레벨에서 테스트를 하기 때문에 매크로 레벨에서 테스트를 할 때 바보 같은 코딩 실수로 인해 방해 받는 일이 없습니다.

-      전체 테스트에서 자기가 맡은 역할을 하면서, 제품의 품질에 대해 신경을 쓰고, 그에 대한 책임을 집니다.

l  나쁜 프로그래머

-      테스트가 소프트웨어 개발의 중요한 필수 요소라고 생각하지 않습니다.

-      테스트하지 않은 코드를 QA 부서에 제출하고, 테스트가 결함을 드러내면 놀라는 모습을 보입니다.

-      문제를 너무 늦게 발견해서 자기 인생을 복잡하게 만듭니다.

9.    결함 찾기

l  좋은 프로그래머

-      버그르르 배양하지 않습니다. 코드를 조심스럽게 작성해서 애초에 버그를 끌어들이는 일을 방지합니다.

-      자신의 코드가 무엇을 하는지 알고 있고, 쉽게 고장 나지 않도록 보장하기 위해 테스트 코드를 신중하게 작성합니다.

-      전투 계획도 없이 무모하게 돌진해서 버그 사냥을 하기보다는 방법론적이고 신중하게 합니다.

-      자신의 한계에 대해 알고 있고, 앞뒤가 모두 막혔을 때는 다른 사람에게 결함 찾는 일을 도와달라고 요청합니다.

-      코드의 변경을 조심스럽게 합니다.

l  나쁜 프로그래머

-      디버깅을 하지 않습니다. 여기저기 마구 두드리면서 잘못된 코드의 바다 속으로 침몰합니다.

-      대부분의 생활을 디버거 안에서 보내고, 그 안에서 자신의 코드가 무엇을 하고 있는지 풀어내려고 합니다.

-      고장에 직면하면 감추려 듭니다.

-      자신의 코드 품질과 결함을 고치는 능력에 대해 비현실적으로 큰 기대감을 가지고 있습니다.

-      진짜 원인을 찾아내기 위해 뒤로 돌아가서 문제점을 추적하기보다는, 증상을 감추는 것으로 버그를 고칩니다.

10. 코드 빌드

l  좋은 프로그래머

-      자신이 사용하는 빌드 시스템의 작동 방법, 사용 방법, 확장 방법을 알고 있습니다.

-      단순하고 한 단위로 빌드 시스템을 잘 만들어서, 소스 코드와 나란히 관리합니다.

-      될 수 있는 한 많은 빌드 작업을 자동화 합니다.

-      오버나이트 빌드를 이용해서 통합의 문제점을 잡아냅니다.

l  나쁜 프로그래머

-      빌드 시스템의 작동 방법을 무시하다가 바보 같은 빌드 문제에 발목이 잡힙니다.

-      자신의 빌드 시스템이 얼마나 불안전하고 신뢰할 수 없는 것인지에 대해 걱정을 하지 않습니다.

-      자신의 묘하고 복잡한 빌드 절차를 신참이 거의 적대적인 방법으로 스스로 터득하기를 기대합니다.

-      정의된 릴리즈 절차를 따르지 않고, 한꺼번에 던지는 식으로 릴리즈 빌드를 만듭니다.

11. 속도의 필요성

l  좋은 프로그래머

-      최적화가 절대적으로 필요하다는 사실이 증명되지 않으면 최적화를 하지 않습니다.

-      사려 깊고 신중한 접근 방법으로 체계적인 최적화를 시도합니다.

-      코드 수준의 최적화에 호소하기 전에, 일찍 대안을 찾고 설계 개선에 대해 연구합니다.

-      코드의 품질을 파괴하지 않는 최적화를 선호합니다.

l  나쁜 프로그래머

-      코드의 부적절성을 증명하기도 전에 최적화부터 시작합니다.

-      측정이나 조사도 하지 않고 보틀텍이라고 생각하는 코드를 공격합니다.

-      더 큰 그림을 고려하는 일이 절대 없습니다. 자기가 하는 최적화가 다른 코드 영역이나 사용 패턴에 대해 어떤 의미를 갖는지 전체적으로 고려하지 않습니다.

-      코드의 품질보다 속도가 더 중요하다고 생각합니다.

12. 불안전 콤플렉스

l  좋은 프로그래머

-      자기가 일하는 각 프로젝트의 보안 요구사항에 대해 알고 있습니다.

-      본능적으로 일반적인 보안 취약점을 피하면서 코드를 작성합니다.

-      시스템 각각에 대해 보안을 설계합니다. 보안을 마지막에 끼워 넣지 않습니다.

-      보안을 테스트하는 전략을 가지고 있습니다.

l  나쁜 프로그래머

-      보안이 별로 중요하지 않다고 간단하게 결론을 내려버립니다.

-      자기가 보안 전문가라고 생각합니다.

-      취약점이 발견되었을 때, 더 나쁜 경우로는 자기 코드가 손상되었을 때, 자기 프로그램에 있는 보안 결합에 대해서만 생각합니다.

-      코드를 작성할 때만 보안에 초점을 맞추고, 설계나 아키텍처 수준에서는 보안을 무시합니다.

13. 웅대한 설계

l  좋은 프로그래머

-      자기가 건드린 모든 것이 좋은 상태로 남게 되기를 희망합니다.

-      프로그래밍을 창의적인 과정으로 생각하고, 자기가 하는 일에 예술적인 요소를 끼워 넣습니다.

-      코드 작업을 시작하기 전에 코드의 구조에 대해 생각합니다.

-      지저분한 코드를 보면 추가 작업을 하기 전에 깔끔하게 정리하고 리팩토링해야겠다는 생각을 합니다.

-      다른 소프트웨어의 설계에 대해 끊임없이 공부하고 성공과 실패에 대한 지식을 쌓아 올립니다.

l  나쁜 프로그래머

-      뜨개질하듯이 코드를 작성해서 점점 더 큰 딱딱한 공처럼 만듭니다. 자기가 만족할 때까지 그 일을 계속하고, 결과에 대해서 불평을 합니다.

-      나쁜 설계를 알아볼 줄 모르고, 밀집된 코드를 가지고 작업할 때도 아무 협오감도 느끼지 않습니다.

-      즐겁게 해킹하듯 코딩하고 나서 자기가 어질러놓은 것을 다른 사람들이 치우라고 남겨둔 채 도망갑니다.

-      코드의 내부 설계를 음미하거나 존중하지 않습니다.

14. 소프트웨어 아키텍처

l  좋은 프로그래머

-      자기의 소프트웨어 아키텍처에 대해 알고 있고, 그 안에서 새로운 코드를 작성합니다.

-      설계 시나리오 각각에 대해서 적절한 아키텍처를 적용할 수 있습니다.

-      아름답고 세련된 단순한 아키텍처를 만들어냅니다 – 소프트웨어 설계의 아름다움을 올바르게 인식하고 있습니다.

-      시스템 아키텍처를 캡처해서, 계속 업데이트되고 있는 활성화된 문서 안에 기록합니다.

-      시스템 구조에 관한 문제점을 시스템 아키텍트에게 전달해서 설계의 개선에 도움이 되도록 합니다.

l  나쁜 프로그래머

-      아키텍처의 전체 비전에 전혀 신경을 쓰지 않으면서 코드를 작성합니다 – 그 결과 코드는 다른 부분과 조화를 이루지 못하게 되고, 컴포넌트들은 서로 통합 되지 않습니다.

-      코딩을 시작하기 전에 높은 수준의 설계를 수행하지 않습니다. 아키텍처 상에서 선택할 수 있는 대안을 모두 무시합니다.

-      아키텍처 수준의 정보를 머리 속에만 둠으로써 아예 접근할 수 없게 만들거나, 위험할 정도로 업데이트가 되지 않는 규격서 안에 둡니다.

-      부적절한 아키텍처를 꾹 참고 계속 사용합니다. 하부에 깔려 있는 문제점을 고치는 것이 아니라 거기에 잘못 설계된 코드를 추가 합니다 – 일이 커지는 것을 귀찮아 합니다.

15. 소프트웨어의 진화 또는 혁명

l  좋은 프로그래머

-      깨끗한 구조와 논리적인 레이아웃을 갖는 유지보수가 쉬운 소프트웨어를 작성한다.

-      나쁜 코드를 알아차리고, 그런 코드를 다룰 각오가 되어 있다.

-      코드의 변경을 시작하기 전에 코드와 원작성자의 모리 속 모델에 대해서 가능한 한 많은 것을 알려고 합니다.

-      자기가 작업하고 있는 코드의 품질을 돌본다.

l  나쁜 프로그래머

-      유지보수 프로그래머가 필요로 하는 것을 생각하지도 않고 복잡한 코드를 생성한다.

-      예전 코드를 관리하지 않으려 하고, 문제를 고치기보다 무시하는 것을 더 좋아한다.

-      좋은 솔루션을 생각하는 것보다 손쉬운 땜질을 더 좋아한다.

-      재빠르고 지저분한 해킹으로 코드의 주변을 어지럽힌다. 할 수 있는 모든 꼼수를 다 사용한다.

-      엉뚱한 곳에 주의를 집중하고, 실제로 고칠 필요가 없는 부분을 땜질한다.

16. 코드 멍키

l  좋은 프로그래머

-      정치적이고, 대인관계가 좋고, 예술적이고, 기술적으로 뛰어납니다.

-      팀 플레이어이고, 정직/겸손하고, 끊임없이 발전하고, 주의 깊고, 열심히 합니다.

l  나쁜 프로그래머

-      좋은 코드의 작성에 관심이 없습니다.

-      팀에 속해서 일을 잘하지 못합니다.

-      실제의 자신보다 더 능력 있는 사람처럼 보이려고 애를 씁니다.

-      활기가 없습니다. 자신을 발전시키려고 하지 않습니다.

17. 여기 우리 함께 서 있네

l  좋은 프로그래머

-      자기가 작성한 코드에 대해 영역권을 주장하지 않습니다.

-      소프트웨어 시스템을 더 좋게 만들 수 있다면, 어떤 종류의 개발 업무든 수행할 것입니다.

-      팀에 기여하면서 배우고 성장합니다. 팀을 희생시키지 않으면서 성취할 수 있는 개인적인 목표를 세웁니다.

-      의사소통을 잘 할 수 있습니다. 항상 다른 팀원들의 말에 귀를 기울입니다.

-      겸손하고, 팀에 도움이 되고, 다른 팀원들을 존중하고 가치 있게 평가합니다.

l  나쁜 프로그래머

-      자기만의 코드 제국을 건설하고, 자신을 아주 중요한 사람으로 만들려고 노력합니다.

-      자기만의 일을 하고 싶어하고, 가장 매력적인 일을 찾아 다닙니다.

-      팀의 효율성을 희생시켜가면서 가지가 하고 싶은 일을 수행합니다.

-      항상 자기의 개인적인 의견을 주장하고 싶어합니다.

-      팀이 자기에게 봉사하기 위해 존재한다고 생각하고, 자기가 팀의 최고 팀원이라고 생각합니다.

18. 안전한 소스 습관

l  좋은 프로그래머

-      자기가 한 일에 대해 책임을 지고, 코드 개발을 안전하게 보호하는 방법을 알고 있습니다.

-      소스 컨트롤을 신중하게 사용하고, 항상 레포지터리를 일관성 있고 사용 가능한 상태로 만들어 둡니다.

-      망가진 코드를 절대 소스 컨트롤에 체크인하지 않습니다.

-      유지보수하기 쉽고 사용하기 쉬운 코드를 만들겠다는 의도를 가지고 모든 툴을 신중하게 사용합니다.

l  나쁜 프로그래머

-      재앙이 일어나기 전까지는 코드의 안전성과 접근 가능성에 대해 신경을 쓰지 않습니다.

-      코드의 백업과 안전에 대해서 다른 사람이 생각할 것이라고 추측합니다.

-      문서의 업데이트에 신경을 쓰지 않습니다.

-      레포지터리에 있는 자기 코드의 상태에 대해 신경을 쓰지 않습니다 – 망가진 코드를 체크인하고, 자기가 어질러놓은 난장판을 다른 사람이 치우라고 그대로 둡니다.

19. 규격화 하기

l  좋은 프로그래머

-      규격서의 중요성을 알고 있고, 규격서를 이용해서 자기의 개발 생활을 편하게 만듭니다.

-      문서의 적절한 수준을 알고 있습니다.

-      자신의 문서 작성 스킬을 향상시키고 싶어 하고, 리뷰와 연습할 기회를 쫓아다닙니다.

l  나쁜 프로그래머

-      설계, 문서, 리뷰에 대한 생각을 하지 않고 코딩으로 곧장 다이빙합니다.

-      자기가 쓰는 텍스트에 대해서 생각을 하지 않습니다. 구조도 없고, 따라가기도 힘든 규격서를 만들어냅니다.

-      문서 작성을 피하려고 하고, 따분하고 무의미한 일이라고 생각합니다.

20. 사냥감 확인하기

l  좋은 프로그래머

-      코드 리뷰를 받고 싶어 하고, 자기의 코드 품질에 자신이 있습니다.

-      다른 사람의 의견을 받아들이고, 그 의견으로부터 배웁니다.

-      다른 사람의 코드에 대해 상대방 기분을 생각하면서 정확한 의견을 제시할 줄 압니다.

l  나쁜 프로그래머

-      코드 리뷰를 두려워하고, 다른 사람의 의견을 무서워합니다.

-      비평을 나쁘게 받아들입니다. 방어적이고 쉽게 화를 냅니다.

-      리뷰를 통해서 자기보다 못한 코더들보다 자기가 잘났다는 것을 보여주려고 합니다. 심할 정도로 가혹하고 비건설적인 논평을 합니다.

21. 얼마나 걸릴까?

l  좋은 프로그래머

-      개발 프로세스의 모든 부분에 대해 잘 생각하고, 건실한 컴포넌트 분할에 기초해서 훌륭한 소요시간 추정치를 만들어냅니다.

-      예상 소요 시간 안에 완전히 문서화되고 테스트된 코드를 만들어내고, 올바르게 통합시키려고 노력합니다.

-      소요 시간의 문제점을 일찍 부각시켜서 처리될 수 있게 합니다.

l  나쁜 프로그래머

-      오로지 육감과 직관에 기초한 자기가 희망하는 추정치를 만들어냅니다.

-      추정된 소요 시간 안에 약간의 코드를 해킹하듯이 만들어내기는 하지만, 높은 품질의 제품과 버그 없는 코드를 만들어내지는 못합니다.

-      소요 시간의 문제점을 받아들이는 것을 약함의 표시라고 생각하고, 바보 같이 그것을 따라잡으려고 애씁니다.

22. 프로그램의 요리법

if(ptnum > 0)
 {
  cvCalcOpticalFlowPyrLK(prev_gray, gray, prev_pyramid, pyramid,
                 m2DOld, m2DNew, ptnum, cvSize(win_size, win_size),
        3, status, 0,
        cvTermCriteria(CV_TERMCRIT_ITER|CV_TERMCRIT_EPS, 20, 0.03), flags);
   flags |= CV_LKFLOW_PYR_A_READY;

   int k = 0;
   for(int i = 0; i < ptnum; ++i)
   {
    if( !status[i] )
               continue;

    m2DNew[k++] = m2DNew[i];
   }
   ptnum = k;
 }

 if(add_point)
 {
  m2DNew[ptnum].x = (float)pt.x;
  m2DNew[ptnum].y = (float)pt.y;
 
  add_point = false;
  cvFindCornerSubPix( gray, m2DNew, ptnum,
                cvSize(win_size,win_size), cvSize(-1,-1),
                cvTermCriteria(CV_TERMCRIT_ITER|CV_TERMCRIT_EPS,20,0.03));
  ++ptnum;
 }

tracking을 먼저 한 다음에 점을 추가해야

tracking이 제대로 된다

 if(add_point) 를 한 다음에

if(ptnum > 0)

를 실행하면 new2D 에 0.413 등의 소수점으로 바뀌어서

계속 tracking이 되지 않는다

주의하자

생각하건데 OpenCV 모든 함수에서도 그렇겠지만

함수의 인자에서 포인터를 넣으면 안 된다

예를 들어서


class CDataSet
{
protected:
 CvPoint2D32f * m2DNew;
 CvPoint2D32f * m2DOld;

public:
CvPoint2D32f * GetNew() { return m2DNew; }
 CvPoint2D32f * GetOld() { return m2DOld; }
};

이라고 했을 때

cvCalcOpticalFlowPyrLK(prev_gray, gray, prev_pyramid, pyramid,
                     OldPt, NewPt, *n,
         cvSize(win_size, win_size), 3, status, 0,
         cvTermCriteria(CV_TERMCRIT_ITER|CV_TERMCRIT_EPS, 20, 0.03), flags);

이렇게 했을 때

Point Tracking 이 되지 않는다.

이거 때문에 이틀을 날리고 그 다음에

두번째 실수이다 잊어버리지 말자

그래서 같은 클래스에 넣었었던 것으로 기억된다.