मैंने आगे बढ़कर प्रयोग को दोहराया कि क्या मैं समझ सकता हूं कि क्या चल रहा है।
प्रक्रिया
मैंने डिफ़ॉल्ट सेटिंग्स का उपयोग करके GIMP (फ़िल्टर> रेंडर> क्लाउड> सॉलिड नॉइज़ ...) में "सॉलिड नॉइज़" फिल्टर का उपयोग करके एक यादृच्छिक 256-बाय-256 पिक्सेल RGB छवि उत्पन्न की (नीचे दिखाया गया है):
और परिणाम:
तब मैंने डिफ़ॉल्ट सेटिंग्स का उपयोग करके छवि को JPEG के रूप में सहेजा:
फिर मैंने छवि को विंडोज़ में स्थानांतरित कर दिया और फ़ाइल एक्सप्लोरर में छवि पर राइट-क्लिक करके और मेनू से पूर्वावलोकन का चयन करके छवि को विंडोज फोटो व्यूअर के साथ खोला । फिर मैंने नीचे के बटनों का उपयोग करके छवि को घुमाया, और तीर कुंजियों का उपयोग करके अगली छवि पर नेविगेट करके छवि को बचाया।
नीचे दिए गए प्रत्येक परीक्षण के लिए मैंने मूल छवि की एक प्रति के साथ शुरुआत की, और बचत करने से पहले संबंधित संख्या को घुमाया (घुमाए गए बटन पर क्लिक किया)। यहां आकार देने वाले आकार ( ls -l -r) हैं:
size in bytes last-modified date
VVVVV VVVVV
-rwxrwx--- 1 root vboxsf 6258 Nov 8 11:24 original.jpg
-rwxrwx--- 1 root vboxsf 23645 Nov 8 11:30 cw.jpg
-rwxrwx--- 1 root vboxsf 23636 Nov 8 11:30 cw-cw.jpg
-rwxrwx--- 1 root vboxsf 23649 Nov 8 11:30 cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf 6258 Nov 8 11:27 cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf 23649 Nov 8 11:31 cw-cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf 23649 Nov 8 11:29 ccw.jpg
-rwxrwx--- 1 root vboxsf 23636 Nov 8 11:29 ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf 23645 Nov 8 11:29 ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf 6258 Nov 8 11:27 ccw-ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf 23649 Nov 8 11:30 ccw-ccw-ccw-ccw-ccw.jpg
तत्काल टिप्पणियों
- विंडोज फोटो व्यूअर (WPV) आकार को नाटकीय रूप से बढ़ाता है; वृद्धि की मात्रा इस परीक्षण में लगभग चार गुना है!
- सभी नई छवियां समान आकार में बढ़ जाती हैं, लेकिन वे समान नहीं हैं।
- WPV उस छवि को फिर से एनकोड या री-सेव नहीं करता है, जब उसे 360 डिग्री से अधिक घुमाया जाता है। (टाइमस्टैम्प, 11:27, तब है जब फ़ाइलों को पहली बार कॉपी किया गया था।)
cmp -lसमान सामग्री वाली फ़ाइलों का उपयोग करने से हमें यह देखने की अनुमति मिलती है कि फ़ाइलें कहाँ भिन्न हैं।
robert@unity ../jpeg-rotate-test % cmp -l cw.jpg ccw-ccw-ccw.jpg
2223 63 62
2224 60 71
2226 60 64
2227 60 66
robert@unity ../jpeg-rotate-test % cmp -l cw-cw.jpg ccw-ccw.jpg
2223 63 62
2224 60 71
2226 60 64
2227 62 64
robert@unity ..jpeg-rotate-test % cmp -l ccw.jpg cw-cw-cw.jpg
2223 62 63
2224 71 60
2226 64 60
2227 61 64
robert@unity ../jpeg-rotate-test % cmp -l cw.jpg cw-cw-cw-cw-cw.jpg
2221 60 61
2223 63 61
2224 60 66
2226 60 61
2227 60 61
robert@unity ../jpeg-rotate-test % cmp -l ccw.jpg ccw-ccw-ccw-ccw-ccw.jpg
2223 62 63
2224 71 60
2226 64 65
2227 61 64
ये फाइलें केवल चार बाइट्स (वास्तव में टाइमस्टैम्प) में भिन्न होती हैं, जिसका अर्थ है कि WPV हर बार एक ही काम कर रहा है; अब हमें केवल यह पता लगाना है कि वह क्या है।
विस्तृत अवलोकन
इसके लिए मैंने JPEGsnoop का उपयोग यह देखने के लिए किया कि वास्तव में छवियों में क्या था।
चूंकि आउटपुट काफी लंबे हैं, इसलिए मैंने उन्हें एक जिस्ट के रूप में जोड़ा है । यहाँ अंतर का सारांश दिया गया है:
GIMP मेटाडेटा के लिए केवल APP0(JFIF) और COM(टिप्पणी) खंड का उपयोग करता है । WPV APP0खंड को अछूता छोड़ देता है , लेकिन उत्सुकता से टिप्पणी के लिए एक अशक्त बाइट जोड़ता है (ताकि यह शून्य-समाप्त हो जाए)।
WPV दो APP1खंडों को जोड़ता है, जो Exif और XMP मेटाडेटा हैं। ये सेगमेंट क्रमशः 4286 और 12726 बाइट्स हैं। साथ में वे फाइलों में लगभग पूरी वृद्धि के लिए खाते हैं।
GIMP एक प्रगतिशील JPEG का उत्पादन करता है, जबकि WPV एक आधारभूत (गैर-प्रगतिशील) JPEG का उत्पादन करता है। इस कारण से GIMP की छवि में कई स्कैन खंड हैं, जबकि WPV छवि में केवल एक है। मेरे अनुभव में प्रगतिशील छवि कभी-कभी थोड़ी छोटी होती है।
GIMP ने 1 × 1 क्रोमा सबसम्पलिंग का उपयोग किया, जबकि WPV ने 2 × 2 सबसम्पलिंग का उपयोग किया। यह मुझे विश्वास दिलाता है कि WPV "सच" दोषरहित रोटेशन का उपयोग नहीं कर रहा है, जब तक कि यह किसी भी तरह यह पता लगाने में सक्षम नहीं है कि यह एक ब्लैक-एंड-व्हाइट छवि है।
इन मुद्दों को हल करने के लिए, मैंने दूसरा परीक्षण चलाया।
प्रक्रिया
मैंने पहले परीक्षण के समान चरणों का पालन किया। मैंने निम्नलिखित चरणों के साथ RGB शोर फिल्टर (फ़िल्टर> नाक> RGB Nose ...) का उपयोग करके एक यादृच्छिक 256 × 256 RGB छवि बनाई:
यहाँ परिणाम है:
मैंने निम्न सेटिंग्स का उपयोग करके फ़ाइल को JPEG के रूप में निर्यात किया है:
प्रोग्रेसिव को बंद कर दिया गया है, लेकिन सबमप्लिमेंटिंग अभी भी 4: 4: 4 पर सेट है (जो 1 × 1 सबसम्पलिंग का दूसरा नाम है)। गुणवत्ता को बढ़ाकर 98 कर दिया गया है।
मैंने छवि को कॉपी किया और कॉपी को दक्षिणावर्त घुमाया; फिर घुमाए गए संस्करण की प्रतिलिपि बनाई और उस प्रति को वामावर्त घुमाया, ताकि हम सीधे मूल और WPP संसाधित प्रतिलिपि के बीच की गुणवत्ता की तुलना कर सकें।
परिणाम
-rwxrwx--- 1 root vboxsf 159774 Nov 8 16:21 original-random.jpg
-rwxrwx--- 1 root vboxsf 222404 Nov 8 16:24 cw-random.jpg
-rwxrwx--- 1 root vboxsf 222467 Nov 8 16:24 cw-ccw-random.jpg
यद्यपि इस समय की वृद्धि सापेक्ष रूप से छोटी है (लगभग 40%), पूर्ण वृद्धि इससे भी अधिक है - 62 kB के आसपास। यह बताता है कि WMV एक कम कुशल एन्कोडिंग का उपयोग कर रहा है।
मैं दो छवियों की तुलना करने के लिए ImageMagick का उपयोग करूँगा :
robert@unity ../jpeg-rotate-test % compare -verbose -metric AE original-random.jpg cw-ccw-random.jpg null:
original-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 160KB 0.000u 0:00.009
cw-ccw-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 222KB 0.010u 0:00.010
Image: original-random.jpg
Channel distortion: AE
red: 0
green: 0
blue: 0
all: 0
original-random.jpg=> JPEG 256x256 256x256+0+0 8-bit sRGB 0.050u 0:00.020
कर रहे हैं शून्य पिक्सल अलग मूल और घुमाया प्रतिलिपि के बीच। इसलिए, भले ही WPV "सच" दोषरहित रोटेशन का उपयोग नहीं कर रहा है, यह काफी अच्छा काम कर रहा है। मुझे संदेह है कि मुझे पता है कि क्या चल रहा है, और समझाने के लिए मैं जेपीईजी संपीड़न के पीछे गणित में थोड़ा सा मोड़ दूंगा।
JPEG कंप्रेशन एल्गोरिदम एक छवि को 8 × 8-पिक्सेल ब्लॉक में तोड़ता है। इन ब्लॉकों में से प्रत्येक को फिर एक असतत कोसाइन ट्रांसफॉर्म (डीसीटी) के अधीन किया जाता है । परिणामस्वरूप डीसीटी गुणांक ब्लॉक को विभिन्न-आवृत्ति तरंगों के योग के रूप में वर्णित करते हैं। एल्गोरिथ्म तब उच्च आवृत्ति तरंगों में कुछ जानकारी "दूर फेंकता है" जो शोर और बहुत छोटे विवरण के अनुरूप है। डिकोडिंग प्रक्रिया डीसीटी को उलट देती है, संग्रहीत तरंगों को जोड़कर ब्लॉक वापस लाने के लिए।
डीसीटी "तरंगों" को वास्तव में बिना परिवर्तन के पूर्ववत करना और फिर से करना संभव है (मूल रूप से आप सभी क्षैतिज तरंगों को ऊर्ध्वाधर तरंगों में बदल देते हैं और इसके विपरीत)। मुझे लगता है कि WPV में ऐसा होता है कि छवि वास्तव में डीकोड की जाती है, घुमाई जाती है, और फिर पुनः एनकोड की जाती है। पुन: एन्कोडिंग प्रक्रिया के दौरान, चूंकि हमारी छवि का आकार दोनों आयामों में 8 से अधिक है, इसलिए प्रत्येक नए ब्लॉक मूल ब्लॉकों में से एक से मेल खाते हैं। महत्वपूर्ण रूप से, चूंकि प्रत्येक ब्लॉक में उच्च-आवृत्ति वाले घटक नहीं होते हैं, एल्गोरिथ्म किसी भी जानकारी को नहीं फेंकता है, और बिल्कुल सही डीसीटी घटकों को पाता है जो "सच" दोषरहित रोटेशन होगा।
अंत में, मैं JPEG फ़ाइलों के घटकों को फिर से देखूँगा। परिणाम फिर से gists के रूप में जुड़े हुए हैं । दो की तुलना:
WPV छवि में Exif मेटाडेटा के अतिरिक्त 4286 + 2 बाइट, टिप्पणी में 1 अतिरिक्त बाइट और XMP मेटाडेटा के 12,726 + 2 बाइट्स हैं। यह अतिरिक्त मेटाडेटा की कुल 17,017 बाइट्स है। वह सभी डेटा किसके लिए उपयोग किया जाता है? मैं अपने भरोसेमंद हेक्स संपादक और संबंधित मानकों की एक प्रति के साथ फाइल में शामिल हुआ:
Exif मेटाडाटा एक TIFF चित्र है, जो टैग की एक संख्या में शामिल की तरह संरचित है (वहाँ जिस तरह से अधिक जटिलता है, लेकिन मैं सही इस पर छोड़ देंगे)। EA1Cएक्सिफ़ खंड में अधिकांश बाइट्स टैग संख्या (59,932 दशमलव) के साथ दो समान टैग में समाहित हैं । वह टैग नंबर कहीं भी प्रलेखित नहीं है जो मुझे मिल सकता है। दोनों टैग में "अपरिभाषित" प्रकार के 2060 बाइट्स हैं, जो पहले छह ( 1C EA 00 00 00 08) को छोड़कर सभी अशक्त बाइट्स हैं । मुझे नहीं पता कि ये टैग क्या हैं, उनमें से दो क्यों हैं, और उन्हें प्रत्येक में 2 kB होने की आवश्यकता क्यों है।
एक्सएमपी मेटाडेटा वास्तव में नेमस्पेसिंग और लंबे यूयूआईडी के साथ एक संपूर्ण एम्बेडेड एक्सएमएल दस्तावेज है, जिसमें बस WPV संस्करण स्ट्रिंग (जो कि पहले से ही Exif मेटाडेटा में था) शामिल है। हालाँकि, यह केवल लगभग 400 बाइट्स के लिए खाता है। इस खंड के शेष भाग में 100 स्थानों के 122 पुनरावृत्तियाँ हैं, इसके बाद एक नई पंक्ति है । यह पूरी तरह से बर्बाद अंतरिक्ष के 12,000 से अधिक बाइट्स है।
पिछले परीक्षण की तरह, GIMP और WPV दोनों समान DCT परिमाणीकरण तालिकाओं का उपयोग करते हैं। इसका मतलब है कि उन्हें ठीक उसी डीसीटी गुणांक की गणना की जानी चाहिए, यही वजह है कि चित्र बिल्कुल समान हैं। मुझे यकीन नहीं है कि अगर WPV सिर्फ उसी परिमाणीकरण तालिकाओं का उपयोग कर रहा है या यदि यह इनपुट से तालिकाओं को कॉपी करता है।
पिछले परीक्षण के विपरीत, इस बार WPV 1 × 1 सबसेंपलिंग का उपयोग करता है, इसलिए यह वास्तव में यह पता लगा सकता है कि यह एक रंग छवि है (या कम से कम यह कि उच्च नमूने छवि को फिर से एनकोड करने के लिए आवश्यक हैं)।
GIMP और WPV अलग-अलग हफ़मैन तालिकाओं (एन्ट्रॉपी कोडिंग स्टेप का हिस्सा) का उपयोग करते हैं। WPV के लिए टेबल कुल 279 बाइट्स से बड़ी हैं, और एक मामले में 7 बार कई कोड होते हैं।
JPEGsnoop के आँकड़ों को देखते हुए, हम देख सकते हैं कि इनमें से कुछ कोड शायद ही कभी उपयोग किए जाते हैं। उदाहरण के लिए, ID: 1, Class: ACतालिका में, 119 16-बिट कोड परिभाषित किए गए हैं, केवल 23 वास्तव में उपयोग किए जाते हैं। कुल मिलाकर, WPV संस्करण में वास्तविक स्कैन खंड 28.5% बड़ा है।
सारांश
WPV "सत्यहीन" दोषरहित घुमाव नहीं कर सकता है, लेकिन घूर्णन व्यावहारिक रूप से दोषरहित प्रतीत होता है।
अतिरिक्त आकार आंशिक रूप से अतिरिक्त मेटाडेटा की एक निश्चित मात्रा के कारण है, और आंशिक रूप से कम कुशल एन्ट्रापी कोडिंग के कारण है।
संस्करण जानकारी:
OS (लिनक्स) ( uname -a):
Linux unity 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
ओएस (विंडोज):
GIMP (लिनक्स): 2.8.14 (पैकेज gimp, संस्करण से 2.8.14-1+deb8u1)
विंडो फोटो दर्शक (छवि मेटाडेटा के अनुसार):
Microsoft Windows Photo Viewer 10.0.10586.0