Skip to content

3D 포인트 클라우드에 주석을 다는 방법

라이다와 사진측량 데이터에 방향이 있는 3D 직육면체로 라벨을 붙입니다. 형식, 세부 수준, 회전을 왜 쿼터니언으로 저장해야 하는지, 그리고 3D 박스의 일치도를 재는 법.

포인트 클라우드에 주석을 단다는 것은, 성기고 고르지 않게 표본화된 데이터 위에 방향이 있는 3D 박스를 놓는 일입니다. 멀리 있는 객체는 반사점이 수십 개뿐일 수도 있습니다. 어려운 부분은 그리기가 아닙니다. 뷰어를 반응성 있게 유지하는 것, 주석자에게 자기 작업을 확인할 수단을 주는 것, 그리고 왕복을 견디는 회전 표현을 고르는 것입니다.

형식

형식비고
KITTI velodyne .bin원시 float32 x, y, z, intensity. 헤더가 없어 배치를 가정함
PCDascii, binary, binary_compressed(LZF)
PLYascii와 두 가지 바이너리 엔디안
LAS1.0부터 1.4까지
.xyz / .pts한 줄에 x y z [r g b]
LAZ압축된 LAS. 먼저 변환: laszip -i scan.laz -o scan.las

파싱은 브라우저가 아니라 서버에서 하십시오. 형식이 넷이라는 것은 엔디안과 레코드 배치 버그가 네 벌이라는 뜻이며, 게다가 페이지가 로드될 때마다 200만 점짜리 스캔을 다시 파싱하게 됩니다.

반응성을 유지하기

원시 스캔은 단순하게 렌더링하기엔 너무 큽니다. 이를 감당하게 해주는 것이 둘 있습니다.

  • 옥트리 세부 수준. 점은 영역별로, 카메라와의 거리별로 로드됩니다. Potato에서는 기본으로 켜져 있습니다(lod: true).
  • 간축 상한(max_points). 이는 데이터 설정이 아니라 뷰어 설정으로 다루십시오.

이 구분은 한 번 실제로 문제를 일으켰으니 되풀이할 가치가 있습니다. 예전에는 점별 분할 라벨이 간축된 클라우드의 인덱스로 저장되어, max_points를 낮추면 기존 라벨이 조용히 다른 점을 가리키게 되었습니다. 인덱스는 언제나 원본 파일을 가리켜야 합니다.

주석자에게 2D 확인 수단을 준다

40미터 떨어진 자동차는 반사점 수십 개입니다. 박스가 꼭 맞는지, 길이가 맞는지, 회전이 옳은지는 클라우드만으로는 거의 판단할 수 없고, 카메라 이미지에서는 한눈에 보입니다.

그러므로 3D에서 편집하고 2D에서 검증하십시오. 항목마다 캘리브레이션을 제공해 모든 박스를 각 카메라 뷰에 투영하십시오. 그것이 없으면 3D 라벨링에는 피드백 고리가 없습니다. 궤도 카메라에서 맞아 보이는 박스가 시선 방향으로 몇 미터 어긋나 있어도 그것을 알려줄 것이 아무것도 없습니다.

정사영 슬랩 패널이 나머지 절반을 맡습니다. 정밀 조정을 위한 축 정렬 뷰 세 개이며, 전부 키보드로 조작합니다.

회전은 쿼터니언으로 저장한다

대부분의 형식은 요(yaw) 각 하나만 저장합니다. 내부적으로 완전한 쿼터니언을 들고 있는 것은, 왕복에서 무언가를 잃기 전까지는 과잉 설계처럼 보입니다.

이 덕분에 KITTI 가져오기가 무손실이 됩니다. 요만 담는 필드가 아무 말 없이 버리는, 약 0.85도의 카메라-라이다 장착 기울기까지 포함해서입니다. KITTI로 되돌려 내보낼 때는 여전히 피치와 롤을 떨궈야 하지만, 올바른 동작은 박스를 조용히 평평하게 만드는 것이 아니라 얼마나 많은 방향 정보가 버려졌는지 보고하는 것입니다.

이 간극은 저장 계층에서 조용히가 아니라, 형식별 코드에서 드러나게 건너십시오.

좌표계가 일을 그르치는 지점

틀리기 쉽고 알아채기 어려운 세 가지 관례가 있습니다.

  • 기준 좌표계와 카메라 좌표계. 보정된 기준 좌표계가 필요한 자리에 카메라의 변환을 쓰면 모든 박스가 그 카메라의 스테레오 기선만큼 밀립니다. 체계적이고, 몇 센티미터이며, 주석자의 부주의로 오해되기 쉽습니다.
  • KITTI의 location은 아랫면이지 중심이 아닙니다. 중심으로 읽으면 모든 객체가 자기 높이의 절반만큼 땅에 묻힙니다.
  • 치수 순서와 축 배정. 여기서의 90도 회전 오류는 왕복 테스트로 잡히지 않습니다. 역변환이 같은 잘못된 가정을 하기 때문에 둘이 서로 들어맞아 버립니다. 참조 구현 자체의 꼭짓점 계산식과 대조해야만 잡힙니다.

일치도 측정

정확한 회전 3D IoU를 쓰십시오. 축에 정렬된 근사는 수평인 차량 데이터에는 무방하지만, 드론·손에 든 장비·실내 스캔에서는 틀립니다. 그런 데이터에서는 주석자가 아니라 측도 자체에서 비롯된 불일치를 보고하게 됩니다.

2D에서와 마찬가지로 질문을 나누십시오. 주석자들이 같은 대상을 찾았는가, 같은 라벨을 붙였는가, 같은 위치에 놓았는가. 바운딩 박스의 일치도를 측정하는 방법을 보십시오.

설정

yaml
annotation_schemes:
  - annotation_type: spatial_annotation
    name: objects
    description: "Put a 3D box around every vehicle and pedestrian."
    source_field: point_cloud
    calibration_field: calibration
    tools: [cuboid_3d, point_3d]
    labels:
      - {name: car, color: "#FF6B6B", key_value: "1"}
      - {name: pedestrian, color: "#FFD93D", key_value: "2"}
    color_mode: height
    lod: true
    max_points: 400000
    fit_box_height: true

동작하는 예시: KITTI 쇼케이스 설계.

다른 도구가 정답인 경우

Segments.ai, Kognic, Deepen AI, Supervisely, Xtreme1/BasicAI는 전문 도구이며, 실제 자율주행 파이프라인에서는 앞서 있습니다. 트랙 전파를 포함한 시퀀스 작업 흐름, 레이더와 다중 LiDAR, 직육면체 자동 맞춤 모델, Deepen의 경우 타깃 없는 캘리브레이션 제품 전체까지 갖추고 있습니다. Supervisely와 Xtreme1은 자체 호스팅이 가능하고, Supervisely는 훨씬 큰 클라우드를 다룹니다.

Potato는 포인트 클라우드 시퀀스를 다루지 않습니다. 주석은 프레임 단위이며, 스윕 전반에 걸친 트랙 전파는 구현되어 있지 않습니다. 3D에서 Potato를 고르는 경우는 공간 라벨에 대한 신뢰도 통계가 필요할 때, 또는 3D가 다중 모달 연구의 한 부분일 때입니다.

더 읽을거리