الميزة الجديدة في الإصدار v1.1 هي إضافة قارئ صور مضغوط كسوري داخل التطبيق متوافق مع ImageIO.

لذلك ، يمكنك قراءة صورة مضغوطة (.dfc) مع التطبيق على النحو التالي:

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

مقارنة الصورة في تنسيق.jpg وفي تنسيق.dfc للتطبيق ، يمكنك أن ترى أن الجودة أسوأ إلى حد ما مما كانت عليه في.jpg وأنها تأخذ ملفًا أكبر قليلاً (كما هو متوقع).

لكن النتيجة ليست سيئة على الإطلاق.

ومع ذلك ، نظرًا لوقت المعالجة الطويل اللازم للانضغاط ، فإن هذا النوع من الضغط وتنفيذه في التطبيق له أهمية أكاديمية فقط.

2026/05/04 - 2026/12/04 - 2026/12/04 . بعد استعادة تطور هذا التطبيق ، أقترح إجراء اختبارات مع صور حقيقية ، وأحاول ذلك باستخدام واحد من "4000 3000" بكسل.

أواجه العديد من المشاكل:

• تستغرق العملية إلى الأبد في التكرارات المقسمة (بسبب التثليثات الواسعة التي تصل إلى 400،000 مثلث ، وأن فحص حالة الانقسام تكرر لجميع المثلثات في كل تكرار)
• تنفد الذاكرة بعد الوصول إلى حد 23 غيغابايت الذي كان لدي على نظامي. لأن:
  • تم تخزين نتيجة الانقسام ودمج التكرارات في قائمة منطقية (حوالي 16 تكرارًا نوعين من التثليث 3 قنوات 400،000 عنصر!!!!!). وهذا يجعل ما مجموعه حوالي 40،000،000 عنصر ، وهو أمر لا يزال مقبولًا)
  • بالإضافة إلى ذلك ، تم اختيار كتاب المثلثات الأكثر تمثيلاً (مجموعة إلى 256) باستخدام K-medoids (أكثر من عناصر 400,000) (أعتقد أن الذاكرة المستخدمة بواسطة هذه الخوارزمية هي O (n 2). الآن هو الخروج عن السيطرة...)
  • ولمزيد من INRI ، تم إجراء هذه الحسابات بالتوازي مع القنوات الثلاث (rgb)!!
• بمجرد حل هذه المشاكل ، تمكنت من ضغط الصورة (4000 3000) ، لكنني أرى أن الأمر يستغرق ما بين 6 و 8 ساعات لإكمال العمل.

وأقترح حلها:

• من أجل الأبدية من الانقسامات. الحل:
  • أقوم بزيادة الحد الأدنى لحجم المثلثات للتقسيم ، بطريقة تدريجية تتناسب مع عدد وحدات البكسل في الصورة. مما أدى إلى انخفاض في عدد المثلثات في المثلثات. في الصورة المستخدمة (4000 3000) يتم تقسيم عدد المثلثات على أكثر من 4 (ذهبنا من حوالي 400،000 مثلث إلى حوالي 100،000 مثلث).
  • بالإضافة إلى ذلك ، أقوم بإنشاء مجموعة مع المثلثات التي لا تفي بمعيار الانقسام (بالنسبة إلى تباين قيم وحدات البكسل الخاصة بها) ، حتى لا أكررها في كل تكرار. الآن يطير!!
• النظام ينفذ من الذاكرة. الحل:
  • نتيجة الانقسامات والدمج المحفوظة في القوائم المنطقية. الحل:
    • مع تقدم التكرارات المقسمة ، يكون عدد المثلثات التي تنقسم أصغر بشكل جذري ، ويتم حفظ الذاكرة المستخدمة عن طريق تخزين مؤشرات المثلثات التي تنقسم في مجموعة.
  • ذاكرة K-medoids (يفترض O (n 2)). الحل:
    • بما أننا قسمنا عدد المثلثات على 4... ، الذاكرة اللازمة لتلك الخوارزمية ، فإن هذا التخفيض للمثلثات ينطوي على قسمة الذاكرة المستخدمة على عامل يبلغ حوالي 16.
    • ثلاثة K-medoids بالتوازي (واحد لكل قناة). الحل:
      • نقوم بتسلسل حسابات التثليث واختيار المثلثات الأكثر تمثيلًا لكتاب التعليمات البرمجية (مع K-medoids).
    • لقد قسمنا الذاكرة اللازمة لـ K-medoids من 48!!
• يستغرق وقت المعالجة مع الصور "الحقيقية" إلى الأبد (يستغرق ضغط صورة المثال ما بين 6 و 8 ساعات) مع 3 خيوط ، واحدة لكل قناة. الحل:
  • جعل عدد من المواضيع شكلي. (من خلال تكوينه إلى 23 المواضيع (نظام بلدي لديه 24 النوى)، يتم تقليل وقت المعالجة إلى ثلاث ساعات ونصف).
• آثار الحل:
  • من الواضح أن تأثير قسمة عدد المثلثات على 4 يؤدي إلى خسارة ملحوظة في جودة الصورة المضغوطة. ولكن مع الكثير من الدقة ، ليس من المهم.
  • عند قسمة عدد المثلثات على 4 ، فإنه يؤدي أيضًا إلى تقسيم حجم الملف المضغوط ، من المفترض أيضًا أن يكون من ترتيب 4.

وأهدف أيضًا إلى محاولة تقليل حجم الملف المضغوط إلى الحد الأدنى ، وإعادة تنظيم المعلومات المراد تخزينها.

والفكرة هي الإشارة قبل كل شيء في ترميز قوائم فهرس المثلثات التي تنقسم في كل من التكرارات، التي كان الترميز التافه الأصلي هو استخدام بت واحد لكل مثلث، مشيرا إلى ما إذا كان تقسيم أم لا.

أنا وضع خوارزمية في محاولة لتقليل حجم اللازمة لتخزين كل من تلك مجموعات الفهرس.

أعتقد أنه لا يضيع... إذا كنت فضوليًا على هذا الموقع أقول النقاط الرئيسية التي اعتمدت عليها.

على الرغم من أنه ربما كان من الأجدر البحث عن ضاغط عام بدون خسارة مثل zip أو 7z وتطبيقه على عالمية الملف المضغوط... ربما في المرة القادمة.

في الإصدار الأخير من التسليم ، يتم تضمين تطبيق واجهة الأمر ، والذي يترجم أرشيف تم إنشاؤه مع إصدارات أقل تحسينًا للمبرمج ، إلى أحدث إصدار من المبرمج ، والذي يفترض أنه يشغل مساحة أقل.

باستخدام هذا التطبيق الجديد الصغير على زوج من الملفات مع الترميز الأصلي (واحد من 143 143 وآخر من 4000 3000) ، يتم تقليل حجم الملف المضغوط بحوالي 4٪ فيها.