La novedad de la versión v1.1 es que añade un reader de imágenes comprimidas fractalmente con la aplicación que es compatible con ImageIO.

Así pues se puede leer una imagen comprimida con la aplicación (.dfc) de esta manera:

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

En la comparativa de la imagen en .jpg y en el formato de la aplicación .dfc, se puede observar que la calidad es algo peor que la de .jpg y que ocupa algo más (como era de esperar).

Pero el resultado no está mal del todo.

Aunque dado el alto tiempo de procesamiento tomado para comprimir, este tipo de compresión y su implementación en la aplicación solo tienen cierto interés académico.

05/04/2026 - 12/04/2026. Tras haber recuperado la evolución de esta aplicación, me propongo hacer pruebas con imágenes de verdad, y la pruebo con una de "4000 x 3000" pixels.

Me encuentro con muchos problemas:

• El proceso se eterniza en las iteraciones de split (debido a las extensas triangulaciones de hasta alrededor de 400.000 triángulos, y que se repetía la comprobación de la condición de split para todos los triángulos en cada iteración)
• La memoria se agota tras alcanzar el límite de 23 GB que tenía en mi sistema. Debido a que:
  • El resultado de las iteraciones de split y merge se almacenaban en una lista de boolean (alrededor de 16 iteraciones x 2 tipos de triangulaciones x 3 canales x 400.000 elementos !!!!). Eso hace un total de alrededor de 40.000.000 de elementos, cosa todavía asumible)
  • Además, la elección del book de triángulos más representativos (configurado a fuego a 256), se realizaba con un K-medoids (sobre 400.000 elementos) (creo que la memoria usada por ese algoritmo es O(n^2). Ahora sí que ya se nos va de las manos ...)
  • Y, para más INRI, se realizaban esos cálculos en paralelo para los tres canales (rgb) !!
• Una vez solucionados esos problemas, consigo que se comprima la imagen de (4000 x 3000), pero veo que tarda entre 6 y 8 horas en realizar el trabajo.

Y me propongo solucionarlos:

• Para la eternización de los split. Solución:
  • Aumento el tamaño mínimo de los triángulos para hacer split, de manera escalonadamente proporcional al número de píxels de la imagen. Resultando en una rebaja del número de triángulos de las triangulaciones. En la imagen usada de (4000 x 3000) se divide el número de triángulos por más de 4 (pasamos de unos 400.000 triángulos a unos 100.000 triángulos).
  • Además, creo un Set con los triángulos que no cumplen con el criterio de split (relativos a la varianza de los valores de sus píxeles), para no repetirlos en cada iteración. Ahora vuela !!
• Se agota la memoria del sistema. Solución:
  • Resultado de splits y merge guardados en listas de booleanos. Solución:
    • Como a medida que avanzan las iteraciones de split, el número de triángulos que hacen split es radicalmente menor, se ahorra memoria usada almacenando los índices de los triángulos que hacen split en un Set.
  • Memoria de K-medoids (presumiblemente O(n^2)). Solución:
    • Como hemos dividido el número de triángulos por 4 ..., la memoria necesaria para ese algoritmo, esta reducción de triángulos implica dividir la memoria utilizada por un factor de alrededor de 16.
  • Tres K-medoids en paralelo (uno para cada canal). Solución:
    • Secuencializamos los cálculos de las triangulaciones y de la elección de los triángulos más representativos para el code-book (con K-medoids).
  • Hemos dividido la memoria necesaria para el K-medoids por 48!!
• El tiempo de procesamiento con imágenes "de verdad", se eterniza (la compresión de la imagen de ejemplo tarda entre 6 y 8 horas) con 3 hilos, uno para cada canal. Solución:
  • Hacer configurable el número de hilos. (Configurándolo a 23 hilos (mi sistema tiene 24 cores), el tiempo de procesamiento se reduce a tres horas y media).
• Efectos de la solución:
  • El efecto de dividir el número de triángulos por 4 se traduce, evidentemente, en una pérdida notable de la calidad de la imagen comprimida. Pero al tener tanta resolución, pues no es tan importante.
  • Al dividir el número de triángulos por 4, también produce que se divida el tamaño del archivo comprimido, supuestamente también del orden de por 4.

También me pongo como objetivo tratar de minimizar el tamaño del archivo comprimido, reorganizando la información a almacenar.

La idea es indicir sobre todo en la codificación de las listas de índices de los triángulos que hacen split en cada una de las iteraciones, cuya codificación original trivial era usar un bit por triángulo, indicando si hacía split o no.

Ideo un algoritmo para tratar de minimizar el tamaño necesario para almacenar cada uno de esos conjuntos de índices.

Creo que no tiene desperdicio ... si tienes curiosidad en este sitio web cuento los puntos clave en los que me he basado.

Aunque quizás hubiera valido más la pena buscar un compresor general sin pérdidas tipo zip o 7z y aplicarlo a la globalidad del archivo comprimido ... Quizás para la próxima.

En la última versión de la entrega se incluye una aplicación de interfaz de comandos, que traduce un archivo creado con versiones del codificador menos optimizadas, a la última versión del codificador, que presumiblemente ocupa menos.

Usando esa pequeña nueva aplicación sobre un par de archivos con la codificación original (uno de 143x143 y otro de 4000x3000), se ve que el tamaño del archivo comprimido se reduce alrededor de un 4% en ellos.