BMP प्रारूप समझाया: Windows का सबसे सरल इमेज प्रारूप

किसी BMP फ़ाइल को हेक्स एडिटर में खोलने पर पहले चौदह बाइट्स कुछ इस तरह दिखते हैं:

42 4D 46 00 00 00 00 00 00 00 36 00 00 00

यह पूरा BITMAPFILEHEADER है। 42 4D ASCII में "BM" सिग्नेचर है। अगले चार बाइट्स फ़ाइल का साइज़ बताते हैं — 46 00 00 00 little-endian में 70 है। उसके बाद के चार बाइट्स रिज़र्व्ड हैं और हमेशा ज़ीरो। आखिरी चार बाइट्स पिक्सल डेटा का ऑफसेट हैं — 36 00 00 00 का मतलब 54, यानी पिक्सल ऐरे बाइट 54 से शुरू होता है।

कोई कंप्रेशन मार्कर नहीं। कोई कलर प्रोफाइल नहीं। कोई अल्फा चैनल नहीं। सिर्फ़ एक सिग्नेचर, एक साइज़ और एक ऑफसेट। BMP अपने नाम के मुताबिक है: बिट्स का एक सीधा मैप।

BMP है क्या

BMP का मतलब है Bitmap, और औपचारिक तौर पर Device Independent Bitmap (DIB)। Microsoft ने इसे 1990 में Windows 3.0 के साथ पेश किया था ताकि रास्टर इमेजें किसी खास डिस्प्ले डिवाइस से बंधी न रहें। DIB से पहले Windows Device Dependent Bitmaps (DDB) का इस्तेमाल करता था, जिनका पिक्सल फॉर्मैट उस ग्राफ़िक्स कार्ड पर निर्भर करता था जो इंस्टॉल था। एक मशीन पर सेव की गई DDB दूसरी मशीन पर अपठनीत हो सकती थी।

BMP ने इस समस्या का हल यह था कि फ़ाइल में इतना मेटाडेटा स्टोर किया जाए कि कोई भी डिकोडर इमेज को फिर से बना सके: चौड़ाई, ऊँचाई, बिट डेप्थ, कलर पैलेट, कंप्रेशन टाइप और रॉ पिक्सल ऐरे। ऑपरेटिंग सिस्टम हेडर पढ़ता है, एक बफ़र आवंटित करता है और पिक्सल को मेमोरी में कॉपी कर देता है। 24-बिट अनकंप्रेस्ड इमेज के लिए पिक्सल डेटा अक्सर नीचे से ऊपर लिखे गए RGB ट्रिपलेट्स होते हैं, पंक्ति दर पंक्ति, चार-बाइट सीमा तक पैड किए हुए।

इसी सरलता ने BMP को दस साल से ज़्यादा समय तक Windows का डिफ़ॉल्ट इमेज प्रारूप बना दिया। Paintbrush, Windows वॉलपेपर इंजन, शुरुआती स्कैनर और असंख्य आंतरिक टूल सभी मूल रूप से BMP का इस्तेमाल करते थे।

फ़ाइल संरचना

एक BMP फ़ाइल में चार हिस्से क्रम से लगे होते हैं:

BITMAPFILEHEADER   (14 bytes)
BITMAPINFOHEADER   (40 bytes for the classic version)
Color Table        (optional, for indexed color modes)
Pixel Data         (the actual image)

BITMAPFILEHEADER (14 bytes)

Bytes 0-1:   Signature    "BM" (0x42 0x4D)
Bytes 2-5:   FileSize     (uint32, little-endian)
Bytes 6-9:   Reserved     (always 0)
Bytes 10-13: Offset       (uint32, offset to pixel data from file start)

सिग्नेचर हमेशा "BM" नहीं होता। Windows कर्सर और आइकन वेरिएंट के लिए "BA", "CI", "CP", "IC" और "PT" भी सपोर्ट करता है, लेकिन व्यवहार में आप जो भी BMP खोलेंगे वह "BM" से ही शुरू होगा।

BITMAPINFOHEADER (40 bytes, BITMAPINFOHEADER type)

Bytes 0-3:   HeaderSize        (40)
Bytes 4-7:   Width             (int32, pixels)
Bytes 8-11:  Height            (int32, pixels; negative means top-down)
Bytes 12-13: Planes            (1)
Bytes 14-15: BitCount          (1, 4, 8, 16, 24, or 32)
Bytes 16-19: Compression       (0 = none, 1 = RLE8, 2 = RLE4, 3 = bitfields)
Bytes 20-23: ImageSize         (0 if uncompressed)
Bytes 24-27: XpixelsPerMeter   (physical resolution)
Bytes 28-31: YpixelsPerMeter   (physical resolution)
Bytes 32-35: ColorsUsed        (0 means 2^BitCount)
Bytes 36-39: ColorsImportant   (0 means all)

बाद के Windows वर्जनों में बड़े हेडर जोड़े गए — 52, 56, 108 और 124 बाइट्स — ताकि अल्फा मास्क, कलर स्पेस और ICC प्रोफाइल सपोर्ट किए जा सकें। 40-बाइट वर्जन अब भी सबसे आम है।

हाइट फील्ड और स्टोरेज दिशा

अगर हाइट फील्ड पॉज़िटिव है, तो इमेज bottom-up स्टोर होती है। फ़ाइल में पंक्ति 0 इमेज की सबसे नीचे की पंक्ति होती है। अगर हाइट फील्ड नेगेटिव है, तो इमेज top-down स्टोर होती है। यह BMP की एक खास बात है — ज़्यादातर दूसरे प्रारूप डिफ़ॉल्ट रूप से top-down स्टोर करते हैं।

कलर टेबल

1, 4 या 8 बिट डेप्थ के लिए BMP एक इंडेक्स्ड पैलेट का इस्तेमाल करता है। हर पैलेट एंट्री चार बाइट्स की होती है: नीला, हरा, लाल और एक रिज़र्व्ड अल्फा बाइट जिसे लगभग हमेशा नज़रअंदाज़ किया जाता है। 256-रंग वाली BMP में हेडर के तुरंत बाद 1,024 बाइट्स का कलर टेबल होता है। उसके बाद आने वाला पिक्सल डेटा रंग नहीं होता — वह उसी टेबल में इंडेक्स होता है।

पिक्सल डेटा पैडिंग

हर स्कैनलाइन चार बाइट्स के गुणज होनी चाहिए। 5 पिक्सल चौड़ी 24-बिट इमेज के लिए हर पंक्ति में 15 बाइट्स चाहिए, जो 16 तक गोल हो जाते हैं। ये अतिरिक्त पैडिंग बाइट्स बर्बाद स्थान हैं, जो BMP की अकुशलता का एक और छोटा कारण बनते हैं।

2 x 2 24-बिट अनकंप्रेस्ड BMP का पूरा उदाहरण यहाँ है:

Offset 0x00: 42 4D 46 00 00 00 00 00 00 00 36 00 00 00  -- BITMAPFILEHEADER
Offset 0x0E: 28 00 00 00 02 00 00 00 02 00 00 00 01 00 18 00  -- BITMAPINFOHEADER
Offset 0x22: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
Offset 0x32: 00 00 00 00 00 00 00 00
Offset 0x36: FF 00 00 00 FF 00 00 00 FF  -- नीचे की पंक्ति: लाल, हरा, नीला (पैडिंग सहित)
Offset 0x3F: 00 FF FF 00 FF FF 00 00 00  -- ऊपर की पंक्ति: सियान, मैजेंटा, पीला (पैडिंग सहित)

1990 के प्रारूप परिदृश्य

BMP खाली जगह में नहीं आया। 1990 तक कई इमेज प्रारूप पहले से ही मौजूद थे:

GIF पहले से ही वेब का डिफ़ॉल्ट था, लेकिन उसके LZW पेटेंट के कारण व्यावसायिक इस्तेमाल जोखिम भरा था। JPEG फोटोग्राफ्स के लिए डिज़ाइन किया गया था और यह डेटा अपरिवर्तनीय रूप से हटा देता था। TIFF शक्तिशाली था लेकिन ओवरइंजीनियर्ड — एक सार्वभौमिक TIFF रीडर लिखना अपने आप में एक प्रोजेक्ट था। PCX DOS के साथ खत्म हो रहा था।

BMP की असली ताकत सरलता थी। यह दूसरों से छोटा, तेज़ या ज़्यादा सक्षम नहीं था। यह बस वह प्रारूप था जिसे Windows बिना किसी अतिरिक्त लाइब्रेरी के समझता था।

BMP क्यों काम करता था

BMP के अपने संदर्भ में असली फायदे थे:

ज़ीरो डीकोडिंग जटिलता। 24-बिट अनकंप्रेस्ड BMP को फिक्स्ड-साइज़ हेडर पढ़कर और पिक्सल सीधे फ्रेमबफ़र में कॉपी करकर रेंडर किया जा सकता है। न हफ़मैन टेबल, न DEFLATE स्टेट मशीन, न प्रोग्रेसिव पास। यह इसे सीमित CPU वाले एम्बेडेड सिस्टम के लिए आदर्श बनाता था।

कोई पेटेंट बंधन नहीं। GIF के LZW के विपरीत, BMP में कंप्रेशन या तो अनुपस्थित था या RLE था, दोनों ही पेटेंट-मुक्त थे। यह ओपन-सोर्स टूल्स और उन कमर्शियल सॉफ्टवेयर के लिए मायने रखता था जो Unisys के GIF लाइसेंस से बचना चाहते थे।

सीधा Windows एकीकरण। Win32 API में LoadBitmap, BitBlt और StretchBlt DIB सेक्शन के चारों ओर बने थे। एक डेवलपर BMP को मेमोरी में लोड करके कुछ पंक्तियों में C कोड में स्क्रीन पर ब्लिट कर सकता था।

पूर्वानुमानित मेमोरी लेआउट। चूँकि अनकंप्रेस्ड BMP पिक्सल सीधे स्क्रीन मेमोरी से मैप करते हैं, 1990 के दशक में गेम इंजन और ग्राफ़िक्स टूल BMP को टेक्स्चर इंटरचेंज प्रारूप के रूप में इस्तेमाल करते थे। फ़ाइल को मेमोरी-मैप किया जा सकता था और पिक्सल ऑफसेट को एक रॉ बफ़र की तरह इस्तेमाल किया जा सकता था।

BMP की कमज़ोरियाँ

BMP की ताकतें ही उसकी कमज़ोरियाँ बन गईं। प्रारूप उद्योग के बाकी हिस्सों के साथ विकसित नहीं हुआ।

कोई प्रभावी कंप्रेशन नहीं। अनकंप्रेस्ड BMP बहुत बड़ी होती हैं। 1920 x 1080 24-बिट इमेज 5.93 MB की होती है। वही इमेज JPEG quality 90 में लगभग 300–500 KB की होती है। जब इंटरनेट स्पीड और स्टोरेज लागत बंधन बनी, BMP अप्रचलित लगने लगा।

RLE कंप्रेशन कमज़ोर है। BMP RLE8 और RLE4 रन-लेंथ एन्कोडिंग सपोर्ट करता है, लेकिन RLE सिर्फ़ उन इमेज में मदद करता है जिनमें बड़े एकरूप क्षेत्र हों। फोटोग्राफ और ग्रेडिएंट कमज़ोर तरीके से कंप्रेस होते हैं। RLE-एन्कोडेड BMP व्यवहार में दुर्लभ हैं।

कोई असली ट्रांसपेरेंसी नहीं। स्टैंडर्ड BMP में कोई अल्फा चैनल नहीं है। 32-बिट BMP वेरिएंट में एक अल्फा बाइट शामिल है, लेकिन कई टूल इसे नज़रअंदाज़ करते हैं या रिज़र्व्ड मानते हैं। वेब ग्राफ़िक्स और गेम स्प्राइट्स के लिए यह BMP को PNG के मुकाबले बेकार बना देता था।

कोई एनिमेशन, कोई मेटाडेटा, कोई कलर मैनेजमेंट नहीं। BMP पिक्सल और थोड़ा सा ही और कुछ स्टोर करता है। कोई EXIF नहीं, मूल हेडर में कोई ICC प्रोफाइल सपोर्ट नहीं, कोई एनिमेशन फ्रेम नहीं। जैसे-जैसे वर्कफ़्लो जटिल हुए, BMP प्राचीन रह गया।

Bottom-up स्टोरेज। डिफ़ॉल्ट bottom-up पंक्ति क्रम डिकोडर को उलझाता है और रूपांतरण पर अतिरिक्त चक्र बर्बाद करता है। यह एक छोटी सी बात है जो बिना किसी फायदे के रगड़ पैदा करती है।

BMP की जगह लेने वाले प्रारूप

BMP की सीमाओं ने सीधे तौर पर यह तय किया कि आगे क्या आया।

PNG (1996) ने ट्रांसपेरेंसी और कंप्रेशन की समस्या हल की। इसने लॉसलेस कंप्रेशन, 8-बिट अल्फा और TIFF से सरल स्पेसिफिकेशन दी। PNG ने BMP को लगभग हर जगह वेब और क्रॉस-प्लेटफॉर्म एप्लिकेशन में बदल दिया।

JPEG (1992) ने फोटोग्राफ की समस्या हल की। इसकी DCT-आधारित लॉसी कंप्रेशन ने फोटोग्राफ्स को अनकंप्रेस्ड BMP से 10–20 गुना छोटा कर दिया। किसी भी कंटीन्यूअस-टोन इमेज के लिए JPEG डिफ़ॉल्ट बन गया।

WebP (2010) ने एक ही कंटेनर में लॉसी और लॉसलेस मोड, एनिमेशन और अल्फा जोड़े। एक लॉसलेस WebP आम तौर पर PNG से 20–30% छोटा होता है, जो खुद BMP से बहुत आगे है।

HEIC/HEIF (2013) ने स्टिल इमेज के लिए HEVC-आधारित कंप्रेशन लाया। यह JPEG से छोटे फ़ाइल साइज़ में बेहतर क्वालिटी देता है, अल्फा और डेप्थ मैप सपोर्ट करता है और अब Apple डिवाइस पर डिफ़ॉल्ट है। जब iPhone एक फोटो सेव करता है, तो यह आम तौर पर HEIC ही होता है।

इनमें से हर प्रारूप इसलिए मौजूद है क्योंकि BMP किसी खास उपयोग के मामले के लिए पर्याप्त अच्छा रहना बंद कर दिया।

BMP आज भी कहाँ इस्तेमाल होता है

BMP अब उन आला क्षेत्रों में सीमित रह गया है जहाँ उसकी सरलता उसकी अकुशलता से ज़्यादा मूल्यवान है।

Windows आंतरिक भाग। Windows बूट स्क्रीन, लेगेसी डायलॉग और कुछ सिस्टम संसाधन अब भी BMP का इस्तेमाल करते हैं। Win32 GDI API DIB डेटा की उम्मीद करती है, और ये कोड पथ फिर से लिखना Microsoft के लिए समय की बर्बादी है।

एम्बेडेड सिस्टम और माइक्रोकंट्रोलर। Arduino या STM32 पर एक छोटा LCD PNG डीकोड करने के लिए RAM या CPU नहीं रखता। एक 16-बिट अनकंप्रेस्ड BMP को लगभग बिना किसी कोड के सीधे फ्रेमबफ़र में कॉपी किया जा सकता है।

मेडिकल और वैज्ञानिक इमेजिंग। कुछ लेगेसी DICOM व्यूअर और लैब उपकरण BMP एक्सपोर्ट करते हैं क्योंकि हर सिस्टम इसे खोल सकता है। प्रारूप की सरलता इंटरऑपरेबिलिटी जोखिम कम करती है, जो regulated माहौल में मायने रखता है।

रिवर्स इंजीनियरिंग और शिक्षा। BMP अब भी इमेज फ़ाइल संरचना सिखाने के लिए सबसे अच्छे प्रारूपों में से एक है। हेडर छोटे हैं, पिक्सल लेआउट स्पष्ट है और आप एक दोपहर में एक काम करने वाला डिकोडर बना सकते हैं।

गेम डेवलपमेंट लेगेसी। पुराने गेम इंजन और टेक्स्चर टूल BMP को इंटरमीडिएट प्रारूप के रूप में इस्तेमाल करते थे। कुछ modding कम्युनिटीज़ अब भी BMP एसेट्स के साथ काम करती हैं क्योंकि टूल इसके चारों ओर बने थे।

सिग्नेचर पढ़कर BMP की पहचान करना

.bmp एक्सटेंशन पर भरोसा न करें। पहले दो बाइट्स पढ़ें।

TypeScript

async function isBmp(file: File): Promise<boolean> {
  const buffer = await file.slice(0, 2).arrayBuffer()
  const bytes = new Uint8Array(buffer)
  return bytes.length === 2 && bytes[0] === 0x42 && bytes[1] === 0x4d
}

Python

def is_bmp(path: str) -> bool:
    with open(path, "rb") as f:
        return f.read(2) == b"BM"

Go

func isBmp(path string) bool {
	f, err := os.Open(path)
	if err != nil {
		return false
	}
	defer f.Close()

	buf := make([]byte, 2)
	if _, err := f.Read(buf); err != nil {
		return false
	}
	return bytes.Equal(buf, []byte("BM"))
}

PHP

function isBmp(string $path): bool {
    $header = file_get_contents($path, false, null, 0, 2);
    return $header === "BM";
}

ImageMagick CLI

magick identify -verbose image.bmp | grep "Format:"
# Format: BMP (Microsoft Windows bitmap image)

या सीधे तौर पर:

file image.bmp
# image.bmp: PC bitmap, Windows 3.x format, 1920 x 1080 x 24

BMP का भविष्य

BMP एक पूर्ण प्रारूप है। Windows 95 युग के बाद से कोर स्पेसिफिकेशन किसी महत्वपूर्ण तरीके से नहीं बदला है। यह एक सीमा भी है और एक गारंटी भी: 1995 में लिखा गया BMP आज भी सही खुलता है।

प्रारूप में नई सुविधाएँ नहीं आएँगी। इसे बेहतर कंप्रेशन, उचित अल्फा हैंडलिंग या एनिमेशन सपोर्ट नहीं मिलेगा। कोई BMP में निवेश नहीं कर रहा क्योंकि किसी को बेहतर BMP की ज़रूरत नहीं है। PNG, WebP, AVIF और HEIC पहले ही हर उस संदर्भ में जीत चुके हैं जहाँ दक्षता मायने रखती है।

फिर भी BMP उन जगहों पर मौजूद रहेगा जहाँ वह पहले से है: Windows आंतरिक भाग, एम्बेडेड डिस्प्ले, लेगेसी मेडिकल उपकरण और कक्षाएँ। यह कोई आधुनिक प्रारूप नहीं है, लेकिन बहुत सी सिस्टम इसे पढ़ना जानती हैं, इसलिए इसे पूरी तरह हटाना आसान नहीं है।

अगर आपके पास ऐसी लेगेसी BMP फ़ाइलें हैं जिन्हें आधुनिक डिवाइस पर इस्तेमाल करना है, तो सबसे व्यावहारिक कदम रूपांतरण है। फोटोग्राफ्स के लिए JPEG या HEIC में बदलने से जगह बचती है। ट्रांसपेरेंसी वाले ग्राफ़िक्स के लिए PNG या WebP सही लक्ष्य है। और जब Apple इकोसिस्टम के साथ कनेक्टिविटी चाहिए, तो HEIC को किसी सार्वभौमिक रूप से पठनीय प्रारूप में बदलना पहला कदम है।

हमारा HEIC to JPG converter पूरी तरह ब्राउज़र में चलता है — फ़ाइल आपके डिवाइस से कभी बाहर नहीं जाती। लॉसलेस आउटपुट के साथ ट्रांसपेरेंसी चाहिए तो HEIC to PNG इस्तेमाल करें। वेब-ऑप्टिमाइज़्ड साइज़ के लिए HEIC to WebP से छोटी फ़ाइलें और व्यापक ब्राउज़र सपोर्ट मिलता है।

BMP ने उद्योग को एक मूल्यवान सबक सिखाया: किसी प्रारूप को हर जगह होने के लिए सबसे अच्छा होना ज़रूरी नहीं है। उसे बस इतना सरल होना चाहिए कि हर कोई इसे लागू करे, और इतना स्थापित होना चाहिए कि इसे हटाने में कोई जल्दबाज़ी न करे।