BMP PNG 변환

같은 픽셀, 훨씬 작은 용량

BMP는 대개 전혀 압축되지 않습니다. 모든 픽셀이 한 개당 3~4바이트씩 있는 그대로 기록되고, 각 행은 4바이트 경계에 맞춰 채워집니다. 그래서 1920×1080 스크린샷이 약 8 MB, 1,200만 화소 사진이 36 MB 가까이 됩니다. PNG는 똑같은 픽셀을 무손실로 압축해 저장하므로 이미지는 전혀 바뀌지 않고 파일은 보통 5~20배 작아집니다. 평평한 영역이 넓은 스크린샷이나 도표라면 이 범위의 높은 쪽에 해당합니다. 아무것도 잃지 않는 드문 변환입니다.

결과물에서 한 가지 확인할 점이 있습니다. 32비트 BMP의 투명도는 믿을 수 없으며, 여기서 하는 처리 때문이 아닙니다. 초기 Windows 비트맵 헤더에는 알파 채널이라는 개념이 없어서 각 픽셀의 네 번째 바이트는 그냥 쓰이지 않았습니다. 이후의 헤더가 이를 제대로 정의했지만, 여전히 많은 소프트웨어가 옛 형식으로 기록하고 많은 디코더가 새 형식을 무시합니다. 그래서 만든 프로그램에서는 투명해 보이던 BMP가 알파 바이트를 채움 값으로 읽어 불투명하게 디코딩될 수 있습니다. 중요하다면 PNG를 사용하기 전에 확인해 보세요.

또 하나의 특이점은 행의 순서입니다. BMP는 관례적으로 행을 아래에서 위로 저장하는데, 초기 그래픽 하드웨어가 메모리를 다루던 방식에서 물려받은 결정이며, 위에서 아래로 저장한 파일은 높이를 음수로 표시합니다. 디코더가 둘 다 처리하므로 실제로는 보이지 않습니다. 반쯤 기록되거나 잘린 BMP가 잘린 모양이 아니라 뒤집혀 보이는 이유가 이것일 뿐입니다.

일반적인 Windows 변형은 모두 변환됩니다. 4비트·8비트 RLE 압축 비트맵, 90년대 초의 OS/2 헤더, 드문 JPEG 내장 형식 같은 특이한 변형은 디코더에 따라 다르며, 그중 하나가 거부되면 뒤섞인 이미지를 내놓는 대신 그렇다고 알려 줍니다.

다른 작업이 필요할 때

PNG를 더 줄이려면 oxipng -o 4 out.png나 optipng가 픽셀 하나 바꾸지 않고 10~30%를 더 줄여 주는 경우가 많습니다. pngquant는 팔레트로 줄여서 훨씬 더 줄이는데, 이는 손실 압축이지만 스크린샷이나 도표에서는 대개 눈에 띄지 않습니다.

폴더 전체라면 ImageMagick의 magick mogrify -format png *.bmp가 한 줄로 모두 변환하고, 아주 큰 이미지는 libvips가 훨씬 적은 메모리로 같은 일을 합니다. BMP가 그래픽이 아니라 사진이라면 PNG는 애초에 맞지 않는 형식입니다. JPG가 누구도 알아볼 수 없는 화질 차이로 10분의 1 용량이 됩니다.