벡터 외적을 이용한 직선의 교점 구하기

수학 이야기 2020. 9. 10. 09:31

2D 평면에서 네 점 p1, p2, p3, p4가 주어졌을 때, 두 직선 p1p2, p3p4의 교점을 벡터의 외적(cross product)를 이용하여 구하는 방법입니다.

 

영상 기하학을 공부하는 사람들이라면 기본적으로 배우는 것으로 압니다만 (스스로는 정리가 안되어서) 이번 기회에 정리해 놓고 참조하려고 합니다.

 

[방법]

먼저, 네 점을 homogeneous 좌표로 변환하고 3D 벡터로 해석

직선1: $p_1 = (x_1, y_1, 1)$, $p_2 = (x_2, y_2, 1)$

직선2: $p_3 = (x_3, y_3, 1)$, $p_4 = (x_4, y_4, 1)$

 

벡터의 외적을 이용하여 $v$를 계산

$v = (p_1 \times p_2) \times (p_3 \times p_4)$

 

계산된 결과가 $v = (x, y, w)$라면 두 직선의 교점의 좌표는 $(x/w, y/w)$로 주어짐

 

[원리]

2D 평면은 3차원 공간에서의 투영면(image plane), 각각의 점(pi)은 3차원 공간의 projection ray가 투영면에 투영된 점으로 생각할 수 있다. 그리고 투영의 기준점(projection reference point)을 3차원 좌표계의 원점(카메라 원점 C)으로 생각할 수 있다.

 

이 때, 두 벡터 $p_1$, $p_2$의 외적 $n_1 = p_1 \times p_2$는 두 벡터에 의해 정의되는 평면에 수직인 벡터이다 (즉, p1, p2, C를 지나는 평면의 normal 벡터). 마찬가지로 $n_2 = p_3 \times p_4$은 평면 p3, p4, C의 수직 벡터이다. 이 때, 두 평면의 교선 벡터는 $v = n_1 \times n_2$로 주어진다 (두 평면의 수직 벡터에 동시에 수직인 벡터). 두 평면은 모두 투영의 원점(C)을 지나며 또한 원래의 두 직선 p1p2, p3p4의 교점을 지난다. 즉, 투영의 원점과 두 직선의 교점을 잊는 ray가 교선 벡터($v$)가 된다. 따라서, 교선 벡터를 확장한 ray가 원래의 투영면(이미지 평면)과 만나는 점이 구하고자 하는 두 직선의 교점이 된다. 그리고 그 값은 $v$를 유클리디언 좌표로 변환하면 얻어진다.

 

☞ 관련 원리는 벡터의 외적 및 homogeneous 좌표에 대한 이해가 필요하며, [영상처리] - [영상 Geometry #2] Homogeneous Coordinates 글 참조하기 바랍니다.

 

by 다크 프로그래머

'수학 이야기' 카테고리의 다른 글

상관계수와 cross correlation  (2) 2021.09.12
벡터 외적을 이용한 직선의 교점 구하기  (0) 2020.09.10
구구단 암산법  (4) 2018.10.08
아이와 수학 공부하기  (5) 2017.11.15

YOLO와 성능지표(mAP, AP50)

기계학습 2020. 9. 7. 12:23

최근에 YOLO 논문들을 보다 보니 저자가 2018년 YOLOv3를 마지막으로 YOLO 연구를 중단한 것을 알게 되었다.

 

☞ 그리고 올해 2020년 2월 자신의 twitter를 통해 컴퓨터비전 연구를 중단한다고 선언한다.

 

YOLOv3 논문에 보면 자신도 Google이나 군에서 fund를 지원받아서 이런 연구를 하고 있는데.. 이게 어디에 쓰일지(프라이버시 정보 수집, 군사목적 등) 뻔하기 때문에 더 이상 그런 곳에 기여할 수는 없다는 게 이유이다.

 

그리고 논문 말미 Rebuttal을 통해 현재 비전계의 mAP 평가방식(MS COCO)에 대해 강도 높은 비판을 하면서 이 연구계를 떠난다.

 

Detector의 성능을 COCO 데이터셋에 대해 평가했을 때,

  • MS COCO mAP 기준으로 YOLOv3는 33.0 ≪ RetinaNet은 40.8
  • Pascal VOC mAP (AP50) 기준으로 YOLOv3는 57.0 ≒ RetinaNet 61.1 (속도는 YOLOv3가 4배 빠름)

 

똑같은 mAP 인데 왜 이렇게 차이가 나는 걸까?

 

 과거 Pascal VOC 기준으로는 YOLO가 단연 최고의 detector인데, 최근 논문들이 사용하는 COCO 챌린지 기준으로는 속도만 빠른 detector로 전락해 버린다.

 

도대체 뭐가 다른지.. 이번 기회에 mAP 계산 방식에 대해 살펴봤는데 이게 여간 복잡하지 않다.

- Evaluation metrics for object detection and segmentation: mAP

 

Pretty soon you will be pulling your hair out and ask yourself what the **** is all this. “I have an algorithm, and I have my dataset. All I want to do is to evaluate it. Why is it so hard?” 라면서 욕을 바가지로 한 사람도 있다. (공감..)

 

Pascal VOC는 IoU(Intersection over Union) > 0.5 인 detection은 true, 그 이하는 false로 평가하는 방식이고 COCO는 IoU>0.5, IoU>0.55, IoU>0.6, …, IoU>0.95 각각을 기준으로 AP를 계산한 후 이들의 평균을 취하는 방식이다.

 

COCO 방식은 기존 Pascal VOC 방식이 정확도가 높은 (ground truth와 일치하는 box를 검출하는) detector들을 구분하지 못하는 단점을 보완하기 위해서 도입한 것이라고 한다. 나름 일리가 있다.

 

그런데, yolo 저자는 이에 대해 다음과 같이 반박한다.

  1. ground truth는 사람이 만든 것으로서 오차가 있을 수 있으며 그러한 오차를 감안하여 Pascal VOC에서는 IoU 0.5라는 기준을 적용하였다. (사실, 무엇이 정답인지에 대한 기준 자체도 모호하다. 예를 들어 팔을 벌리고 있는 사람의 가장 이상적인 bounding box는 어디인가? 저자는 box를 사용하면서 정확도를 평가한다는 것 자체가 멍청한 짓이라고 말한다)
  2. IoU 기준을 높이다 보면 상대적으로 classification 정확도는 무시되게 된다. box의 위치 정확도가 물체의 클래스 인식율보다 중요한 것인가? (예를 들어 IoU>0.7 기준을 사용하면, 그 이하의 검출은 물체를 사람으로 인식했는지 자동차로 인식했는지 여부와 무관하게 모두 false로 간주된다)
  3. 물체 class별로 각각 AP를 계산하는 방식도 문제이다. 사람 class의 경우, 현재의 평가방식은 detector의 출력들 중 사람에 대한 출력값만 가지고 precision, recall을 계산한다. 그래서, detector가 실제 사람을 치타라고 분류하거나 강아지라고 분류하더라도 이것들은 성능 평가에 아무런 영향을 미치지 않는다. 지금처럼 개별 class별로 AP를 계산한 후 평균하는 방식이 아니라 모든 class를 한꺼번에 놓고 평가하는 방식으로 바꿔야 한다. (이건 조금 이해하기 힘들 수 있는데, multi-class classification 문제에서는 class 개수만큼 ouput 노드를 만들고 그중 가장 출력이 큰 값을 해당 객체의 class로 분류한다. 그런데, 해당 classifier로 사람만 평가한다고 하면 사람 노드의 출력값만 이용해서 출력값>threshold인 경우에 대해 precision-recall 그래프를 그리게 되고, 다른 class 노드에서 사람 노드보다 더 높은 출력값이 나오더라도 이 값은 무시되게 된다)

 

개인적으로는 yolo 저자의 주장에 대부분 공감이 간다. IoU>0.5라는 기준이 사실 그렇게 낮은 기준이 아니다. 크기가 동일한 box라 하더라도 ground truth와 66.7% 이상 overlap이 되어야 IoU = 0.5가 나오고 사람의 눈으로 봤을 땐 대부분 잘 찾았네 하고 느껴지는 수준이다.

 

COCO 기준이 IoU>0.5 AP와 IoU>0.75 AP의 평균을 사용한다면 어느정도 수긍할 수 있다. 그런데, IoU>0.95까지 동일한 weight로 평균한 것은 수긍이 어렵다. 

 

기준이 어찌되었든 모든 detector들에게 동일하게 적용되는 것이니 공평한 것 아니냐 할 수도 있다. 하지만, COCO 방식이 찾은 물체의 사람/자동차/물건 구분은 종종 틀리더라도 COCO가 정한 ground truth 박스와 최대한 일치하게 물체의 bounding box를 찾아주는 detector들에게 유리한 방식임은 틀림없다.

 

그런데, Joseph Redmon이 yolo를 중단한 후, 그동안 yolo에 대한 다양한 플랫폼 빌드(github.com/AlexeyAB/darknet)를 제공하던 Alexey Bochkovskiy이 대대적인 optimization을 통해 올해 2020년 4월에 YOLOv4를 release한다. 그리고 YOLOv4는 MS COCO 지표로 mAP 43.5% (Pascal VOC mAP로는 65.7%), 속도 65 fps를 발표한다.

 

by 다크 프로그래머

'기계학습' 카테고리의 다른 글

딥러닝과 Loss 함수의 이해  (0) 2021.09.15
YOLO와 성능지표(mAP, AP50)  (7) 2020.09.07
YOLO 윈도우즈(windows) 버전  (63) 2017.09.01
최적화 기법의 직관적 이해  (107) 2015.06.02
  • Jiseong 2020.09.08 18:40 ADDR 수정/삭제 답글

    실제로 Localization과 Classification 의 두 가지 task를 동시에 수행하는건데 하나의 성능지표로 나타내려다보니 생기는 문제(?)인거 같네요. IoU 기준에 따라 mAP 계산방식이 Localization에 엄격한건지, Classification에 엄격한건지 갈리는게 재밌는 부분인것 같습니다.
    오랜만에 글 올려주셔서 재밌게 읽었습니다 감사합니다!

  • BlogIcon Baek Kyun Shin 2020.09.09 20:50 신고 ADDR 수정/삭제 답글

    오랜만에 새 글이 올라와서 반갑네요 ㅎㅎ 글 잘 읽었습니다 감사합니다~

  • da 2020.09.24 21:39 ADDR 수정/삭제 답글

    안녕하세요. 작성하신 글 잘 보았습니다!!

    제가 classification을 공부하고 있는데 coco mAP를 뽑아야 하는데
    참조할만한 코드가 있을까요?

    • BlogIcon 다크pgmr 2020.09.25 09:53 신고 수정/삭제

      그건 저도 모릅니다. 해본 적이 없네요.. 인터넷 검색을 활용하시기 바랍니다.

  • BlogIcon 로디네로 2021.04.01 14:52 신고 ADDR 수정/삭제 답글

    yolo 저자가 반박한 세개 내용이 되게 와닿네요.. 감사합니다.

  • BlogIcon 성민석 2021.06.09 17:25 신고 ADDR 수정/삭제 답글

    직접 mAP 계산하는거 구현하려니까 왜 욕박은지 이해가 되네요..ㅋㅋ

아래한글(hwp) 멈춤 현상과 파워포인트(ppt)

잡기장 2018. 12. 22. 21:41

아래한글로 작업을 하다가 그림을 복사한 후 무심코 파워포인트를 닫았다.


아차 싶었지만 이미 엎질러진 물이었다..


역시나 아래한글은 이미 먹통이 되었고 마우스, 키보드 등 아무것도 먹히지 않았다.


작업관리자를 띄워서 아래한글 프로그램을 강제로 종료시킨 후, 혹시나 하는 마음을 담아서 작업하던 문서를 조심스럽게 열었지만..


무려 2시간 30분동안 작업했던 문서 내용이 모두 날아갔다..


글을 새로 쓰는 것보다 훨씬 더더욱 어려운 것은 썼던 글을 모두 날려버리고 다시 그 글을 써내려 가는 것이다.


한번 썼던 글을 다시 쓰는 것이니 좀더 쉬울 것 같지만 사실은 전혀 그렇지가 못하다. 키보드를 던져 버리고 싶은 마음을 꾹꾹 달래면서 지금 쓰는 글과 희미한 기억 사이를 비교하는 일은 꽤나 괴롭고 힘든 일이다.


그동안 아래한글로 작업하다가 프로그램이 먹통이 되어서 문서를 날려 먹은 일이 한두 번이 아니다. 그 전에는 원인조차 몰랐지만 최근에야 아래한글로 작업하다가 열려 있던 파워포인트 프로그램을 닫으면 그러한 현상이 발생한다고 어렴풋이 깨닫고 있었다.


망연 자실해 있다가 도대체 왜 그러는지 원인이라도 알아야겠다는 마음에 '아래한글 먹통 파워포인트'라고 인터넷 검색을 해 보니.. 왠걸, 해결책까지 떡 하니 나온다. 그 동안에는 그렇게 검색을 했어도 안나오더니..


그러한 현상은 아래한글과 파워포인트가 동시에 열려 있는 상태에서 그림 복사, 내용 복사 등의 작업을 하다가 파워포인트를 닫으면 파워포인트가 정상 종료되지 않고 메모리에 남아서 문제가 발생한다고 한다.  그리고 해결책은 작업관리자 창에서 아직 종료되지 않은 파워포인트 프로세스를 찾아서 강제로 종료시키면 아래한글이 다시 살아난다는 것이다.


다시.. 살아난다고 한다.... OTL


하지만 내 경우는 이미 죽여버린 아래한글이라 다시 살아나지는 않는다.. 그래도 해결책을 알았으니 그나마 다행이다.


다크 프로그래머


'잡기장' 카테고리의 다른 글

글쓰기에 대해  (2) 2021.02.05
아래한글(hwp) 멈춤 현상과 파워포인트(ppt)  (33) 2018.12.22
기술의 가치  (7) 2018.10.12
논문제목(영어) 대소문자 표기  (4) 2018.04.30
  • 이전 댓글 더보기
  • 감사합니다 2019.11.06 14:49 ADDR 수정/삭제 답글

    드디어 이유를 알았습니다

  • 감사합니다 2019.11.29 04:24 ADDR 수정/삭제 답글

    살았어요. 새벽 4시까지 작업한거 날릴 뻔했어요. 다시 쓰는 거 정말 싫어요.

  • 정말 감사합니다 2019.11.30 18:42 ADDR 수정/삭제 답글

    선생님께서 절 살리셨어요...

  • tblue 2019.12.05 10:15 ADDR 수정/삭제 답글

    감사합니다 선생님~!

  • 구세주 2020.03.21 16:51 ADDR 수정/삭제 답글

    제 40분을 살려 주셔서 감사합니다 그저 갓,,

  • 하루키 2020.04.03 23:59 ADDR 수정/삭제 답글

    예전에 이글보고 해결했는데 멍청하게 또 그래서 또 검색해서 해결했어유 저는 두번 살리셨어유

  • 신이시여 2020.04.06 16:13 ADDR 수정/삭제 답글

    당신은 신입니다... 저에게.... 와...맨날 다 날리다가 드디어 발견했내요!!

    완전 감사합니다!!!!

  • 감사합니다. 2020.04.22 10:53 ADDR 수정/삭제 답글

    감사합니다. 선생님~~ 다 날릴뻔 했는데....

  • 천재폭발 2020.05.27 16:34 ADDR 수정/삭제 답글

    느낌상 COM OLE 예외처리가 안되어서 그런것 같네요.
    아래아 한글.. 애증의 프로그램이네요. 도스시절부터 썻다가 회사들어오면서 다른걸 썻는데.
    좋게 시작해서 흐지부지 되는 프로그램중의 하나가 아닐까 합니다. 중요 개발자가 이탈해서 그렇겠죠. MDIR, V3, 아래아한글 계속 지속된다고 하더라도 변화의 혁신이 없다면 늙어서 꼬장만 부린다는 ♫♪♬ 처럼 되는것 같습니다. 계속 변화를 해야 살아남는 냉정한 현실이네요.

  • 데빌리너스 2020.06.03 17:13 ADDR 수정/삭제 답글

    정말 감사합니다. 다른 자료 찾으러 왔을 때 많이 왔었는데, 여기서도 또 하나의 지식을 얻어 갑니다. 감사합니다~

  • 엉즈 2020.09.03 00:05 ADDR 수정/삭제 답글

    감사합니다ㅠㅠ!! 작업물을 다 날릴뻔 했어요.........ㅠ

  • 제이니 2020.10.14 22:04 ADDR 수정/삭제 답글

    감사합니다~~ 해결했어요~~ 복받으실꺼예요~~

  • 감사합니다 2020.11.04 20:55 ADDR 수정/삭제 답글

    감사합니다ㅠㅠ 그래서 한글이 저렇게 된거였군요.....파워포인트랑 호환이 좀 잘 되면 좋겠는데ㅠㅠ

  • ㅁㄴㅇ 2020.11.18 16:05 ADDR 수정/삭제 답글

    어디 사시나요 그쪽으로 절하겠습니다. 너무 감사합니다..

  • ㄹㄴㄹㄴㅇ 2020.12.07 18:14 ADDR 수정/삭제 답글

    형님 덕분에 살았습니다 감사합니다

  • 1215xia 2021.01.10 18:33 ADDR 수정/삭제 답글

    선생님 감쟈합니다!

  • gdk 2021.01.18 20:22 ADDR 수정/삭제 답글

    정말 감사합니다

  • 몰빵이 2021.06.22 18:38 ADDR 수정/삭제 답글

    와................................... 감사합니다.... 진짜 구세주 십니다.... 다 날릴뻔했습니다...... 정말정말 감사합니다....

  • MK 2021.07.12 16:55 ADDR 수정/삭제 답글

    감사합니다. 덕분에 살렸습니다.

  • 프리지아 2021.08.10 10:30 ADDR 수정/삭제 답글

    와 정말 감사합니다ㅠㅠㅠㅠㅠ 회사 보고서 날려먹을뻔 했네요ㅠㅠㅠㅠ 정말 감사드려요