BMP / DIB 파일 분석기

아래에서 위로 저장하는 것이 기본이기 때문입니다. BMP는 biHeight가 음수가 아닌 한 이미지의 마지막 행을 먼저 저장하고, 음수일 때만 행이 위에서 아래로 흐르며 실제 높이는 그 절댓값이 됩니다. 거의 모든 다른 이미지 형식은 위에서 아래로 저장하므로 명세 대신 습관으로 작성한 디코더는 흔한 경우에는 뒤집힌 그림을, 드문 경우에는 올바른 그림을 만들어 냅니다. 이 페이지는 저장된 값과 부호를 따로 보여 주므로 코드를 뒤지기 전에 어떤 파일인지 먼저 알 수 있습니다.

대개는 쓰는 쪽이 남긴 여유 공간일 뿐이며 완전히 합법입니다. 픽셀 배열의 위치는 앞의 크기를 모두 더해서가 아니라 파일 헤더의 bfOffBits로 정해지기 때문입니다. 어떤 프로그램은 픽셀 배열을 디스크 섹터에 맞추고, 어떤 프로그램은 채우지 않을 팔레트 자리를 미리 잡아 두며, 어떤 프로그램은 이전 편집이 비워 둔 공간을 그대로 남깁니다. bfOffBits를 믿지 않고 오프셋을 직접 계산하는 리더는 몇 바이트 이르거나 늦게 읽기 시작해 비스듬히 밀린 이미지를 만드는데, 그것이 전형적인 증상입니다.

명세의 문언대로라면 평범한 BI_RGB 파일에서는 아닙니다. 그 바이트는 쓰이지 않는 패딩으로 문서화되어 있고, BI_BITFIELDS나 BI_ALPHABITFIELDS의 알파 마스크 또는 V4·V5 헤더가 알파를 지정할 때에만 진짜 알파 채널이 생깁니다. 하지만 실제로는 대부분의 프로그램이 거기에 알파를 저장하고 대부분의 리더는 그것을 무시합니다. Pillow만 해도 그런 파일을 그냥 RGB로 읽어 들입니다. 그래서 어떤 프로그램에서는 멀쩡하고 다른 프로그램에서는 검거나 보이지 않는 파일이 생기며, 바이트만으로는 판정할 수 없습니다. 이 페이지는 둘 중 어느 쪽인지 추측하지 않고 그대로 알려 줍니다.

채널 마스크로만 알 수 있습니다. 둘 다 픽셀을 2바이트에 담고 둘 다 픽셀당 16비트라고 선언하며 헤더의 다른 어떤 값도 둘을 구분해 주지 않습니다. 빨강·초록·파랑 마스크가 어느 비트가 어느 채널인지 말해 주고, 초록 마스크가 한쪽에서는 5비트, 다른 쪽에서는 6비트입니다. 마스크 블록이 아예 없는 16비트 BI_RGB 파일은 기본값인 5-5-5입니다. 이 페이지는 각 마스크를 최하위 설정 비트의 위치와 연속된 비트 수로 풀어 주는데, 디코더에서 시프트와 스케일을 쓸 때 실제로 필요한 형태가 바로 그것입니다.

8비트와 4비트 팔레트 이미지를 위한 단순한 런 렝스 인코딩입니다. 바이트 쌍이 한 색의 연속이거나 이스케이프이며, 이스케이프는 줄 끝, 비트맵 끝, 그리고 커서를 x와 y만큼 건너뛰게 하고 지나친 자리를 정의되지 않은 채로 남기는 델타를 다룹니다. 플로피에 든 비트맵을 압축할 가치가 있던 시절을 위한 것이지만, 오래된 Windows 리소스나 구형 도구가 만든 파일에서 여전히 나타납니다. 여기서는 둘 다 디코딩하며 델타 이스케이프의 횟수와 그로 인해 기록되지 않은 픽셀 수를 함께 보고합니다. 리더마다 눈에 띄게 달라지는 부분이 바로 그 픽셀들이기 때문입니다.

아니요. 파일은 브라우저의 File API로 읽고 이 페이지의 자바스크립트가 해석하며, 미리 보기도 같은 탭의 캔버스에 그립니다. 무언가를 보낼 서버 쪽 구성 요소 자체가 없습니다. 이 종류의 도구에서는 그 점이 특히 중요합니다. 들여다보려는 비트맵은 스크린샷이거나 스캔본이거나 웹 서비스에 넘길 수 없는 자산인 경우가 많기 때문입니다. 페이지가 로드된 뒤 네트워크를 끊어도 모든 기능이 그대로 동작합니다.