संस्करण v1.1 में नई विशेषता अनुप्रयोग के भीतर एक विंडो-कंस्क्ड छवि रीडर के साथ मेल खाती है जो कि छवि आईआईओ के साथ संगत है.

अतः, आप अनुप्रयोग के साथ संपीडित छवि (. ddc) पढ़ सकते हैं:

BufferedImage image = ImageIO.read("image.dfc");

छवि की तुलना.jpg की फॉर्मेट में और अनुप्रयोग के लिए अनुप्रयोग के फ़ॉर्मेट में, आप देख सकते हैं कि गुणवत्ता किसी से भी बदतर है.jpg की तुलना में यह थोड़ा बड़ा फ़ाइल लेता है (जैसे कि उम्मीद है).

लेकिन परिणाम सब पर बुरा नहीं है.

लेकिन, संपीडन के लिए लंबे समय की ज़रूरत पड़ी, इस प्रकार की संपीडन और अनुप्रयोग में इसकी कार्यान्वयन केवल शैक्षिक दिलचस्पी की बात है ।

04/05/2026 - 04/12/2026 .. इस अनुप्रयोग के विकास को ठीक करने के बाद, मैं असली छवियों के साथ परीक्षण करने का प्रस्ताव किया, और मैं इसे एक "4000 x 300 मिमी पिक्सेल के साथ कोशिश की.

मैं कई समस्याओं का सामना करता हूँ:

• इस प्रक्रिया को विभाजित करने के लिए हमेशा के लिए विभाजित करता है (30,000 त्रिकोण के विस्तार से 40,000 त्रिकोण के लिए), और कि विभाजित शर्त प्रत्येक त्रिकोण में सभी त्रिकोण के लिए दोहराया गया था)
• स्मृति 23 GB की सीमा तक पहुँचने के बाद चला जाता है कि मैं अपनी प्रणाली पर था. क्योंकि:
  • विभाजित और जोड़ने का परिणाम एक बुलियन सूची में जमा किया गया था (दूर 16 यह है x 3 चैनल x 4000 तत्वों के 2 प्रकार!
  • इसके अलावा, अधिकांश प्रतिनिधि त्रिकोण की पुस्तक के चयन को के रूप में बाहर किया गया था (४: ४,००० तत्वों से अधिक तत्वों) (मुझे लगता है कि एल्गोरिथ्म ओ(n^2) द्वारा इस्तेमाल किया जाता है. अब यह हाथ से बाहर हो रहा है...)
  • और अधिक के लिए, उन गणना तीन चैनलों के समानांतर किया गया!
• एक बार जब उन समस्याओं को हल किया जाता है, मैं (4000 x 300) छवि को निर्धारित करता हूँ, लेकिन मुझे लगता है कि यह काम पूरा करने के लिए 6 से 8 घंटे लेता है.

और मैं उन्हें हल करने के लिए प्रस्ताव:

• क्योंकि विभाजित किए जाने का समय, और हल है:
  • मैं त्रिकोण के न्यूनतम आकार को विभाजित करने के लिए, एक चरणिक प्रकार में पिक्सेल की संख्या के लिए। परिणाम की संख्या में त्रिकोण की संख्या में कमी। 4000 से 300 बार त्रिकोण की संख्या 4 से अधिक विभाजित है।
  • इसके अतिरिक्‍त, मैं त्रिकोण के साथ एक सेट बनाता हूँ जो विभाजित मापदंड (उनकी पिक्सेल के मूल्यों के बीच फर्क नहीं करता) के साथ, ताकि उन्हें प्रत्येक भाग में दोहराने के लिए नहीं. अब मक्खी!
• समस्या:
  • बुलियन सूची में सहेजा गया फूटता है तथा भाग को आगे बढ़ाता है. हल:
    • जैसा कि यह विभाजित होता है, त्रिकोण की संख्या जो आधारित रूप में विभाजित होता है वह वास्तविक रूप से छोटा है, स्मृति जो एक सेट में विभाजित होता है उसे जमा करने के द्वारा सहेजा जाता है.
  • के- एमडिस्काइड्स की मेमोरी (प्रयोगात्मक रूप से ओ( n^2). परिणाम:
    • के रूप में हम 4 से त्रिकोण की संख्या विभाजित किया है..., स्मृति उस एल्गोरिथ्म के लिए जरूरी है, त्रिकोण की इस कमी में 16 के एक कारक द्वारा इस्तेमाल किया स्मृति को विभाजित करना शामिल है।
    • समानांतर में तीन केमाइड ( प्रत्येक चैनल के लिए एक). परिणामः
      • हम विभिन्न ढंग से त्रिकोण की गणना करते हैं और कोड-बुक के लिए अधिकतर ईमेल त्रिकोण के चयन (के-एम्डाइड के साथ).
    • हमने 48 केमाइड के लिए आवश्यक स्मृति विभाजित की है!
• "सही" छवि के साथ प्रक्रिया समय हमेशा के लिए लेता है (उदाहरण के लिए उदाहरण छवि का संपीडन 3 से 8 घंटे के बीच होता है) प्रत्येक चैनल के लिए. समाधान:
  • थ्रेड कॉन्फ़िगर करने योग्य होने वाली संख्या बनाइए. (अपनी तंत्र को 23 थ्रेड (मेरे तंत्र को 24 कोर) कॉन्फ़िगर करने के द्वारा, प्रक्रिया का समय साढ़े तीन घंटे तक कम हो जाता है.
• समाधान का प्रभाव:
  • 4 द्वारा त्रिकोण की संख्या को 4 से विभाजित करने का प्रभाव निश्चित रूप से समझौता छवि की गुणवत्ता की एक उल्लेखनीय कमी में परिणित होता है. लेकिन इतना प्रस्ताव के साथ, यह महत्वपूर्ण नहीं है.
  • जब त्रिकोण की संख्या को 4 से विभाजित करता है तो यह संपीडित फ़ाइल के आकार को भी विभाजित करता है, जिन्हें 4 के क्रम से भी विभाजित किया जाता है.

मैं यह भी संकल्प करता हूँ कि संपीडित फ़ाइल के आकार को कम करने की कोशिश करें, जानकारी को भंडारित करने के लिए पुनः लोड किया जाए.

विचार है कि त्रिकोण की निर्देशिका सूची में सभी के ऊपर सूचित करना है जो हर एक हिस्से में विभाजित होता है, जिसका मूल छोटा कोडिंग प्रति एक बिट का उपयोग करने के लिए था, यदि वह विभाजित होता या नहीं.

मैं एक एल्गोरिथ्म की योजना बना उन निर्देशिका सेट के प्रत्येक स्टोर के लिए आवश्यक आकार को कम करने के लिए कोशिश करने के लिए एक एल्गोरिथ्म.

मुझे लगता है कि यह बर्बाद नहीं है... अगर आप उत्सुक हैं इस वेबसाइट पर मैं महत्वपूर्ण मुद्दों को बताता हूँ कि मैं किस पर भरोसा किया है.

हालांकि शायद एक सामान्य नुकसानकर्ता के लिए देखना अधिक लाभप्रद होता...... ज़िप या 7z की तरह और इसे संपीडित फ़ाइल की वैश्विकता पर लागू करें... शायद अगले समय के लिए.

प्रसव के अंतिम संस्करण में, एक कमांड इंटरफेस अनुप्रयोग शामिल है जिसमें एक अभिलेख बनाया गया है जो कोडर के कम समाधानित संस्करण के साथ, जो कि कोडर के नवीनतम संस्करण में, जो कि सीमित जगह लेता है.

मूल एनकोडिंग के साथ फ़ाइलों के जोड़े पर इस छोटा सा अनुप्रयोग का उपयोग किया जा रहा है (3143 में से एक और 4000x300), यह है कि उन में 4% द्वारा कम किया गया है.