이미지 파일 포맷에는 Exif와 ICC Profile을 비롯한 각종 메타 데이터가 포함되어 있다.
이는 여전히 전통의 강호인 JPEG 뿐만 아니라, WebP, HEIF 등등까지 거의 모든 포맷에 해당된다.
심지어 그동안 Exif를 지원하지 않던 PNG도 1.2(2017년 7월)부터 이를 지원하기 시작했다.
나온지 무척 오래 된 규격이라 이 바닥 엔지니어라면 누구나 손쉽고 정확하게 다룰 수 있는 규격...
이기는 개뿔... 실제로 데이터를 만나보면 결코 이게 쉽지가 않다.
WebP 이미지에 포함된 Exif 데이터는 다음과 같은 형식으로 저장되어야 한다.
WebP 파일에서 Exif 데이터는 EXIF 문자열 뒤에 Exif 영역의 길이가 4바이트 Little endian1으로 저장된다.
Exif 데이터는 II 또는 MM으로 시작되므로 아래 이미지와 같은 모습이 된다.
하지만, WebP 파일들을 뒤져보다 보면 아래와 같이 괴랄한(?) 파일도 눈에 띈다.
뭔가 이상한 10바이트의 데이터가 더 들어있다.
이게 뭔지는 조금만 쳐다보면 쉽게 알 수 있다.
JPEG에 저장된 Exif 영역 데이터를 APP1 Marker(0xffe1)까지 다 업어온 것이다.
마냥 웃을 수만은 없는 것이 위의 파일은 무려 메타 데이터를 꽤 잘 다루는 Exiv2의 예제 파일2이다.
Exif와 마찬가지로, ICC Profile 역시 명확한 표준이 공개되어 있다.
표준에 따르면 맨 앞의 4 바이트는 Profile의 전체 크기다.
그리고, 36-39번째에 acsp라는 고정된 문자열이 저장된다.
그래서 WebP에 ICC Profile이 정상적으로 저장되면 아래와 같은 재미있는 모습이 눈에 띈다.
WebP의 필드 길이 표시부는 필드 길이 자신을 포함하지 않고 Little Endian으로 저장된다.
반면, ICC Profile의 크기 필드는 자신을 포함하여 Big Endian으로 저장된다.
따라서, 아래 화면처럼 좌우 대칭으로 저장되게 된다.
ICC Profile이 JPEG에 저장되면 아래와 같은 모양이 된다.
반드시 들어가야 하는 acsp 문자열을 기준으로 보면 간단하게 따라갈 수 있다.
표시된 0x0230이 ICC Profile의 전체 크기.
더불어, 0x2f32번째에 2바이트로 저장된 0x0240이 JPEG Marker 입장에서의 크기이다3.
하지만 아래와 같은 JPEG 파일도 종종 눈에 띈다.
맨 앞에 적혀있어야 할 ICC Profile의 크기가 없다.
물론, 프로그램이 조금만 똑똑하면 이런 데이터는 손쉽게 처리할 수 있지만, 봐줘야 할 예외가 너무 많다.
PNG는 뒤늦게 Exif를 지원해서 그런지 ICC Profile와 Exif의 저장 방식이 미묘하게 다르다.
ICC Profile은 zlib으로 압축해서 저장하고, Exif는 있는 그대로 저장된다.
저장된 모습 자체는 특이한 게 없어서 화면은 생략.
덧. 현실이 이렇다보니 이미지 프로그램/뷰어들마다도 천차만별이다.
꿀뷰의 경우 대부분의 오류를 다 잡아주지만, WebP에서 0xffe1이 더 들어간 Exif는 읽지 못한다.
또한, PNG에 저장된 Exif는 읽지 못한다.
Paint.NET의 경우 Exif가 포함된 PNG를 다시 저장하면 해당 필드를 날려버린다.
| 이제는 안드로메다로 가버리는 SAMI 자막... (8) | 2022.08.23 |
|---|---|
| 인텔이 공개한 SVT-AV1의 성능 테스트 결과 (1) | 2022.04.27 |
| ffmpeg으로 VirtualDub과 동일한 무압축 RGB 비디오를 만드는 법 (0) | 2021.11.10 |
| MainConcept HEVC 인코더가 2.0으로 업데이트됨 (0) | 2021.10.18 |
| JPEG artifacts 제거 방법들에 대한 간단한 고찰 (0) | 2021.10.16 |
