अपलोड के बाद फोटो आड़ी क्यों हो जाती है?

आप अपने फोन से किसी प्रोडक्ट की फोटो खींचते हैं, हैंडसेट घुमाते हैं, शटर दबाते हैं। स्क्रीन पर यह सीधी दिखती है। लेकिन मार्केटप्लेस के अपलोड फॉर्म में यह आड़ी होकर पहुंचती है — वही फ़ाइल, बस एक चौथाई मोड़ के साथ।

यह आपके फोन की खराबी नहीं है। हो सकता है कि तस्वीर फ़ाइल के अंदर वाकई आड़ी हो, और फोटो खींचने के समय से ही ऐसी हो। आपका फोन इसे आपको हमेशा सीधा दिखाता है, चाहे कुछ भी हो। अपलोड फॉर्म ने ऐसा नहीं किया।

आपकी फ़ाइल इन दो स्थितियों में से किसी एक में होती है, और दोनों में फ़र्क़ पहचानने के लिए बस एक जांच काफी है।

कैमरा तस्वीर को वैसे ही सेव करता है जैसे सेंसर ने उसे देखा

इमेज सेंसर फोन में कसा हुआ एक स्थिर आयत होता है; जब आप घूमते हैं तो यह नहीं घूमता। पोर्ट्रेट फोटो खींचने पर भी यह लैंडस्केप फ्रेम ही रिकॉर्ड करता है, जिसमें आपका सब्जेक्ट अंदर आड़ा लेटा होता है।

कई कैमरे लाखों पिक्सेल फिर से लिखने से बचते हैं और इसके बजाय मेटाडेटा में एक छोटा नंबर लिख देते हैं, जिसका मतलब होता है, "दिखाने से पहले इसे एक चौथाई मोड़ दें।" कुछ अन्य कैमरे सेव करते समय पिक्सेल को खुद घुमा देते हैं और फ़ाइल को पहले से ही सीधी के रूप में चिह्नित कर देते हैं — यही वजह है कि एक ही शॉट पर दो फोन अलग-अलग व्यवहार करते हैं। JPEG में यह नंबर Exif टैग 274, Orientation, होता है, और यह मोड़ के साथ-साथ मिरर किए गए फ्रेम को भी बता सकता है।

कुछ रीडर फ्लैग का सम्मान करते हैं, कुछ इसे नज़रअंदाज़ करते हैं

आधुनिक ब्राउज़र इसे ज़रूर पढ़ते हैं। CSS की image-orientation प्रॉपर्टी का शुरुआती मान from-image होता है; MDN इसे साफ़ शब्दों में बताता है: "इमेज में मौजूद EXIF जानकारी का इस्तेमाल इमेज को सही तरीके से घुमाने के लिए किया जाता है।" अप्रैल 2020 से यह सभी ब्राउज़रों में काम कर रहा है।

जो चीज़ ब्राउज़र नहीं है, वह अब भी इस टैग को नज़रअंदाज़ कर सकती है। वेब स्टैंडर्ड्स अब इसका सम्मान करने पर सहमत हो चुके हैं, लेकिन कई सर्वर-साइड डिकोडर, थंबनेलर और इमेज लाइब्रेरी इस सहमति से पहले लिखी गई थीं और वे इस टैग को कभी देखती ही नहीं — और उन्हें ऐसा करने के लिए कोई बाध्य भी नहीं करता।

इसलिए सवाल कभी यह नहीं होता कि "क्या मेरी फोटो आड़ी है", बल्कि यह होता है कि "क्या इसे दिखाने वाली चीज़ ने फ्लैग पढ़ा"। आपकी गैलरी पढ़ती है। मार्केटप्लेस का थंबनेल जनरेटर शायद न पढ़े।

गैलरी में घुमाने से शायद सिर्फ़ फ्लैग ही फिर से लिखा जाए

रोटेट बटन दबाने पर नतीजा ऐप पर निर्भर करता है। दो बिल्कुल अलग चीज़ें हो सकती हैं।

• ऐप ओरिएंटेशन वैल्यू बदल देता है और पिक्सेल डेटा को छूता तक नहीं। यह तुरंत होता है, बिना किसी नुकसान के, और फ्लैग को नज़रअंदाज़ करने वाली किसी भी चीज़ के लिए अदृश्य रहता है: आपकी फोटो फ़ाइल में अब भी आड़ी ही है।
• ऐप री-एनकोड करता है: यह पिक्सेल को डिकोड करता है, उन्हें घुमाता है, और फ्लैग को रीसेट करते हुए एक नई फ़ाइल लिखता है। घुमाव अब स्थायी रूप से पिक्सेल में शामिल हो जाता है और हर जगह बना रहता है। PNG या लॉसलेस WebP के लिए इसकी कोई कीमत नहीं चुकानी पड़ती; JPEG के लिए आमतौर पर एक री-एनकोड जनरेशन की कीमत चुकानी पड़ती है, जो एक बार चुकाने लायक है, बार-बार नहीं।

ऐप कौन-सा रास्ता अपनाएगा, यह बटन देखकर पता नहीं चलता, और यह एक ही ऐप के अलग-अलग वर्ज़नों के बीच बदल भी चुका है। कुछ भी मान कर मत चलिए; नतीजा जांचिए।

इससे भी बुरी स्थिति तब बनती है जब कोई टूल पिक्सेल तो घुमा देता है, लेकिन पुराना मेटाडेटा जस का तस कॉपी कर देता है: फ्लैग अब भी कहता है "घुमाओ", जबकि पिक्सेल पहले ही घूम चुके होते हैं, और फ्लैग का सम्मान करने वाले रीडर फोटो को दो बार घुमा देते हैं।

यह कैसे पता करें कि आपकी फ़ाइल किस स्थिति में है

इसे सिर्फ़ ध्यान से देखकर तय नहीं किया जा सकता, बल्कि ऐसी किसी चीज़ की जांच करके ही तय किया जा सकता है जो प्रीव्यू न हो।

• आकार की तुलना नंबरों से करें। अगर कोई फोटो देखने में पोर्ट्रेट लगती है, लेकिन फ़ाइल की प्रॉपर्टीज़ में उसकी चौड़ाई ऊंचाई से ज़्यादा बताई जाती है, तो इसका मतलब है कि पिक्सेल लैंडस्केप में हैं और एक फ्लैग यह काम कर रहा है। कुछ व्यूअर इन नंबरों को भी ठीक करके दिखाते हैं, इसलिए मेल न खाना मेल खाने से ज़्यादा साबित करता है।
• फ्लैग को खुद पढ़ें। ब्राउज़र, डेस्कटॉप व्यूअर और फ़ाइल-मैनेजर के थंबनेल अब लगभग सभी इस टैग का सम्मान करते हैं, इसलिए इनके बीच मेल होना कुछ भी साबित नहीं करता। हमेशा एक कॉपी पर काम करें, कभी ओरिजिनल पर नहीं, और Orientation को सीधे पढ़ने के लिए इसे किसी Exif व्यूअर में खोलें। 1 के अलावा कोई भी वैल्यू — 1 को अक्सर "Normal" दिखाया जाता है — इसका मतलब है कि एक फ्लैग काम कर रहा है और पिक्सेल सीधे नहीं हैं।

फ़ाइल को कुछ और छूने से पहले ओरिएंटेशन तय कर लें

remover.bg PNG, JPEG और WebP फ़ाइलें 25 MB तक स्वीकार करता है और बैकग्राउंड हटाकर एक नई फ़ाइल वापस देता है। यह एक बैकग्राउंड रिमूवर है, फोटो एडिटर नहीं: घुमाने का काम आपके फोन के फोटो एडिटर या डिज़ाइन टूल में, अपलोड करने से पहले होना चाहिए।

यह क्रम इसलिए मायने रखता है क्योंकि आप एक नई फ़ाइल बना रहे हैं। PNG और WebP कंटेनर, दोनों में Exif रखने की जगह होती है — Google का WebP स्पेक मेटाडेटा को "'EXIF' या 'XMP ' Chunks" में रखने की अनुमति देता है — लेकिन जिस एडिटर में आपने घुमाया, वह एक्सपोर्ट में मेटाडेटा लिखेगा या नहीं, यह उस एडिटर का फ़ैसला है, आपका नहीं। घुमाव को पिक्सेल में ही स्थायी रूप से शामिल कर दें, तो खोने के लिए कोई फ्लैग बचता ही नहीं। सीधे WebP एक्सपोर्ट करने पर हमारे नोट्स इस फॉर्मेट को कवर करते हैं।

एक कारगर क्रम:

1. गैलरी में रोटेट बटन दबाने के बजाय, किसी एडिटर में घुमाएं और एक कॉपी एक्सपोर्ट करें।
2. उस एक्सपोर्ट की गई कॉपी पर Orientation वैल्यू जांचें।
3. बैकग्राउंड हटाने के लिए उसे अपलोड करें।
4. कटआउट को किसी ठोस रंग या अपनी खुद की फोटो पर रखें, और अगर इसे किसी सतह पर बैठाना हो तो ड्रॉप शैडो भी लगाएं।

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

अपनाने लायक एक आदत

प्रीव्यू पर नहीं, फ़ाइल पर भरोसा करें। एक्सपोर्ट करके घुमाएं और कॉपी पर एक बार Orientation पढ़ लें; फिर वह फोटो ब्राउज़र, थंबनेल जनरेटर और प्रिंटर की कतार — हर जगह सीधी दिखेगी।