JPEG 구조 분석기

사용법

1. JPEG 파일을 상자에 끌어다 놓거나 클릭해서 고르세요. 업로드 없이 페이지 안에서 바이트를 읽습니다.
2. 먼저 개요를 보세요. 크기, 베이스라인/프로그레시브, 크로마 서브샘플링, 추정 품질이 한눈에 들어옵니다.
3. 파일이 예상보다 크다면 애플리케이션 세그먼트 표를 확인하세요. 작은 이미지에서는 ICC 프로파일이나 EXIF 썸네일이 그림보다 클 수도 있습니다.
4. 양자화 표를 펼쳐 실제 행렬과, 그것이 표준 Annex K 표인지 인코더 고유 표인지 확인하세요.
5. 마커 목록에서 이상한 점을 찾아보세요. JFIF 헤더 누락, 낯선 APPn, EOI 뒤에 남은 바이트 같은 것들입니다.

자주 묻는 질문

베이스라인인지 프로그레시브인지 어떻게 판단하나요? 차이가 중요한가요?

바이트 하나로 결정됩니다. 베이스라인은 SOF0, 프로그레시브는 SOF2 프레임 헤더를 가지며 이 도구는 그림을 보고 추측하지 않고 실제 마커를 읽습니다. 차이는 로딩 중 표시 방식입니다. 베이스라인은 한 번의 스캔으로 위에서 아래로 채워지고, 프로그레시브는 여러 스캔이 화면 전체를 점점 선명하게 만들어 몇 킬로바이트만 받아도 흐릿한 전체 이미지가 보입니다. 프로그레시브가 보통 몇 퍼센트 작지만 디코딩에 CPU와 메모리를 더 쓰기 때문에 아주 작은 이미지나 썸네일은 베이스라인으로 두는 경우가 많습니다.

왜 품질이 추정치인가요?

JPEG 파일에는 품질 숫자가 저장되지 않습니다. 저장되는 것은 양자화 표이고, 인코더의 품질 슬라이더는 그 표를 만드는 규칙일 뿐입니다. libjpeg은 표준 Annex K 예시 표에 슬라이더에서 유도한 배율 하나를 곱하므로 그 계산을 되돌릴 수 있고, 표가 배율만 적용된 Annex K 표와 정확히 일치하면 실제로 libjpeg에 전달된 값을 복원해 보여줍니다. 반면 포토샵, MozJPEG, 카메라 펌웨어는 자체 표나 자체 배율을 쓰기 때문에 평균으로 추정할 수밖에 없습니다. 다시 저장하면 연결이 끊어진다는 점도 기억하세요. 품질 90으로 만든 파일을 95로 다시 저장하면 표는 95, 실제 디테일은 90입니다.

품질을 높였는데도 사진이 뿌옇습니다. 어디를 봐야 하나요?

품질과는 별개인 크로마 서브샘플링을 보세요. 4:2:0에서는 두 색차 채널이 가로·세로 절반 해상도로 저장되므로 파란 배경 위의 빨간 선, 색이 들어간 글자, 채도가 높은 로고 가장자리는 색 표본이 4분의 1만 남아 품질 설정과 무관하게 번져 보입니다. 이 도구는 프레임 헤더의 샘플링 계수에서 이를 계산하고 원래 숫자도 함께 보여줍니다. 휘도 2×2에 색차 1×1이면 4:2:0, 휘도 2×1이면 4:2:2, 모두 1×1이면 4:4:4입니다. 대부분의 인코더가 품질 90 부근부터 자동으로 4:4:4로 바꾸기 때문에 95로 내보낸 결과가 양자화 차이만으로 설명되지 않을 만큼 선명해 보이기도 합니다.

그림에 비해 파일이 너무 큽니다. 바이트는 어디에 쓰였나요?

애플리케이션 세그먼트 합계를 보세요. ICC 프로파일이 흔한 원인입니다. v4 프로파일은 수십 킬로바이트에 이르고 JPEG 세그먼트 하나가 65,533바이트까지만 담을 수 있어 여러 APP2 조각으로 나뉘는데, 이 도구가 그 개수를 세어 줍니다. EXIF에는 썸네일이 들어 있는 경우가 많고, 편집 소프트웨어가 남긴 XMP는 수 킬로바이트의 XML이며, 포토샵 APP13에는 웹에서 쓸 일 없는 패스와 슬라이스가 들어 있습니다. 엔트로피 부호화 데이터 비율은 나머지 절반의 이야기입니다. 스캔 데이터가 파일의 40%뿐이라면 아무리 다시 압축해도 소용없고 메타데이터를 지우는 편이 빠릅니다.

리스타트 간격은 무엇이고 왜 필요한가요?

DRI 세그먼트가 리스타트 간격을 정하면 인코더는 MCU N개마다 RST 마커를 쓰고 엔트로피 부호화 상태를 그 지점에서 초기화합니다. 용량이 조금 늘어나는 대신 두 가지를 얻습니다. 바이트가 손상돼도 디코더가 그 지점에서 다시 동기화할 수 있고, 리스타트 사이 구간을 병렬로 디코딩할 수 있습니다. 웹용 JPEG에는 대개 없고 스캐너나 방송 장비, 하드웨어 디코더용 파일에서 볼 수 있습니다. 설정되어 있으면 이 도구가 MCU 단위 간격을 알려주며, RST 마커 자체는 스캔의 일부로 건너뛰고 세그먼트 목록에는 넣지 않습니다.

이미지 뷰어에서는 잘 열리는 파일을 왜 거부하나요?

뷰어는 관대해도 되지만 구조 보고서는 그럴 수 없기 때문입니다. EOI 마커 없이 파일이 끝났다면 압축 데이터 도중에 잘린 것이고, 디코더는 받은 만큼의 줄을 보여 주지만 마커 체인에는 끝이 없습니다. 그 상태에서 합계를 내면 조각의 합계일 뿐입니다. 세그먼트가 파일 끝을 넘는 길이를 선언한 경우도 마찬가지여서, 그 지점 이후는 읽을 수 없고 앞부분만 멀쩡한 척 보고하는 것은 아무 말도 하지 않는 것보다 나쁩니다. 두 경우 모두 이름 붙은 오류로 처리하며, SOI 마커로 시작하지 않는 파일도 마찬가지입니다. 보통은 PNG를 .jpg로 바꿔 놓은 경우입니다.

관련 도구