रिस्टोर की हुई फोटो की फाइल स्कैन से बड़ी क्यों हो सकती है

इसकी शुरुआत एक यूज़र की टिप्पणी से हुई: रिस्टोर किया डाउनलोड उनकी अपलोड की हुई फोटो से बड़ा था, जो “मरम्मत” के लिए सहज रूप से गलत लगता है। माप में दो स्वतंत्र कारण मिले: एक प्रोडक्ट का इरादे के मुताबिक काम करना है, दूसरा सचमुच बर्बादी थी जिसे हमने फिर हटा दिया।

कारण 1: आउटपुट में सच में ~6× पिक्सेल होते हैं

रिस्टोरेशन में पूरी इमेज का एन्हांसमेंट शामिल है: एक आम 821×1024 स्कैन (0.84 मेगापिक्सेल) 2052×2560 (5.25 मेगापिक्सेल) में लौटता है, पिक्सेल गिनती का 6.25×, और उन पिक्सेलों में असली गढ़ी हुई डिटेल होती है, खींची हुई कॉपियाँ नहीं। ज़्यादा जानकारी, ज़्यादा बाइट। यह हिस्सा फीचर है।

कारण 2: ब्राउज़र के PNG एनकोडर 20–40% फूले हुए हैं

बर्बादी वाला हिस्सा: ऐप शुरू में डाउनलोड को ब्राउज़र में कैनवास API के बिल्ट-इन PNG एनकोडर से एनकोड करता था। अधिकतम लॉसलेस सेटिंग वाले एक ठीक-ठाक ऑप्टिमाइज़िंग एनकोडर के मुकाबले, कैनवास एनकोडर पिक्सेल-दर-पिक्सेल एक जैसे आउटपुट के लिए 20–40% बड़ी फाइलें बनाता था। PNG दोनों तरह लॉसलेस है; अतिरिक्त बाइट से कुछ नहीं मिला।

सर्वर अब नतीजे वाला PNG एक बार अधिकतम लॉसलेस कम्प्रेशन पर एनकोड करता है, और क्लाइंट कैनवास से दोबारा एनकोड करने के बजाय डाउनलोड के लिए ठीक वही बाइट दोबारा इस्तेमाल करता है। यह दोबारा इस्तेमाल बनावट से ही सही है: डाउनलोड किया ब्लॉब वही है जिससे कैनवास पेंट हुआ था, इसलिए पिक्सेल अलग हो ही नहीं सकते।

जो हमने जानबूझकर नहीं किया

हमने छोटा आँकड़ा दिखाने के लिए लॉसी आउटपुट फॉर्मैट नहीं जोड़े। रिस्टोरेशन एक आर्काइवल कॉपी है, इसलिए डाउनलोड बटन आपको PNG देता है और कुछ नहीं; JPEG या WebP में बटोरने के लिए कोई मुफ्त लॉसलेस फायदा बचा नहीं है। और ऑन-डिवाइस फ़ॉलबैक मोड में प्रोसेस हुई फोटो ब्राउज़र एनकोडर ही रखती हैं; वे रन हमारे सर्वर को छूते ही नहीं।

व्यावहारिक निष्कर्ष

अगर आपकी रिस्टोर की हुई फाइल आपके स्कैन से बड़ी है, तो बर्बादी मानने से पहले उसके पिक्सेल आयाम जाँचें: 6× पिक्सेल पर कुछ बड़ी फाइल अपेक्षित नतीजा है, और छोटी फाइल का मतलब होगा कि डिटेल फेंक दी गई है।