कभी-कभी जब आप एक छवि डाउनलोड कर रहे होते हैं और कनेक्शन मध्य धारा को तोड़ देता है, तो आपको आधी डाउनलोड की गई छवि के साथ छोड़ दिया जाता है। यदि आप इसे देखने की कोशिश करते हैं तो आपको छवि का ऊपरी भाग मिलता है और नीचे का भाग आमतौर पर भूरे या हरे या किसी अन्य रंग का होता है। दूसरे शब्दों में, यह भ्रष्ट है।
क्या यह जांचने का कोई तरीका है कि क्या छवि उस तरह से क्षतिग्रस्त है या अन्यथा दूषित है?
जवाबों:
यदि आप JPEG फ़ाइलों के बारे में बात कर रहे हैं, तो उपयोगिता jpeginfo बिल्कुल वही है जो आप देख रहे हैं। यह विभिन्न प्रकार की जेपीईजी त्रुटियों और भ्रष्टाचार के लिए फाइलों की जांच कर सकता है और या तो एक त्रुटि कोड (स्क्रिप्टिंग के लिए सबसे उपयोगी चीज) लौटाता है, या त्रुटियों के साथ फाइलें हटा देता है।
मैं अपनी प्रारंभिक फ़ाइल स्थानांतरण के हिस्से के रूप में इसका उपयोग करता हूं, यह सुनिश्चित करने के लिए कि मैन्युअल जाँच पर भरोसा किए बिना सब कुछ ठीक किया गया है। (उसके बाद, मैं यह सुनिश्चित करता हूं कि उनके चेकसम मेरे सामान्य बैकअप / बिट्रोट सुरक्षा के हिस्से के रूप में परिवर्तित न हों।)
कार्यक्रम कमांड-लाइन है, और स्रोत कोड के रूप में आता है, लेकिन किसी भी लिनक्स वितरण या मैक पर एक विकास वातावरण के साथ ठीक से स्थापित करने के लिए इसका निर्माण और उपयोग करना आसान होना चाहिए। मुझे यकीन है कि आप इसे सिगविन या मिनगव के साथ विंडोज पर भी कर सकते हैं। (उदाहरण के लिए, हालांकि मैं इसकी अखंडता के लिए व्रत नहीं कर सकता, यह ब्लॉग पोस्ट कानूनी लगता है और इसमें एक पूर्वनिर्धारित डाउनलोड भी शामिल है।) इसे स्वयं बनाने के लिए:
$ git clone https://github.com/tjko/jpeginfo.git
Cloning into 'jpeginfo'...
[...]
Checking connectivity... done
$ cd jpeginfo/
$ ./configure && make
यह एक jpeginfoकमांड बनाना चाहिए जिसे आप या तो जगह पर चला सकते हैं या जहाँ चाहें (संभवतः उपयोग करके make install) कॉपी कर सकते हैं ।
फिर, आप इसे इस तरह चलाते हैं:
$ ./jpeginfo -c *.jpg
test1.jpg 1996 x 2554 24bit Exif P 6582168 [OK]
test2.jpg 1996 x 2554 24bit Exif P 6582116 Premature end of JPEG file [WARNING]
test3.jpg Corrupt JPEG data: 1 extraneous bytes before marker 0xe2 1996 x 2554 24bit Exif P 6582169 [WARNING]
यहाँ, test1.jpg पूरी तरह से ठीक है, और test2.jpg मैंने अंत से कुछ बाइट्स हटा दिए, और test3.jpg मैंने हेडर में कुछ यादृच्छिक बाइट्स बदल दिए।
यदि आपके पास RAW फाइलें हैं, तो इस पृष्ठ को अमेरिकन सोसाइटी ऑफ़ मीडिया फ़ोटोग्राफ़रों की DNG वैलिडेशन पर , या डेटा सत्यापन विवरणों में से एक पर देखें , जो Adobe-DNG कन्वर्टर का उपयोग बैच-प्रॉपर मालिकाना RAW प्रारूपों का उपयोग करने के लिए करता है। (दुर्भाग्य से, यह एक जीयूआई ऑपरेशन है और जरूरी नहीं कि आसानी से स्क्रिप्ट योग्य हो।)
यदि आपके पास एक कैमरा है जो मूल रूप से DNG के 1.2 संस्करण का आउटपुट देता है, तो यह और भी बेहतर है, क्योंकि इसमें छवि डेटा का एक अंतर्निहित MD5 चेकसम शामिल है। दुर्भाग्य से, यह सामान्य छवि मेटाडेटा के साथ संग्रहीत नहीं किया जा सकता है - या कम से कम एक्सफ़ॉल और एक्सिव 2 इसे नहीं पहचानते हैं, और वे सामान्य रूप से 1.2 डीएनजी फाइलें पढ़ते हैं - जिसका अर्थ है कि जहां तक मुझे पता है कि वर्तमान में एडोब सत्यापन टूल उसी का फायदा उठाने का एकमात्र तरीका है।
ImageVerifier ने वही किया जो आप चाहते थे। दुर्भाग्य से यह अब डाउनलोड करने के लिए उपलब्ध नहीं है और 31-दिसंबर -2017 को समर्थन बंद कर दिया गया है (देखें बिक्री के लिए अब इनिस्टैमैटिक और इमेज वीयरिफायर )।
ImageVerifier (IV for short) सत्यापित करने के लिए छवि फ़ाइलों की तलाश करने वाले फ़ोल्डरों के पदानुक्रम का पता लगाता है। यह TIFF, JPEGs को सत्यापित कर सकता है। पीएसडी, डीएनजी और गैर-डीएनजी कच्चे (जैसे, एनईएफ, सीआर 2)।
IV को बड़ी संख्या में छवियों को संसाधित करने के लिए डिज़ाइन किया गया है। 100,000 छवियों या अधिक के साथ फ़ोल्डर पदानुक्रम कोई समस्या नहीं होनी चाहिए। एक टेस्ट रन में, IV 14 घंटे तक चला।
दो प्रकार के सत्यापन हैं जो IV करता है: संरचना की जाँच और हैश की जाँच।
यदि यह आपके कैमरे से छवियों को डाउनलोड करने के बारे में नहीं है, लेकिन एक कंप्यूटर-से-कंप्यूटर हस्तांतरण, फ़ाइल अखंडता के लिए एक सामान्य दृष्टिकोण चेकसम हैं ।
दुर्भाग्य से, जहां तक मुझे पता है, आम "एंड यूज़र" छवि प्रारूप (जेपीईजी, पीएनजी, जीआईएफ, ...) अपने आप अखंडता-जांच नहीं हैं। लेकिन जैसा कि मैंने समझा कि स्वचालित प्रसंस्करण को लागू करने के लिए सवाल है, वर्कफ़्लो टूल ( CRC32 , MD5 ,…) को वर्कफ़्लो में एकीकृत करना एक व्यवहार्य समाधान हो सकता है। चेकसम को संचय करने के लिए एक सामान्य दृष्टिकोण एक फ़ाइल नाम के साथ एक फ़ाइल है, बस एक जोड़ा एक्सटेंशन के साथ, जैसे img123.jpg → img123.jpg.md5:।
इस दृष्टिकोण में अतिरिक्त लाभ है कि आप (उदाहरण के लिए) साइडइकर फ़ाइलों की अखंडता की जांच कर सकते हैं या कुछ और जिसे आप एक समान तंत्र में स्थानांतरित करना चाहते हैं। और अगर आप भविष्य में भी चेकसम फाइलों को इधर-उधर रखते हैं। (और यह मेरे सीमित ज्ञान की सीमा तक पीएस, एलआर, या अन्य सामान्य उपकरणों में एकीकृत नहीं होने का नकारात्मक पहलू है।)
मैंने check_media_integrity को एक साधारण अजगर लिपि विकसित की है check_mi.py, आप इसे GitHub से डाउनलोड कर सकते हैं:
https://github.com/ftarlao/check-media-integrity
मैं गाइड परिचय को उद्धृत करता हूं:
check-mi एक पायथन 2.7 स्क्रिप्ट है जो स्वचालित रूप से मीडिया फ़ाइलों (चित्रों, वीडियो, ऑडियो) की अखंडता की जांच करती है। आप एक फ़ाइल की अखंडता की जाँच कर सकते हैं, या एक फ़ोल्डर में फ़ाइलों का सेट और सबफ़ोल्डर को पुनरावृत्ति कर सकते हैं, अंत में आप वैकल्पिक रूप से खराब फाइलों की सूची को उनके पथ और विवरणों के साथ सीएसवी प्रारूप में आउटपुट कर सकते हैं।
उपकरण सामान्य पुस्तकालयों (तकिया, ImageMagik, FFmpeg) का उपयोग करके फ़ाइल की अखंडता का परीक्षण करता है और जब वे प्रभावी रूप से मीडिया फ़ाइलों को डीकोड करने में सक्षम होते हैं, तो जाँच करते हैं। चेतावनी, छवि, ऑडियो और वीडियो प्रारूप दोषों और क्षतियों के लिए बहुत लचीले हैं, इस कारण से उपकरण सभी क्षतिग्रस्त फ़ाइलों का पता नहीं लगा सकता है।
चेक-मील सक्षम है, 100% आत्मविश्वास के साथ, उन फ़ाइलों को स्पॉट करने के लिए, जिनमें हेडर / मेटाडेटा, टूटी हुई छवि फाइलें (सख्त_लेवल> 0 के साथ), और डिवाइस i / o त्रुटियां हैं।
चेक-एमआई, आमतौर पर, सभी छोटे नुकसानों का पता लगाने में सक्षम नहीं है - जैसे मीडिया फ़ाइल का छोटा हिस्सा विभिन्न मूल्यों के साथ ओवरराइट किया गया। विस्तार से, मैंने एक छोटे यादृच्छिक प्रयोग के साथ सख्त_लेवल 1 का परीक्षण किया है, जिसे एक एकल 5 एमबी जेपीईजी चित्र पर निष्पादित किया गया है:
शून्य के साथ छवि फ़ाइल के एक हिस्से (अंतराल) को ओवरराइट करना, क्षति का पता लगाने का 50% मौका पाने के लिए आपको अंतराल आकार = 1024KBytes की आवश्यकता होती है। विभिन्न यादृच्छिक मूल्यों के साथ छवि फ़ाइल के एक हिस्से (अंतराल) को ओवरराइट करते हुए, आप 4096bytes से 1024Kbytes तक के अंतराल आकारों के लिए लगभग 85% का पता लगाने का अनुपात प्राप्त करते हैं।
मामले में जब आप जानते हैं कि पिलो, वैंड और एफएफएमपीपी को डिकोड करने के लिए सख्त होने के निर्देश हैं, तो कृपया मुझे बताएं।
स्वीकार किए गए उत्तर में जेपेगिनफो का उपयोग होता है, जो कि सी (और साथ ही बहुत मॉड्यूलर / एक्स्टेंसिबल भी नहीं) में लिखा गया एक पुराना और गैर-अनुरक्षित उपकरण है। इसके अलावा, यह उपकरण बस कुछ विशिष्ट EXIF डेटा बिंदुओं के लिए लगता है ( ~ 5 मिनट के लिए स्रोत कोड के माध्यम से स्किम )।
IMO, एक बेहतर टूल, जिसे फ़ाइल-प्रकार कहा जाता है, का उपयोग करना बहुत आसान है - मूल रूप से उनके उदाहरण कोड को कॉपी-पेस्ट करें और यदि आप कोड नहीं जानते हैं तो फ़ाइल नाम को संशोधित करें। यह कुछ ज्ञात फिल्टिप के साथ जुड़े मैजिक नंबरों की जांच करता है और आपको यह बताता है कि आप किस तरह की फाइल के साथ काम कर रहे हैं।
मैं अभी भी सिर्फ इस से सुरक्षा की अधिक परतों की तलाश कर रहा हूं। उदाहरण के लिए, यदि मनमाने ढंग से डेटा EXIF मेटाडेटा, या मैजिक नंबरों के बाद संग्रहित किया जाता है, तो इससे सुरक्षा समस्याएं उत्पन्न हो सकती हैं। मैं अधिक सुरक्षा उपायों पर ध्यान देना चाहता हूं और बाद में इस उत्तर को अपडेट करने की उम्मीद करता हूं।
यहाँ आलसी के लिए उनके वेबपेज से कॉपी किया गया उदाहरण कोड है:
// Node.js
const readChunk = require('read-chunk');
const fileType = require('file-type');
const buffer = readChunk.sync('unicorn.png', 0, fileType.minimumBytes);
fileType(buffer);
//=> {ext: 'png', mime: 'image/png'}
FYI करें, इस टूल को लगातार अपडेट किया जा रहा है (3 दिन पहले अंतिम अपडेट था, जैसा कि मेरे मूल उत्तर के रूप में यहां दिया गया है), और उनके पास वर्तमान में 3,691,850 साप्ताहिक डाउनलोड हैं - इसलिए यह शायद एक अच्छा संकेत है।
file(जो इसी तरीके से काम करता है) सही तरीके से रिपोर्ट करेगा, लेकिन रेंडर करने में विफल रहेगा क्योंकि डेटा का अधिकांश हिस्सा वास्तव में गायब है।