BMP 픽셀 행은 아래에서 위로 저장될 수도 있고 위에서 아래로 저장될 수도 있습니다. 헤더 높이의 부호와 실제 디코딩 결과를 확인하고, 단순 회전으로 숨기지 말고 원본부터 방향을 검증하세요.
BMP → PNG
BMP 행 순서가 두 방향일 수 있음을 이해하기
Windows DIB 계열 BMP는 픽셀 행을 항상 위에서 아래로만 저장하지 않습니다. BITMAPINFOHEADER의 높이가 양수인 일반 사례에서는 픽셀 배열이 아래쪽 행부터 시작하는 bottom-up 방식이며, 음수 높이는 위쪽 행부터 시작하는 top-down 방식을 나타낼 수 있습니다. 디코더는 헤더의 부호를 읽어 화면 좌표로 재배치해야 합니다. 바이트 배열을 그대로 위에서부터 그리면 결과가 상하로 뒤집힐 수 있습니다.
먼저 원본 방향이 분명한 파일을 준비하세요. 위쪽에 글자 TOP, 아래쪽에 BOTTOM 또는 비대칭 표식을 둔 표본이 좋습니다. 파일 헤더의 너비와 높이, 비트 깊이, 압축 값을 기록하고 여러 뷰어에서 원본을 엽니다. 한 프로그램만 뒤집어 보인다면 해당 디코더 문제일 수 있고, 모든 프로그램이 같다면 제작 단계에서 이미 픽셀이 뒤집혔을 가능성도 있습니다.
- 높이 값의 부호 확인
- 방향 표식이 있는 표본 사용
- 여러 뷰어에서 원본 비교
BMP 높이의 부호는 단순한 크기가 아니라 행 진행 방향을 나타낼 수 있습니다.
행 순서와 다른 방향 정보를 구분하기
상하 반전은 카메라 회전이나 Exif Orientation 문제와 모습이 다릅니다. BMP는 JPEG처럼 Exif 방향 태그에 의존하는 일반 흐름이 아니므로, 먼저 픽셀 행 순서와 헤더를 확인해야 합니다. 좌우 글자는 정상인데 위아래만 바뀌었다면 행 순서 해석을 의심할 수 있습니다. 90도 회전이나 좌우 반전까지 섞였다면 원본 캡처 또는 별도 변환 단계도 추적하세요.
화면 캡처 API나 오래된 프로그램이 메모리의 DIB 데이터를 BMP로 저장하면서 헤더와 행 배열을 잘못 조합할 수 있습니다. 확장자만 바꾸거나 결과를 수동으로 뒤집으면 원인은 남아 다음 파일에서 반복됩니다. 원본 생성 프로그램, 중간 변환기와 최종 출력 경로를 기록하고 어느 단계에서 방향이 바뀌는지 한 단계씩 비교합니다. 가능하면 같은 픽셀을 정상 파일과 문제 파일로 만들어 헤더 차이를 살펴보세요.
- 상하 반전과 회전 문제 구분
- 생성·중간·최종 단계별 비교
- 정상·문제 파일의 헤더 대조
행 패딩과 픽셀 오프셋도 함께 확인하기
BMP의 각 스캔라인은 정렬을 위해 패딩 바이트를 포함할 수 있습니다. 디코더가 실제 픽셀 너비만 읽고 다음 행 시작 위치를 잘못 계산하면 단순 반전이 아니라 비스듬한 밀림, 색 줄무늬나 잘린 행이 나타납니다. 헤더의 픽셀 데이터 오프셋, 비트 깊이와 행당 바이트 수를 함께 검증하세요. 너비가 특정 배수가 아닌 표본은 패딩 오류를 드러내는 데 도움이 됩니다.
압축된 BMP나 색상표를 사용하는 파일은 추가 조건이 있으므로 무압축 24비트 표본만 통과했다고 모든 BMP가 안전한 것은 아닙니다. 실제 입력에 1·4·8비트 팔레트, 16·32비트 또는 알파 정보가 있다면 각 유형을 별도로 시험합니다. 구조를 직접 고치기보다는 지원되는 디코더로 다시 읽고 표준 출력으로 변환하세요. 손상된 오프셋을 추측해 수정하면 다른 필드를 망가뜨릴 수 있습니다.
- 행 패딩과 오프셋 계산 확인
- 폭이 다양한 표본 시험
- 비트 깊이·팔레트 유형별 검증
행이 밀리거나 색 줄이 생기면 순서뿐 아니라 패딩 계산도 확인해야 합니다.
PNG와 JPG 결과를 목적에 맞게 비교하기
BMP를 PNG로 바꾸면 무손실로 픽셀을 보존하기 쉬워 방향과 색을 점검하는 기준본으로 사용할 수 있습니다. JPG는 투명도를 지원하지 않고 손실 압축이 추가되므로 작은 글자와 경계 비교에는 덜 적합할 수 있습니다. 먼저 PNG 결과에서 위·아래 표식, 픽셀 크기와 색을 확인한 뒤 JPG가 필요한 경우 별도로 품질과 배경 처리를 검증하세요.
원본 BMP, PNG와 JPG를 같은 크기로 놓고 모서리, 첫 행과 마지막 행을 비교합니다. 단순히 화면이 똑바로 보이는지만 보지 말고 한 줄 누락, 패딩으로 생긴 색 변화와 알파 합성도 살펴보세요. 변환기가 자동으로 방향을 교정했다면 결과는 맞아도 원본 문제를 기록해야 합니다. 다른 도구가 같은 원본을 읽을 때 다시 뒤집힐 수 있기 때문입니다.
- PNG를 방향 비교 기준으로 사용
- 첫·마지막 행과 모서리 확인
- 자동 교정 여부 기록
대표 BMP로 전체 경로 승인하기
top-down과 bottom-up 표본, 폭이 다른 이미지, 팔레트 파일과 24·32비트 파일을 준비합니다. 각 파일을 실제 BMP→PNG 또는 BMP→JPG 도구로 변환하고 여러 뷰어와 대상 시스템에서 엽니다. 위아래 방향, 픽셀 크기, 색상, 알파, 첫 행과 마지막 행이 모두 일치하는지 체크하세요. 파일명과 미리보기 캐시 때문에 이전 결과를 보지 않도록 새 이름과 체크섬을 사용합니다.
승인 기록에는 원본 헤더 값, 생성 프로그램, 변환기 버전, 출력 설정과 테스트 환경을 남깁니다. 실패한 결과를 수동으로 뒤집어 덮어쓰지 말고 원본 BMP에서 올바른 디코딩으로 다시 만드세요. 마지막 실무 점검으로 TOP·BOTTOM 표식이 있는 파일과 실제 업무 파일을 각각 최종 서비스에 올려 다운로드본을 비교합니다. 모든 유형이 통과한 뒤에만 폴더 전체를 변환하세요.
- top-down·bottom-up 모두 시험
- 캐시 방지를 위해 새 이름 사용
- 최종 서비스 다운로드본 확인
방향이 명확한 표본과 실제 파일이 모두 통과해야 일괄 변환이 안전합니다.
핵심만 정리했어요
- 일반적인 DIB는 양수 높이일 때 bottom-up, 음수 높이일 때 top-down 행 순서를 나타낼 수 있습니다.
- 행 순서를 무시한 디코더는 이미지를 상하 반전하거나 일부 경로에서만 다르게 표시할 수 있습니다.
- 방향이 분명한 표본과 헤더 값을 함께 확인해 촬영 방향·Exif·행 순서 문제를 구분해야 합니다.
- PNG·JPG 변환 후 픽셀 방향과 크기, 색상, 패딩을 실제 사용 프로그램에서 검증하세요.
자주 묻는 질문
BMP는 왜 아래쪽 행부터 저장될 수 있나요?
전통적인 DIB 구조는 양수 높이에서 bottom-up 배열을 사용할 수 있으며 디코더가 이를 화면 순서로 재구성합니다.
음수 높이는 손상된 값인가요?
항상 그렇지 않습니다. 지원되는 헤더에서 음수 높이는 top-down 행 순서를 나타낼 수 있습니다.
뒤집힌 결과를 편집기에서 다시 뒤집으면 끝인가요?
화면은 맞출 수 있지만 원인과 자동 처리 일관성이 남습니다. 헤더와 디코딩 경로를 확인하는 편이 안전합니다.
이미지가 비스듬히 밀리는 것도 행 순서 문제인가요?
순서보다 행 패딩이나 픽셀 오프셋 계산 오류일 가능성이 있으므로 너비와 행당 바이트를 확인하세요.
최종 변환 검사는 무엇인가요?
방향 표본과 실제 BMP를 변환해 대상 서비스의 다운로드본에서 위아래, 첫·마지막 행, 크기와 색을 비교하세요.