BMP की पिक्सेल पंक्तियाँ नीचे या ऊपर से शुरू हो सकती हैं। signed height और header देखें, स्पष्ट दिशा वाला नमूना इस्तेमाल करें और डिकोडर की गलती को हाथ से पलटकर छिपाने के बजाय बदले हुए PNG तथा JPG की जाँच करें।
BMP → PNG
BMP की दो पंक्ति दिशाओं को पहचानें
Windows device-independent bitmap का डेटा हमेशा दिखाई देने वाली सबसे ऊपर की पंक्ति से नीचे की ओर संग्रहीत नहीं होता। सामान्य BITMAPINFOHEADER स्थिति में धनात्मक ऊँचाई bottom-up bitmap बताती है, जिसकी pixel array उस scanline से शुरू होती है जो स्क्रीन पर सबसे नीचे दिखेगी। ऋणात्मक ऊँचाई top-down bitmap बता सकती है, जिसकी array ऊपर वाली scanline से शुरू होती है। डिकोडर को चिह्न पढ़कर संग्रहीत पंक्तियों को display coordinates में सही जगह रखना होता है। हर array को top-down मान लेने पर परिणाम लंबवत उलटा हो सकता है।
ऐसा स्रोत तैयार करें जिसकी दिशा को लेकर कोई भ्रम न हो। ऊपरी किनारे पर TOP, निचले किनारे पर BOTTOM लिखें, केवल एक तरफ असममित आकृति रखें और चारों कोनों के रंग अलग करें। Header से width, signed height, bit depth और compression लिख लें, फिर मूल BMP को कई viewers में खोलें। केवल एक प्रोग्राम उलटता है तो उसका डिकोडर संदिग्ध है। सभी समान दिखाते हैं तो बनाने वाले ऐप ने पिक्सेल गलत क्रम में लिखे होंगे या height sign को row array से गलत जोड़ा होगा। फ़ाइल नाम और checksum भी दर्ज करें।
- ऊँचाई का चिह्न देखें
- असममित दिशा नमूना रखें
- कई BMP डिकोडर मिलाएँ
ऊँचाई का चिह्न केवल कुल pixels नहीं, पंक्तियों की दिशा भी बता सकता है।
पंक्ति क्रम को दूसरी दिशा समस्याओं से अलग करें
पंक्ति क्रम से हुआ vertical flip कैमरा rotation या Exif Orientation की समस्या नहीं है। BMP workflow की जाँच JPEG वाली धारणाओं से न करें। यदि अक्षर बाएँ से दाएँ सही पढ़े जा रहे हों लेकिन ऊपर और नीचे बदल गए हों, तो पहले row order देखें। नब्बे अंश का rotation, horizontal mirror या मिला-जुला transform capture software, पहले हुए conversion या display के समय जोड़ी गई किसी प्रक्रिया की ओर अधिक संकेत करता है। यह फर्क सही जगह पर सुधार करने के लिए जरूरी है।
Screen-capture APIs और पुराने ऐप कभी-कभी DIB memory को BMP में लिखते समय row array के साथ गलत height sign जोड़ देते हैं। Extension बदलना या अंतिम चित्र को हाथ से पलटना एक फ़ाइल का लक्षण छिपाता है, उत्पादन प्रक्रिया नहीं सुधारता। Source application, हर intermediate operation और अंतिम converter दर्ज करें, फिर प्रत्येक चरण के बाद चित्र की तुलना करें। उसी target से अच्छा और खराब BMP बन सके तो headers, pixel-data offset और शुरुआती rows साथ रखकर देखें। नए नाम और hashes इस्तेमाल करें ताकि cache में पुरानी preview परिणाम को भ्रमित न करे।
- Flip और rotation अलग करें
- हर चरण का रिकॉर्ड रखें
- सही और खराब headers तुलना करें
पंक्ति padding और pixel offset की जाँच करें
BMP scanlines में alignment पूरा करने के लिए padding bytes हो सकते हैं। यदि डिकोडर पूरी padded row length के बजाय केवल दिखने वाले pixel bytes जितना आगे बढ़े, तो साफ vertical flip के बजाय तिरछा खिसकाव, रंगीन पट्टियाँ या कटी हुई पंक्तियाँ दिख सकती हैं। Pixel data तक offset, bit depth, width और हर scanline के bytes की गणना जाँचें। ऐसी widths पर परीक्षण करें जो storage boundary पर स्वाभाविक रूप से पूरी न बैठें, क्योंकि वे सुविधाजनक dimensions की तुलना में padding की गलती जल्दी दिखाती हैं।
Palette वाले और compressed BMP में अतिरिक्त शर्तें होती हैं। एक uncompressed 24-bit नमूना सफल होना हर BMP variant के समर्थन का प्रमाण नहीं है। यदि वास्तविक inputs में 1, 4 या 8-bit palettes, 16 या 32-bit pixels, alpha जैसे channels या compression आते हैं, तो हर इस्तेमाल होने वाली class अलग जाँचें। Header offset का अनुमान लगाकर bytes सीधे न बदलें। मूल को सुरक्षित रखें, अनुरूप implementation से decode करें और मानक output दोबारा लिखें। केवल एक pixel width बदलने पर लक्षण बदले तो stride और alignment formula को पहले जाँचें।
- Padded stride की गणना करें
- असुविधाजनक widths जाँचें
- वास्तविक depths और palettes शामिल करें
तिरछा खिसकाव या रंगीन rows अक्सर padding या offset की गलती बताते हैं, केवल उलटा क्रम नहीं।
अंतिम उपयोग के अनुसार PNG और JPG तुलना करें
BMP को PNG में बदलने से lossless reference मिलता है, जो orientation, तेज किनारों और सही colors की जाँच के लिए उपयोगी है। JPG lossy compression जोड़ता है और alpha channel नहीं रखता, इसलिए छोटे text या boundary pixels की diagnosis में कम उपयुक्त है। पहले PNG सत्यापित करें। JPG तभी बनाएँ जब destination को उसकी जरूरत हो, और JPEG quality, color subsampling तथा background compositing को row order से अलग निर्णय मानें। इससे compression artifacts को decoding fault समझने की गलती कम होती है।
Source BMP, PNG और JPG को समान displayed dimensions में रखें और चारों corners, top row, bottom row तथा orientation marks तुलना करें। केवल यह न देखें कि चित्र सीधा लग रहा है; missing line, padding से आया color shift या transparency change भी खोजें। Converter किसी असंगत source को अपने आप सुधारता है तो उसे लिखित रूप में दर्ज करें। दूसरा tool उसी source को अलग समझ सकता है, भले पहला output सही लगे। Thumbnail के साथ 100% zoom पर भी देखें, क्योंकि preview एक-pixel defect छिपा सकती है।
- PNG को reference बनाएँ
- पहली और आखिरी row मिलाएँ
- Automatic correction दर्ज करें
प्रतिनिधि BMP को शुरू से अंत तक मंजूर करें
ऐसा test set बनाएँ जिसमें top-down और bottom-up files, कई widths, palette images और production में आने वाले 24 या 32-bit variants शामिल हों। हर फ़ाइल को वास्तविक BMP-to-PNG या BMP-to-JPG tool से बदलें। परिणाम target application और एक स्वतंत्र viewer दोनों में खोलें। Top और bottom, dimensions, colors, alpha behavior तथा edge rows की पूर्णता की पुष्टि करें। नए filenames और checksums रखें ताकि browser cache, sync service या CDN पुराना परिणाम न दिखाए। केवल आसान sample से पूरी pipeline को मंजूरी न दें।
मूल header values, बनाने वाला app, converter version, output settings और test environment दर्ज करें। खराब derivative को पलटकर overwrite न करें; source पर लौटें और सही तरह decode करें। अंतिम practical check के लिए marked target और वास्तविक business image दोनों delivery service पर upload करें, वहाँ से बनी copies download करें और किनारों तक तुलना करें। प्रत्येक आवश्यक BMP class के pass होने और दूसरे viewer में वही परिणाम मिलने के बाद ही batch conversion शुरू करें। इससे एक manual fix को स्थायी समाधान समझने का जोखिम घटता है।
- दोनों row directions जाँचें
- पुरानी cache से बचें
- Downloaded output निरीक्षण करें
पूरे folder को बदलने से पहले direction target और वास्तविक production BMP दोनों सफल होने चाहिए।
मुख्य बातें
- सामान्य DIB संरचनाओं में धनात्मक ऊँचाई bottom-up और ऋणात्मक ऊँचाई top-down पंक्तियों को बता सकती है।
- ऊँचाई के चिह्न को अनदेखा करने वाला डिकोडर चित्र को लंबवत पलट सकता है या अलग ऐप में अलग परिणाम दे सकता है।
- असममित और स्पष्ट रूप से चिह्नित नमूना तथा header मान पंक्ति क्रम की गलती को rotation या capture समस्या से अलग करते हैं।
- रूपांतरण के बाद वास्तविक प्राप्तकर्ता प्रणाली में दिशा, आयाम, रंग, padding और किनारे की पंक्तियाँ जाँचना जरूरी है।
अक्सर पूछे जाने वाले सवाल
BMP सबसे नीचे की पंक्ति पहले क्यों रख सकता है?
पारंपरिक DIB layout धनात्मक height के साथ bottom-up array रख सकता है और decoder दिखाई देने वाला top-to-bottom क्रम फिर बनाता है।
क्या ऋणात्मक BMP height हमेशा corruption है?
नहीं। समर्थित header forms में यह जानबूझकर top-down bitmap दिखा सकती है।
क्या converted image को editor में पलटना पर्याप्त है?
इससे एक फ़ाइल का रूप सुधर सकता है, पर source या decoder की असंगति रहती है और अगली files फिर विफल हो सकती हैं।
क्या diagonal drift भी row-order समस्या है?
यह अधिकतर गलत padded stride या pixel offset का संकेत है, जिसे width और bit depth के साथ जाँचना चाहिए।
अंतिम conversion check क्या है?
Marked target और वास्तविक BMP बदलें, फिर service से downloaded files में orientation, edge rows, dimensions और colors तुलना करें।