Search
Duplicate
🌏

deer.a7.3_8. title: TPU 를 사용하면서 생기는 TFRecord, Offline augmentation 의 병목 문제

🚀 prev note
♻️ prev note
🚀 next note
♻️ next note
17 more properties
미리 TFRecord 를 잔뜩 만들어서 하드디스크에 캐싱해두는 방법 (참고1) 을 사용하면, 큰 영상으로부터 작은 영상 (참고7:보통 작은 영상을 만들음) 을 미리 만들어두게 된다. 하지만 aihub pedestrian 의 surface masking 데이터셋 1920x1080x3 png 5만장 (참고2,3:데이터셋의개수,해상도) 을 각각 5번씩만 augmentation 하고 640x480x3 크기로 변환해 저장한다고 한다면 (참고4,5:해상도비율과 realsense 해상도) 하더라도 1개의 파일에 총 50000 번의 이미지 읽기, 250000 번의 이미지 쓰기 연산이 이루어져야 한다. 이것은 굉장히 오랜 시간이 걸리는 작업이다. 그래서 리소스의 지속적 사용을 고려했을 때 (참고6:google colab 의 리소스독점제한), 하나의 TFRecord 파일을 생성할 때, 증강시킬 수 있는 영상의 수가 제한될 수 있다. Augmentation 이 복잡하면 복잡해질수록, 하나의 이미지당 다양한 방식으로 augmentation 할수록, 이미지 쓰기 해상도가 커지면 커질수록, 모델은 더욱 정교해지지만 이 과정이 더 오래 걸린다.
참고
1.
2.
6.
7.