Новая функция в версии v1.1 - это добавление фрактал-компрессированного считывателя изображений в приложение, совместимое с IMO.

Таким образом, вы можете прочитать сжатое изображение (.dfc) со следующим приложением:

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

Сравнивая изображение в формате.jpg и в формате.dfc приложения, вы можете увидеть, что качество несколько хуже, чем в.jpg, и что он занимает несколько более крупный файл (как и ожидалось).

Но результат совсем не плох.

Однако с учетом продолжительного времени, необходимого для обработки сжатия, этот тип сжатия и его применение в заявке представляют лишь академический интерес.

04/05/2026 - 04/12/2026 После восстановления эволюции этого приложения, я предлагаю провести тесты с реальными изображениями, и я попробую его с одним из пикселей "4000 x 3000".

Я сталкиваюсь со многими проблемами:

• Процесс занимает вечность в разделительных итерациях (из-за обширных триангуляции до 400 000 треугольников и что проверка на разделение была повторена для всех треугольников в каждой итерации)
• Память заканчивается после того, как я достиг предела в 23 ГБ, который был у меня в организме.
  • Результат разделения и слияния итераций хранился в булевом списке (около 16 итераций х 2 типа триангуляции х 3 канала х 400 000 элементов!!!!!!!!), что в общей сложности составляет около 40 000 000 элементов, что все еще приемлемо)
  • Кроме того, выбор книги наиболее репрезентативных треугольников (начиная с 256) был произведен с помощью K-медоидов (более 400 000 элементов) (я думаю, что память, использованная этим алгоритмом, о(n)2. Теперь она выходит из-под контроля...)
  • И, что касается еще INRI, эти расчеты проводились параллельно по трем каналам (Rgb)!!
• Как только эти проблемы будут решены, я смогу сжать изображение (4000 x 3000), но я вижу, что для завершения работы требуется от 6 до 8 часов.

И я предлагаю решить их:

• За вечность раскола. Решение:
  • Я увеличиваю минимальный размер треугольников для деления, шаг за шагом пропорциональный количеству пикселей в картинке, что приводит к сокращению числа треугольников в триангуляциях. В используемом образе (4000 x 3000) число треугольников делится более чем на 4 (мы перешли от примерно 400 000 треугольников к примерно 100 000 треугольников).
  • Кроме того, я создаю набор с треугольниками, которые не отвечают критерию разделения (относительно разницы значений их пикселей), чтобы не повторять их в каждой итерации.
• У системы кончается память. Решение:
  • Результат разделения и слияния в булевых списках. Решение:
    • По мере развития итераций, числа треугольников, которые делятся, значительно меньше, используемая память сохраняется путем хранения индексов треугольников, которые делятся в наборе.
  • Память о K-медоидах (предположительно O(n)2). Решение:
    • Поскольку мы разделили число треугольников на 4, память, необходимая для этого алгоритма, это сокращение треугольников предполагает разделение памяти, используемой коэффициентом около 16.
    • Параллельно три к-медоида (по одному на каждый канал). Решение:
      • Мы последовательно вычисляем триангуляции и выбираем наиболее репрезентативные треугольники для книги кодов (с K-медоидами).
    • Мы разделили память, необходимую для К-медоидов 48!
• Время обработки "реальных" изображений занимает вечность (сжатие примера занимает от 6 до 8 часов) с тремя нитями, по одной для каждого канала. Решение:
  • Сделайте количество ниточек перегруппируемым. (Назначив их 23 нитями (в моей системе 24 ядра), время обработки сокращается до трех с половиной часов).
• Последствия решения:
  • Последствие деления числа треугольников на 4, очевидно, приводит к заметной потере качества сжатого изображения, но с такой разрешающей способностью, это не так важно.
  • Разделяя число треугольников на 4, это также приводит к разделению размера сжатого файла, предположительно также порядка 4.

Я также пытаюсь свести к минимуму размер сжатого файла, реорганизовав информацию, которая будет храниться.

Идея заключается прежде всего в том, чтобы указать в индексных списках треугольников, которые делятся в каждой из итераций, чье первоначальное тривиальное кодирование состояло в том, чтобы использовать один бит на треугольник, и указать, раскололся ли он или нет.

Я разрабатываю алгоритм, чтобы попытаться свести к минимуму размер, необходимый для хранения каждого из этих наборов индексов.

Я думаю, это не пустая трата... если вам любопытно. На этом сайте я рассказываю о ключевых моментах, на которые я опирался.

Хотя, возможно, было бы более целесообразно найти общий бесполезный компрессор, как Zip или 7z, и применить его к глобализму сжатого файла... возможно, в следующий раз.

В последней версии передачи включалось приложение командного интерфейса, которое переводит архив, созданный с менее оптимизированными версиями кодера, на последнюю версию кодера, которая, предположительно, занимает меньше пространства.

Используя это небольшое новое приложение на паре файлов с оригинальным кодированием (одно из 143x143 и другое из 4000x3000), размер сжатого файла сокращается примерно на 4% в них.