JPEG फ़ोटो से EXIF डेटा हटाएं
01 ज़्यादातर "EXIF हटाने वाले" टूल JPEG के इर्द-गिर्द ही क्यों बने हैं
JPEG पुराना है (1992 में शुरू हुआ) और आज भी ज़्यादातर पुराने कैमरे और फ़ोन का डिफ़ॉल्ट आउटपुट फ़ॉर्मैट है। इसका मेटाडेटा फ़ाइल के अंदर नंबरदार "APP" मार्कर सेगमेंट में रहता है - APP1 में आमतौर पर EXIF (कैमरा मॉडल, GPS, टाइमस्टैंप) रहता है, कभी-कभी XMP भी; APP2 में आमतौर पर एम्बेडेड ICC कलर प्रोफ़ाइल; और एक सादा COM सेगमेंट किसी भी फ़्री-टेक्स्ट कमेंट को रख सकता है। यह सब असली इमेज डेटा से पहले होता है और सही टूल से आसानी से पढ़ा जा सकता है - इसीलिए JPEG मेटाडेटा हटाना इस पूरे क्षेत्र में सबसे परिपक्व, सबसे ज़्यादा प्रतिस्पर्धी जगह है।
और गहराई से जानें: क्वांटाइज़ेशन टेबल, थंबनेल, और "क्वालिटी" विकल्प असल में क्या बदलते हैं
JPEG का DQT (क्वांटाइज़ेशन टेबल) मार्कर यह तय करता है कि इमेज का हर 8x8 पिक्सेल ब्लॉक कितना कड़ा कम्प्रेस किया जाए - यह टूल असली टेबल वैल्यू सीधे पढ़कर दिखाता है, कुछ फ़ोरेंसिक टूल की तरह "क्वालिटी स्कोर" का अंदाज़ा नहीं लगाता। EXIF में अक्सर एक दूसरी, छोटी एम्बेडेड थंबनेल भी होती है, जो एक बार बनती है और बाद के एडिट में अक्सर अपडेट नहीं होती - अगर वह थंबनेल कुछ ऐसा दिखाती है जो मुख्य इमेज में नहीं है, तो यह एक असली, जांचने लायक सुराग है कि फ़ोटो बाद में एडिट की गई थी, जैसा कि मेटाडेटा पेज पर ज़्यादा बताया गया है।
एक और असली, अलग खतरा जानने लायक है: JPEG का इमेज-एंड मार्कर (0xFFD9) साफ़ तौर पर तय है, लेकिन कई खराब या जानबूझकर बनाई गई फ़ाइलें इसके बाद एक्स्ट्रा डेटा जोड़ देती हैं - यह एक क्लासिक "मल्टी-फ़ॉर्मैट पॉलीग्लॉट" तरीका है, जिसमें दूसरी फ़ाइल (स्क्रिप्ट, आर्काइव) एक साधारण दिखने वाली फ़ोटो के अंदर छिपकर साथ जाती है। चाहे कोई भी प्रीसेट चुना हो, यहां असल में होने वाली पूरी पिक्सेल रीकंस्ट्रक्शन इस मार्कर के बाद की हर चीज़ को एक स्ट्रक्चरल गारंटी के तौर पर हटा देती है, किसी खास जांच की तरह नहीं।
जानने लायक एक असली इतिहास
इमेज प्रोसेसिंग सॉफ़्टवेयर में गंभीर सुरक्षा खामियों के असली, दर्ज़ किए गए उदाहरण हैं - यह कोई काल्पनिक जोखिम नहीं है। "ImageTragick" (CVE-2016-3714) 2016 में एक व्यापक रूप से इस्तेमाल होने वाली इमेज लाइब्रेरी की एक कमज़ोरी थी, जिसमें खास तरीके से बनाई गई एक इमेज फ़ाइल उसे प्रोसेस करने वाले सर्वर पर कमांड चला सकती थी, और यह असल में इस्तेमाल होते हुए पाई गई थी। पूरी पिक्सेल रीकंस्ट्रक्शन ठीक इसी तरह की चीज़ को रोकने के लिए बनाई गई है: चाहे कोई भी प्रीसेट चुना हो, कहीं और किसी डिकोडर की गलती जो कुछ भी नज़रअंदाज़ कर देती, मूल फ़ाइल का वह असली बाइट कभी किसी ऐसी चीज़ तक नहीं पहुंचता जो उसे चला सके।
खासतौर पर JPEG के लिए कम्प्रेशन प्रीसेट चुनना
PNG या GIF के उलट, JPEG की क्वालिटी एक असली और मायने रखने वाला ट्रेड-ऑफ़ है - यहां "लॉसलेस" मोड बहुत ऊंची क्वालिटी को प्राथमिकता देता है (साइज़ से ज़्यादा फ़िडेलिटी को प्राथमिकता देने की वजह से यह कभी-कभी कड़े कम्प्रेस्ड मूल फ़ाइल से भी बड़ा हो सकता है), "बैलेंस्ड" एक ठीक-ठाक बीच का रास्ता देता है, और "सुपर कम्प्रेस्ड" तब असल में साइज़ घटाता है जब परफ़ेक्ट पिक्सेल क्वालिटी से ज़्यादा साइज़ मायने रखे। तीनों में मेटाडेटा बाइट-दर-बाइट बराबर हटता है - प्रीसेट सिर्फ़ पिक्सेल कम्प्रेस करने का तरीका बदलता है, जो हटाया जाता है वह कभी नहीं बदलता।