Temporal cue
- 시간적 정보를 의미하며, object detection에서는 주로 이전 프레임과 현재 프레임의 이미지나 feature를 비교하여 물체의 움직임이나 속도를 추정
- Temporal cue를 활용하면 단일 프레임 데이터만 사용하는 방법보다 더 많은 정보를 얻을 수 있음
모든 센서 features가 정보 손실 없이 변환되기 쉽고 다양한 타입의 작업에 적용가능한 shared representation을 찾는 것이 중요
Feature map의 channel 수를 라 하였을 때 하나의 카메라의 feature map으로부터 생성된 Camera feature point cloud의 크기는 로 예상됨
Example)
N = 6, (H, W) = (32, 88), and D = (60-1)/0.5=118
6개의 multi-view camera를 사용하며 각각의 256 X 704 이미지는 1/8 downsampling되어 32 X 88 camera feature map으로 추출
Depth는 1 ~ 60m, step size 0.5m 로 이산화
Precomputation
- The first step of BEV pooling : Grid association
camera feature point cloud의 모든 점을 BEV grid에 속하는 하나의 그룹으로 묶는 과정
- LiDAR point cloud와 달리, 카메라의 내부, 외부 파라미터가 변하지 않는다면 Camera feature point cloud의 각 point의 좌표는 변하지 않음
- 이를 바탕으로 Camera feature point cloud의 모든 point의 3D 좌표와 BEV grid indices 미리 계산
- 모든 point들을 grid indices에 따라 정렬하고 각 point의 순위(rank of each point)를 기록하여 저장
위 문장이 잘 이해가 안되는데 내가 생각하기엔 camera feature point cloud의 크기가 이해하기 쉽게 (X, Y, Z, C)라 하였을 때
W->X, D->Y, H->Z
BEV grid indices는 형태를 지니고 rank of each point는 값인듯하다. 위에서 BEV pooling을 point cloud에서 BEV 형태로 변환하기 위해 사용된다 하였으므로 Figure 3.b에서 index는 이고 value는 각 픽셀의 feature과 depth probability를 곱한 값이며, 같은 좌표의 grid에 속하는 point들을 sum pooling 하여 BEV 형태로 flatten하는 과정이라고 볼 수 있을 것 같다. 정확한 것은 추후 코드를 분석하여 확인할 예정이다.
- 추론 시에는 미리 계산된 순위에 따라 모든 feature point를 재정렬하여 사용
Interval Reduction
- The next step of BEV pooling : Feature aggregation
각 BEV grid 내의 feature들을 대칭 함수 (e.g., mean, max, and sum)로 집계(aggreate)
- 기존의 pooling은 Figure 3.b에서 보듯이 모든 point에 대해 prefix sum을 계산한 다음 인덱스가 바뀌는 경계에서 이전 경계의 결과값을 빼는 방식
- prefix sum 연산은 GPU에서 tree reduction을 필요
- 경계에서의 값만 필요로 하는 것에 비해 사용되지 않는 partial sum을 많이 생성하여 비효율적
- 본 논문에서는 feature aggregation을 가속하기 위해, BEV grid에 직접 병렬화하는 특수한 GPU kernel을 제안
- 각 그리드에 GPU thread를 할당하여 그리드내의 구간 합을 계산
- 제안된 커널은 그리드의 출력들 사이의 의존성을 제거하기 대문에 multi-level tree reduction이 필요하지 않음
- Feature aggregation의 지연 시간을 500ms에서 2ms로 단축 가능 (Figure 3.c)
We apply FPN [28] to fuse multi-scale camera features to produce a feature map of 1/8 input size. We downsample camera images to 256×704 and voxelize the LiDAR point cloud with 0.075m (for detection) and 0.1m (for segmentation)
MAC (Multiply-ACcumulates)
- 컴퓨터 비전에서 모델의 복잡도와 연산량을 측정하는 지표
- 모델이 수행하는 곱셈과 덧셈의 총 횟수를 나타내며, 일반적으로 1 MAC = 2 FLOPs (Floating Point Operations)
- MACs는 모델의 크기와 입력 이미지의 크기에 따라 달라지며, MACs가 작을수록 모델이 더 효율적이고 빠르다고 할 수 있음
망상
- Figure 5.a와 b에서 크기가 작거나 먼 거리의 객체 검출 성능이 모두 크게 증가하였는데 이는 객체의 LiDAR point cloud는 희박하지만 밀도가 높은 카메라 정보에서 이득을 얻을 수 있기 때문
- Figure 5.b에서는 가까운 거리의 (큰) 객체 검출 정확도가 먼 거리의 (작은) 객체보다 높은 것에 비해, Figure 5.a에서 모든 모델의 작은 사이즈의 객체 검출 정확도가 큰 사이즈의 객체 검출 정확도보다 상대적으로 높음
- 논문에는 나와있지 않으나, 크기가 4m가 넘는 객체의 경우 객체 전체의 정보가 아닌 부분적인 정보만 포함되었기 때문이라고 생각함
- 이유
- MVP 모델은 카메라 이미지에 2D instance segmentation을 수행하고, 각 인스턴스에 속하는 픽셀들에 depth estimation을 하여 virtual point를 생성
이 가상의 점들을 LiDAR point cloud와 결합하여 3D 객체를 검출- 본 논문에서는 MVP 모델의 크기가 큰 객체의 검출 정확도가 LiDAR-only 모델에 비해 크게 향상되지 않은 이유를 이미 LiDAR point cloud의 밀도가 높기 때문에 virtual point를 사용한 증강 방법의 이득이 적기 때문이라고 하였음
- 이는 BEVFusion에도 어느정도 적용가능하기 때문에 MVP 모델의 성능 향상이 미미한 이유에 대한 근거라고 보기 어려울 듯 함
- 따라서 앞서 설명한 것과 같이 4m 보다 큰 객체는 부분적인 데이터만 포함하고 있으며, 2D instance segmentation이 부정확하기 때문에 MVP 모델의 성능 향상이 미미함