BMP হলো মাইক্রোসফটের তৈরি উইন্ডোজে অন্তর্নির্মিত বিটম্যাপ ইমেজ ফরম্যাট, এবং এটি সিস্টেমের প্রাথমিক গ্রাফিকাল ভার্সন থেকেই এর অংশ; খুব কাছাকাছি একটি ভ্যারিয়েন্ট এসেছে IBM-এর OS/2 থেকে। এখানে মূল লক্ষ্য ছিল না কোনো স্মার্ট কমপ্রেশন। একটি BMP প্রায় এমনই যেন স্ক্রিনে যে পিক্সেলগুলো দেখানোর কথা, প্রোগ্রাম সেগুলো সরাসরি ডাম্প করেছে, শুধু কীভাবে পড়তে হবে তা বোঝানোর জন্য একটি ছোট হেডার ঘিরে রাখা হয়েছে। আপনি এখনও BMP ফাইল দেখতে পাবেন উইন্ডোজ সফটওয়্যারের ভেতরের আইকন ও রিসোর্স হিসেবে, সাধারণ ক্যাপচার প্রোগ্রামের আউটপুট হিসেবে, এবং যখন একটি প্রোগ্রাম আরেকটি প্রোগ্রামকে কোনো ইমেজ হস্তান্তর করে তখন মধ্যবর্তী ফরম্যাট হিসেবে।
একটি BMP কীভাবে তার ছবি সংরক্ষণ করে
প্রায় সবসময়ই অসংকুচিত (uncompressed)। ফাইলটি শুরু হয় একটি ছোট হেডার দিয়ে, যেখানে থাকে BM এই দুইটি অক্ষর, ফাইলের আকার এবং পিক্সেল কোথা থেকে শুরু হয়েছে তার অবস্থান; তারপর দ্বিতীয় একটি হেডার আসে, যা ইমেজটিকে বর্ণনা করে: প্রস্থ, উচ্চতা, বিট ডেপথ এবং রঙগুলো কীভাবে সাজানো আছে। এরপর ঐচ্ছিক একটি প্যালেট থাকতে পারে, এবং শেষে থাকে পিক্সেল অ্যারে, যেখানে প্রতি পিক্সেলের জন্য একটি করে মান থাকে, কিছুই বাদ না দিয়ে।
দুটি অদ্ভুত আচরণ মানুষকে অবাক করে। সারিগুলো সাধারণত নিচ থেকে উপরে সংরক্ষণ করা হয়, তাই ফাইলের প্রথম পিক্সেলগুলো আসলে ছবির নিচের-বাম কোণা, এবং প্রতিটি সারি চার বাইটের গুণিতকে পূর্ণ করা হয়। বিট ডেপথ ১ বিট (মানে দুইটি রঙ) থেকে শুরু করে ৪- ও ৮-বিট প্যালেট, তারপর ১৬, ২৪ ও ৩২ বিট পূর্ণ রঙ পর্যন্ত চলে। ৪- ও ৮-বিট মোডের জন্য একটি রান-লেংথ কমপ্রেশন আছে, কিন্তু খুব কমই ব্যবহার হয়, এবং ৩২-বিট মোডে একটি আলফা ট্রান্সপারেন্সি চ্যানেল রাখা যায়, যদিও পুরোনো সফটওয়্যার প্রায়ই এটি উপেক্ষা করে।
কিছুই কমপ্রেস না হওয়ায় আকারটি নির্দিষ্ট এবং বড়: ২৪-বিট BMP-তে ছবিতে যা-ই থাকুক না কেন, প্রতি পিক্সেলের জন্য তিন বাইট লাগে, তাই একটি ছবি যা ছোট JPG-তে ফিট হয়ে যায়, তা BMP-তে অনেক মেগাবাইট হয়ে যায়। এর বিনিময়ে ফরম্যাটটি পড়া ও লেখা অত্যন্ত সহজ, এবং এটি লসলেস (lossless): কোনো ডিটেইল কখনও বাদ পড়ে না।
একটি BMP কী মেটাডাটা ধারণ করে
প্রায় কিছুই না, এবং এটাই এই ফরম্যাট সম্পর্কে জানার সবচেয়ে গুরুত্বপূর্ণ বিষয়। মেটাডাটা হলো সেই বর্ণনামূলক তথ্য যা একটি ফাইল নিজেকে নিয়ে ধরে রাখে, আর BMP তৈরি হয়েছিল যখন এই ধারণাটি গুরুত্বপূর্ণ ছিল না। কোনো BMP ফাইলে EXIF নেই, IPTC নেই এবং XMP-ও নেই, তাই সেখানে ক্যামেরা মডেল, ফটোগ্রাফারের নাম, ক্যাপশন বা GPS সমন্বয় রাখার কোনো জায়গা নেই। এতে কোনো লেখক (author) ফিল্ড নেই, কোনো শিরোনাম নেই এবং কোনো ধরনের তারিখ ফিল্ডও নেই: BMP-র একমাত্র তারিখ হলো যেটা ফাইল সিস্টেম রাখে, যা ফাইলের বাইরে থাকে এবং ফাইল কপি করলে বদলে যেতে পারে।
রিপোর্ট যা দেখাতে পারে, তা আসে হেডারগুলো থেকে, এবং সেগুলো ছবিটিকে বর্ণনা করে, এর ইতিহাসকে নয়:
- প্রস্থ, উচ্চতা এবং বিট ডেপথ, এবং সারিগুলো নিচ থেকে উপরে, নাকি উপর থেকে নিচে চলছে তা।
- কমপ্রেশন পদ্ধতি, যা সাধারণত একেবারেই নেই।
- অনুভূমিক এবং উল্লম্ব রেজোলিউশন, যা পরিচিত ডটস পার ইঞ্চির বদলে পিক্সেল পার মিটার হিসেবে সংরক্ষণ করা হয়।
- প্যালেটে কতগুলো রঙ আছে, এবং সেগুলোর মধ্যে কতগুলোকে ইমেজটি গুরুত্বপূর্ণ বলে ধরে।
গোপনীয়তার আসল একটি বিষয় তবে আছে। বর্ধিত হেডারগুলোতে একটি ICC কালার প্রোফাইল যুক্ত করা যায়, এবং সেটি এমবেড না করে লিঙ্কড করে রাখা যায়, অর্থাৎ যেই মেশিনে ইমেজটি সেভ করা হয়েছে সেখানে একটি ফাইল পাথ হিসেবে। এমন কোনো পাথ ব্যবহারকারীর নাম বা কারও ফোল্ডারের গঠন ফাঁস করতে পারে। এটি খুব সাধারণ নয়, কিন্তু কোনো রিপোর্টে যদি লিঙ্কড প্রোফাইল দেখা যায়, তবে নীরব একটি ফাইলের ভেতরে সেটি কোনো ব্যক্তির কম্পিউটার সম্পর্কে বাস্তব একটি তথ্য।
কখন BMP ব্যবহার করবেন
যখন সরলতা আকারের চেয়ে বেশি গুরুত্বপূর্ণ, তখন BMP যৌক্তিক: খুব ছোট ডিকোডারযুক্ত কোনো প্রোগ্রাম বা ডিভাইসকে ইমেজ সরবরাহ করতে, এমন উইন্ডোজ সফটওয়্যারের ভেতরে কাজ করতে যা এটি আশা করে, অথবা কোনো প্রসেসের দুই ধাপের মধ্যে ইমেজ পাঠাতে, যেখানে আবার কমপ্রেস করাটা বাড়তি পরিশ্রম হতো। এটি লসলেস হওয়ায়, বারবার সেভ করলেও ইমেজের গুণমান নষ্ট হয় না।
সংরক্ষণ, পাঠানো বা প্রকাশের জন্য প্রায় সব ক্ষেত্রেই PNG ভালো বিকল্প। এটিও লসলেস, তাই পিক্সেলগুলো অভিন্নভাবে ফিরে আসে, কিন্তু এর ফিল্টারিং এবং কমপ্রেশন সাধারণত ফাইলের আকার অনেক কমিয়ে আনে, এবং এতে শিরোনাম, লেখক ও কালার প্রোফাইল রাখা যায়। ফটোগ্রাফের জন্য JPG বা WebP আরও ছোট হবে। ডিফল্ট হিসেবে নয়, নির্দিষ্ট প্রযুক্তিগত কারণে ভেবেচিন্তে BMP নির্বাচন করুন।