얼마전 GeoNURIS Desktop을 사용하여 시스템을 구축 중에 있는 사용자로부터 tiff 파일을 읽는데 오류가 발생한다는 내용과 함께 해당 tiff 파일(약 4.68G)을 받았다.
지금까지 tiff 파일을 읽는데 문제가 발생한 적이 없었기에 파일이 온전치(?) 못하거나 사용자 조작 미숙일거라 판단하고, 바로 디버깅에 돌입하였다.
그러나 디버깅을 시작한지 얼마 안되어 곧바로 밀려오는 멘붕.... 이건 뭐지??
소스 없이 JAI (Java Advanced Image) 모듈을 디버깅하는데.. 도통 알 수 없는 코드 블럭을 종횡무진하면서 파일로부터 데이터를 읽어대는데... 30분이 넘도록 그러고 계신다...
예전부터 tiff 포맷이 궁금했으나.. 궂이 내가 그걸 들여다 볼 필요가 있겠냐는 생각으로 손대지 않았지만, 갑자기 승부욕이 불타올라 tiff 규격을 해부하면서 원인 파악에 나섰다.
별의 별 상상력을 다 동원해가며 문제 원인을 예상하고, 그 문제가 맞는지 테스트해 보는 과정을 별다른 진전 없이 반복하기를 사흘째... 초조.. 낙담..
Tiff 헤더에서 읽힌 버전 넘버에 별 신경을 안 쓰다가... 가만히 보니 42 (고정값)가 아니라 43 인거다.
JAI에서 버전 넘버가 이상하다는 것을 알려주기만 했어도 쉽게 갈 수 있었는데.... ㅜㅜ
버전 넘버 43을 구글링하다가 발견한 것이 BigTIFF !
Adobe 사의 Steve Carlsen에 의해 제안된 규격으로 아직 정식 규격으로 채택된거 같진 않아 보인다. BigTIFF 규격은 64bit OS에 의해 지원되는 파일 사이즈가 커짐에 따라, 4G 이상의 tiff 파일을 지원하기 위하여 제안된 규격으로써 JAI에서도 아직 지원하지 않고 있는 규격이다.
tiff 파일의 내부 구조는 굉장히 가변적이고 확장적이며, 이를 위해 tagging된 데이터 블럭들이 서로를 참조하고 있다.
기존의 tiff 규격에서는 데이터블럭의 오프셋을 나타내기 위하여 4byte unsigned int를 사용하는데, 4G 이상의 큰 파일 상에서의 오프셋을 지정하기에는 부족하였다.
BigTIFF에서는 8byte unsigned long 값을 사용하여 오프셋을 표현하도록 되어 있으며, 이 밖에 데이터타입의 추가확장을 포함한 전반적인 규격 변경이 이루어졌다.
결국 BigTIFF를 읽을 수 있도록 JAI 코드를 확장하여, GeoNURIS Desktop에 반영하였더니, 드디어 문제의 tiff 파일이 열렸다. 그 순간 소름이 확 돋았다는 ... ㅋ
심지어 ArcMap이나 QGIS와 비교하여 속도가 더 빠르다는 사실에 뿌듯~~
앞으로 BigTIFF를 읽을 때도 GeoNURIS Desktop에서~~ (^^) v
혹시나 비슷한 문제로 헤딩(?)하시는 분들이 있을까 해서 정보 공유합니다.
BigTIFF 관련 내용은 아래 링크를 참고하세요~
BigTIFF File Format Proposal
댓글 없음:
댓글 쓰기