검색결과 리스트
분류 전체보기 에 해당되는 글 531건
- 2010.01.06 좋은 프로그래머와 나쁜 프로그래머
- 2009.03.06 LK Tracking 다시
- 2009.03.06 Reconstruction
- 2008.09.04 Lucas Kanade Tracking 에 관하여
- 2008.09.01 glClear( ) 와 glClearColor( ) 의 차이
- 2008.08.19 Point Tracking 에러
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. 프로그램의 요리법
tracking을 먼저 한 다음에 점을 추가해야
tracking이 제대로 된다
if(add_point) 를 한 다음에
if(ptnum > 0)
를 실행하면 new2D 에 0.413 등의 소수점으로 바뀌어서
계속 tracking이 되지 않는다
주의하자
이유를 알 거 같다...;;;
Old Point 가 있어야 Tracking 이 되기 때문에...
한번 쉬어야 한다....;;;
그걸 몰랐네...;; 그걸 몰랐어...;;
x1 = P1 * X1
x2 = P2 * X2
여기에서 P1 = [R1 | t1]; 이다. R1은 SO(3)에 포함되고 t1은 3D vector 이다.
1. Reconstruction Method
P1(t) = p1 + t * v1;
P2(s) = p2 + s * v2;
다음과 같이 되기 때문에 P1 과 P2 가 같게 되는 t와 s를 각각 구하면 된다.
두 장의 영상에서 임의의 점에 대한 대응점을 x와 x'이라고 하면
다음과 같이 만들 수 있다.
(x와 x'은 영상 좌표의 homogeneous coordinate 이다)
xn = K-1 * x;
xn' = K-1 * x';
p1 = - R1' * t1;
p2 = - R2' * t2;
v1 = R1' * xn;
v2 = R2' * xn';
위의 4개의 vector p1, p2, v1, v2를 이용하여
다음과 같은 식으로 t와 s를 구할 수 있다.
k1 = p2 - p1;
k2 = v1 x v2;
M1 = [k1 v2 k2];
M2 = [k1 v1 k2];
t = det(M1) / (k2' * k2);
s = det(M2) / (k2' * k2);
t와 s를 구하면 P1(t) 와 P2(s) 에 각각 대입하면
같은 3D 좌표가 나오게 되고 이게
실제 3차원 상의 점이 된다.
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이 되지 않는다
주의하자
glClear(GL_COLOR_BUFFER_BIT);
이렇게 하면 바탕 색이 적용된다.
glClear(GL_COLOR_BUFFER_BIT);
glClearColor(0.0f, 0.0f, 1.0f, 1.0f);
이렇게 하면 바탕색이 적용되지 않는다.
생각하건데 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 이 되지 않는다.
이거 때문에 이틀을 날리고 그 다음에
두번째 실수이다 잊어버리지 말자
그래서 같은 클래스에 넣었었던 것으로 기억된다.