CODERNER

이미지 파일을 읽을 때 opencv 혹은 PIL을 쓴다. 두 라이브러리의 기능적 차이는 없다만 경험적으로 보면 읽는 속도와 쓰는 속도가 다름을 알 수 있다. 상황에 따라서 opencv가 효율적일 때도, PIL이 효율적일 때도 있는데 각각 어떤 상황인지 파악해두었다. 왜 차이가 발생하는지 알 수 있는 경우는 이유도 같이 적는다. 이미지 읽기확장자가 PNG일 때 : opencv 써야 빠르다.cv2.imread/imwrite가 훨씬 빠르다. meta 정보를 포함한 DSLR 12MB 이미지의 경우, 10초 가량 차이가 날 때도 있다. 차이가 적을 땐 적지만 클 땐 10배도 난다. 웬만하면 opencv로 png 읽자.확장자가 JPG일 때 : PIL 써야 빠르다.Image.open으로 읽는 것이 약 2배 빠르다. ..

COCO bounding box format은 document를 보면 (x,y,w,h)을 따른다고 적혀있다. 순서대로 사각형의 left top (x, y) 값과 사각형의 (width, height)라는 뜻이다.  그런데 실제로 보면 값이 다음과 같이 0~1 값으로 normalize 되어있는 것을 볼 수 있다.45 0.479492 0.688771 0.955609 0.595545 0.736516 0.247188 0.498875 0.47641750 0.637063 0.732938 0.494125 0.51058345 0.339438 0.418896 0.678875 0.781549 0.646836 0.132552 0.118047 0.096937549 0.773148 0.129802 0.0907344 0.09722..

광각 카메라 모델 중 double sphere 모델을 보면 수식 상 다음과 같이 projection이 실패하는 조건이 있다. 여기서 저 수식 (43)이 의미하는 범위가 대충 지금 광각 카메라가 표현할 수 있는 화각 범위 밖이라는 느낌은 오는데 정확히 어떤 형태인지가 궁금했다. 내가 캘리브레이션했었던 double sphere 모델 주변에 point를 채우고 수식(43) 조건에 필터링되는 point만 남기면 다음 그림과 같다.예상했던 것과 같이 카메라 뒤로 원뿔 형태로 퍼지는 영역이 잡힌다. 광각 이미지가 동심원을 그리듯 표현되어 있고 렌즈도 원이기 때문에 projection-failed 영역은 원뿔 모양이었다. invalid projection 을 그냥 무시하고 구현을 해왔었는데 영역을 보니... 무조건 ..

카메라 자세를 초기화할 때 가장 많이 쓰이는 방법이 PnP를 사용하는 것이다. 이미 알고 있는 3D point set과 이미지에서 검출한 2D point set이 있을 경우, 수학적으로 자세를 아주 간단하게 구할 수 있고 심지어 opencv 함수로 구현되어 있기 때문에 단 한 줄이면 카메라 자세 값을 계산할 수 있다. 하지만 카메라가 광각 카메라여서 pinhole model로 표현이 안될 경우에는 이러한 접근이 어렵다. PnP 알고리즘은 3D point와 2D point 간의 관계가 서로 linear projection일 경우를 가정하기 때문이다. 다른 말로 표현하면 빛이 직진해서 바로 이미지로 맺혔을 경우에만 적용이 가능하다. 반면 광각 카메라 (특히 180도가 넘어가는) 의 경우, 2D point와 ..

각종 논문에서 camera pose를 얻는 기본 방법으로 웬만하면 SfM을 사용하는데 그 때마다 SfM == COLMAP으로 생각하는게 당연할 만큼 COLMAP은 자주 접하게 되는 툴이다.  하지만 COLMAP은 기본적으로 c/c++ 기반으로 되어있어서 python 위주로 코딩할 때 사용성이 그렇게 좋은 편은 아니고 독자적인 포맷도 맞춰줘야 하기 때문에 뚝딱 쓰기엔 조금 시간이 걸린다. 더불어 SIFT 이하 feature 만을 사용하는 COLMAP이기 때문에 더 좋은 deep feature가 있어도 이를 COLMAP에 내장시켜 사용하는 것은 더 오래 걸린다. pycolmap이 있어서 python binding된 형태로 사용할 수 있지만, pycolmap 역시 deep feature를 기반으로 동작하도록 ..

RealityCapture 라고 유명한 photogrammetry 툴이 있다. 연구하는 입장에서는 colmap보다 훨씬 좋은 성능과 속도로 SfM을 돌려주는 툴이라고도 볼 수 있는데 graphics쪽 좌표계와 각종 설정이 섞여있어 좌표계가 자주 쓰는 좌표계와 완전히 다르게 되어 있다. 결과적으로 RealityCapture에서 뱉어주는 카메라를 별도의 후처리 없이 그대로 사용하게 되면 카메라가 지멋대로 돌아가있다.  온갖 검색을 해봐도 정확히 이해될 만한 좌표계 설명이 없고, 일반적으로 쓰는 roll, pitch, yaw 가 각각 x축, y축, z축 회전에 대응되는 것이 아니라 또 새로 정의한 순서이기 때문에 변환하는 일이 만만치 않았다. 결국 나도 온갖 자유도의 transformation과 roll, p..

데이터를 다루다 보면 주어진 3D point와 camera pose가 좌표계가 잘 맞춰져 있는지, coordinate origin을 어디인지, 방향은 맞는지 확인하는 것이 생각보다 귀찮고 까다롭다. 수십, 수백개나 되는 xyz 값이나 se3 값을 봐서는 알 방법이 없기 때문에 보통 시각화해서 보는데, colmap 외 사용 가능한 툴들도 제한적이고 매번 포맷을 맞추는 것도 귀찮다. 나 같은 경우, 간단히 open3d를 이용해 시각화하는 식으로 해결해왔는데 매번 반복적으로 코드를 구현하는 것이 귀찮아서 여기에 내가 주로 사용하는 디버깅용 코드를 기록해두려고 한다. Helper function들 def Rt2T(R, t): T = np.eye(4) T[:3, :3] = R T[:3, -1] = t.reshap..

sphere상에서 normal vector를 뽑는 방법이 가장 간단하게는 위, 경도 상에서 uniform sampling해서 환산하는 방법일 것이다. 하지만 이 방법은 생각해보면 Equi-rectangular projection된 이미지 상에서 뽑아내는 것과 같은 효과이기 때문에 3D 공간 측면에서 생각해보면 극점 (north pole, south pole)에서 뽑히는 샘플이 많고 적도(equator)에서 뽑히느 샘플은 적으므로 충분히 고르다고 할 수 없다. 그러면 3D 공간 상에서 고르게 normal vector를 뽑으려면 어떻게 해야하는가? 머리를 굴려보면 대충 계산할 순 있겠다만 간단한 방식이 있다. sphere에서 고르게 normal vector를 뽑아내는 수식은 정의된 바가 있다. patchma..

실제 카메라를 설치할 때 공간적 제약 혹은 화각의 문제로 카메라를 돌려서 설치하는 경우가 있다. 시계 방향으로 90도 혹은 반시계 방향으로 90도가 가장 흔한 경우인데 이 때 이미지는 또 똑바로 보고 싶을 때도 많다. 이미지만 사용할 경우에야 간단히 cv2.rotate를 쓰든 numpy를 쓰든 돌리면 끝이지만 만약 카메라 캘리브레이션 값도 같이 써야할 경우는 귀찮은 일이 많이 생긴다. 90도 돌린 경우에 intrinsic parameter는 focal length, fx, fy를 서로 스위칭해주어야 하고 principal point는 회전 방향에 따라 값을 재계산해주어야 한다. 또한 extrinsinc parameter 역시 yaw rotation을 가해주어야 한다. 계산하는 것이 어렵지는 않다만 귀찮고..

matrix inverse를 하고자 할 때 numpy든 torch든 간단하게 linalg.inv 함수를 사용하면 끝나니 크게 생각해본 적 없겠지만 matrix inverse는 연산량이 굉장히 큰 operation이다. 간단히만 봐도 O(n^3)이므로 matrix 사이즈가 커질수록 폭발적으로 연산량이 증가한다. 대략 2000 x 2000 보다 큰 크기의 matrix를 다루기 시작하면 영겁의 시간이 걸린다. 이 글에서는 matrix inverse 방식 별 소요 시간을 대충 비교해보고, matrix 크기가 클 때 조금이라도 inverse operation에 들어가는 시간을 줄일 수 있는 노하우를 공유한다. (설명 전에 미리 말하면, 모든 matrix가 가능한 것은 아니다.) 1. Gauss-Jordan eli..