TIFF 구조 검사기

파일의 첫 두 바이트이며 그 뒤의 모든 다중 바이트 값의 바이트 순서를 정합니다. II는 리틀 엔디언(인텔), MM은 빅 엔디언(모토로라)입니다. TIFF는 작성자가 둘 중 하나를 고를 수 있는 드문 형식이라 리더가 한쪽을 못 박을 수 없습니다. 문제는 요란하게 실패하지 않는다는 점입니다. 리틀 엔디언으로 쓴 ImageWidth 40을 빅 엔디언으로 읽으면 10240이 나오고, 그럴듯해 보이는 그 수치 때문에 디코더가 40배 넓은 버퍼를 잡았다가 실제 원인과 한참 떨어진 곳에서 무너집니다. 이 도구가 바이트 순서 표시를 맨 먼저, 그리고 지금 기기와 같은지까지 보여 주는 이유입니다.

거의 아닙니다. TIFF는 디렉터리의 연결 리스트이고 디렉터리 하나가 한 페이지입니다. 팩스와 문서 스캐너가 여러 장짜리 작업을 파일 하나에 담는 방식이 바로 이것입니다. 규격 어디에도 리더가 첫 고리 너머까지 따라가야 한다는 요구는 없어서, 대부분의 미리보기·썸네일 생성기와 모든 브라우저가 거기서 멈춥니다. 여기 체인 표에 5페이지라고 나온다면 페이지는 파일 안에 있고 문제는 리더입니다. ImageMagick, libtiff의 tiffsplit, 포토샵, 대부분의 PDF 변환기는 체인을 끝까지 따라갑니다.

스트립은 RowsPerStrip만큼의 온전한 행으로 이미지를 가로 띠로 자릅니다. 타일은 직사각형으로 자르되 오른쪽과 아래 가장자리에서도 항상 같은 크기로 저장되어, 아무도 보여 주지 않는 패딩이 들어갑니다. 스트립은 스캐너나 평범한 인코더가 쓰는 방식이고 파일을 위에서 아래로 흘려 읽게 해 줍니다. 타일은 큰 이미지를 위한 것입니다. 폭 3만 픽셀짜리 스캔에서 한 구역만 필요한 뷰어는 그 구역을 덮는 타일 몇 개만 읽고 나머지는 건드리지 않습니다. 대신 단순한 리더가 타일 파일에서 넘어집니다. StripOffsets만 처리하고 TileOffsets 분기가 아예 없는 코드가 많습니다.

LZW와 PackBits는 둘 다 반복을 부호화하는데, 사진이나 센서 잡음이 섞인 스캔에는 반복이 거의 없기 때문입니다. 특히 PackBits는 최악의 경우 128바이트마다 1바이트를 더 쓰고, LZW는 잡음 구간에 원본보다 많은 비트를 쓰기도 합니다. 오류가 아니라 실제 결과입니다. 여기 비율은 스트립·타일 바이트 수의 합을, 같은 파일에서 읽은 너비·픽셀당 비트·높이로 계산한 무압축 크기와 비교한 값입니다. 사진에서 이 현상이 보인다면 보통 Deflate가 낫고, 연속 계조라면 TIFF 안의 JPEG나 다른 형식이 더 낫습니다.

디렉터리 엔트리는 12바이트입니다. 태그 2바이트, 타입 2바이트, 개수 4바이트, 값 4바이트입니다. 값이 4바이트 이하이면 — LONG 하나, SHORT 둘, 세 글자 ASCII 문자열 — 그 마지막 4바이트에 그대로 들어갑니다. 넘치면 그 4바이트가 오프셋이 되고 값은 파일의 다른 곳에 쓰입니다. 그래서 TIFF의 데이터가 디렉터리와 붙어 있지 않습니다. BigTIFF에서는 이 자리가 8바이트라 차이가 가장 뚜렷하게 드러납니다. 같은 이미지라도 SHORT 3개짜리 BitsPerSample이 고전 TIFF에서는 바깥에, BigTIFF에서는 엔트리 안에 놓입니다.

BigTIFF는 64비트 오프셋을 쓰는 TIFF입니다. 고전 TIFF의 4바이트 오프셋이 파일에 4GB 한계를 두었기 때문에 만들어졌고, 위성 영상·전체 슬라이드 현미경·대형 스캔은 그 한계에 일상적으로 부딪힙니다. 매직이 42 대신 43이고 헤더에 필드가 두 개 더 붙으며 디렉터리 배치도 달라집니다. 엔트리 개수 8바이트, 엔트리 20바이트, 모든 오프셋 8바이트입니다. 이 도구는 그 구조를 식별만 하는 것이 아니라 끝까지 읽어서, 체인·엔트리·스트립·타일을 고전 파일과 똑같이 보여 줍니다. 유일한 제약은 2^53을 넘는 오프셋을 자바스크립트가 정확히 표현하지 못한다는 점인데, 실제 파일은 거기에 근처도 가지 않습니다.

미리보기는 브라우저에게 파일 디코딩을 부탁하는데 크롬·파이어폭스·엣지에는 TIFF 디코더가 아예 없습니다. 역사적 이유로 사파리만 가지고 있습니다. 그래서 여기서 실패하는 것은 파일에 대한 판정이 아니며, 빈 상자를 보여 주는 대신 사실대로 적습니다. 페이지의 나머지 내용은 모두 바이트에서 직접 읽은 것이라 미리보기와 무관합니다. 태그는 의도적으로 컨테이너에서 멈춥니다. Exif나 GPS 하위 디렉터리가 있는지, 어디서 시작하고 엔트리가 몇 개인지, ICC 프로파일이 몇 바이트인지까지는 알려 주지만 그 안의 카메라·렌즈·노출·좌표는 Exif 뷰어의 일입니다.