평판 스캐너는 한 줄짜리 센서를 유리면 위로 천천히 밀어 이미지를 완성한다. 한 블로거는 이 원리를 뒤집었다. 센서를 고정하고 피사체를 움직이는 대신, 센서(카메라)를 통째로 움직이고 세상을 가만히 두는 것이다. 달리는 기차 창밖으로 카메라를 겨눈 채 아주 얇은 수직 라인 하나만을 초고속으로 반복 촬영하고, 그 라인들을 이어 붙이면 폭이 극단적으로 넓은 파노라마 한 장이 만들어진다. 컨테이너 항구 같은 길게 뻗은 풍경을 담아낸 결과물이 바로 이 방식의 산물이다.
발상 자체는 새롭지 않다. 1990년대에는 디지털 센서가 중대형 필름의 해상도를 따라잡지 못해, 한 줄(컬러는 세 줄)의 픽셀을 프레임 위로 이동시키며 고해상도 이미지를 얻는 스캐닝 백이 쓰였다. 지금은 4×5인치 대형 포맷을 덮는 센서까지 나왔지만, 큰 포맷일수록 거대한 센서보다 라인 센서를 움직이는 편이 여전히 저렴하다. 필자는 자신의 대형 카메라에 붙일 스캐닝 백을 오래 구상했지만 마운트 제작이 부담스러워 미루던 차에, 한 중형 스캐닝 카메라 제작 영상을 보다가 "카메라 전체가 움직이면 어떨까"라는 생각에 도달했다.
속도가 모든 것을 결정한다
첫 실험은 소파였다. 사무용 의자에 폰을 올려 천천히 밀며 영상을 찍고, 각 프레임의 가장 왼쪽 열(슬릿)만 뽑아 이어 붙였다. 결과는 소파처럼 보이긴 했지만 심하게 찌그러졌고 벽의 그림은 알아볼 수 없었다. 열을 두 배로 복제해 덜 눌린 것처럼 만들어봤지만, 근본 문제는 밀어내는 속도가 일정하지 않다는 데 있었다. 여기서 핵심 교훈이 드러난다. 이 방식에서 이미지의 가로 축은 곧 시간이자 이동 거리이며, 순간 속도의 작은 변동조차 결과를 왜곡한다. 실무 데이터 파이프라인에서 타이밍 지터가 신호를 망가뜨리는 것과 정확히 같은 문제다.
속도를 측정하려는 시도는 험난했다. MBTA 오렌지 라인에서 낡은 폰을 좌석에 붙여 가속도계로 기록했지만, 데이터가 너무 지저분해 이를 적분해 속도로 바꾸자 마지막엔 기차가 뒤로 가는 것으로 나올 정도였다. 가속도의 노이즈가 적분 과정에서 누적되어 드리프트로 폭발하는 전형적인 관성 항법의 한계다. 필자는 처음엔 속도를 대충 어림잡아도 될 거라 낙관했지만, 결국 속도 보정이 프로젝트 전체에서 가장 성가신 난제였음을 인정한다.
컨베이어벨트용 산업 카메라라는 해법
초당 더 많은 라인을 얻기 위해 필자가 택한 것은 바슬러(Basler)의 ruL2048-19gm이었다. 원래 고속 컨베이어벨트를 겨냥해 설계된 이 카메라는 1×2048 픽셀 센서를 초당 약 1만 9천 회 읽어낸다. 신품은 최저 사양도 700달러 안팎이지만 이베이에서 10분의 1 가격에 구했다. 대신 대가는 빛으로 치른다. 최장 노출이 1/100초에 불과해 많은 광량이 필요하고, 그래서 밝은 낮과 조명이 좋은 역·터널에서만 촬영이 가능하다. 기가비트 이더넷으로 연결되며 APIPA 주소(169.254.0.0/16)만 잡혀 있으면 SDK가 자동으로 카메라를 찾는다. 2013년 제품인데도 최신 SDK가 여전히 지원하고, 구매 증빙 없이 SDK를 내려받을 수 있었다는 점은 벤더 소프트웨어에 시달려본 사람에겐 반가운 대목이다.
하드웨어는 실용 일변도로 꾸려졌다. 친구가 3D 프린팅한 케이스에 열박음 인서트를 넣어 삼각대에 물렸고, 렌즈는 이미 갖고 있던 비비타 28mm f/2.8을 펜탁스 K에서 C 마운트로 변환해 달았다. 높은 피사체를 담기에 화각이 적당했다. 전원은 USB-C 배터리뱅크, 노트북까지는 이더넷과 USB 케이블이 얽힌 케이블 뭉치가 딸려 있다. 가속도계 보정을 적용하면 창밖을 좌우로 흔들며 찍은 이미지가 눈에 띄게 정상적인 비율로 돌아왔고, 오렌지 라인과 롱펠로 다리를 담은 사진에서는 역 표지판 글자까지 또렷이 읽혔다.
미리보기와 데이터 파이프라인의 함정
실전에서 가장 큰 걸림돌은 뜻밖에도 미리보기였다. 벤더 도구 파일런(Pylon)은 화면을 90도 돌려 보여주는 데다 노출을 맞춘 뒤 카메라 점유를 풀고 자체 코드를 다시 띄우는 과정이 번거로웠다. 직접 만든 GUI의 첫 시도인 OpenCV highgui는 프레임마다 1ms 지연을 요구했는데, 라인당 250μs로 촬영하는 상황에서는 화면 한 번 갱신할 때마다 네 줄을 통째로 놓치는 셈이라 부적합했다. 결국 프레임 획득 루프와 잘 맞물리는 Dear ImGui에 GLFW·OpenGL3 백엔드를 붙여 해결했다. 실시간 캡처 루프에 UI를 얹을 때 렌더링 블로킹이 데이터 손실로 직결된다는 것을 보여주는 좋은 사례다.
센서 데이터 전송에서도 실무적 교훈이 쌓였다. SAMD21 마이크로컨트롤러에서 측정값을 문자열로 변환해 시리얼로 보내는 것은 부동소수점 문자열 변환 비용 때문에 지나치게 무거웠고, 변환을 노트북 쪽으로 옮겨야 했다. 가속도계는 원시 부동소수점, GPS는 NMEA 문장으로 흘러 들어와 둘을 고정 바이트 시퀀스(0x11 반복, 0x22 반복)로 구분했지만, 데이터가 우연히 그 시작 시퀀스와 겹칠 가능성은 완전히 배제할 수 없는 취약한 프로토콜이었다. 실제로 시리얼 포트를 제때 플러시하지 않아 하루치 촬영을 통째로 날린 적도 있다. 버퍼가 가득 차 다음 샘플을 하염없이 기다리는 사이 이미지에는 약 0.5초 분량의 '이음매'가 생겼는데, 라인 카메라의 시간 감각에서는 영겁에 가까운 공백이다.
이 프로젝트는 화려한 결과물보다 그 뒤에 쌓인 시행착오가 더 값지다. 관성 센서의 적분 드리프트, 실시간 루프에서의 UI 블로킹, 마이크로컨트롤러의 문자열 변환 비용, 취약한 인밴드 프로토콜 구분자, 버퍼 플러시 타이밍까지, 임베디드와 데이터 처리를 다뤄본 개발자라면 어디선가 마주쳤을 함정들이 한 취미 프로젝트 안에 압축돼 있다. 근본적 한계도 분명하다. 밝은 대낮에만 찍을 수 있고 속도 측정 정확도가 화질의 상한을 정한다. 그럼에도 산업용 라인 스캔 카메라를 저렴하게 구해 창의적으로 전용한 이 실험은, 값비싼 전용 장비 없이도 아이디어와 끈질긴 디버깅만으로 어디까지 갈 수 있는지를 잘 보여준다.