La novetat de la versió v1.1 és que afegeix un reader d'imatges comprimides fractalment amb la aplicació que és compatible amb ImageIO.

Així doncs es pot llegir una imatge comprimida amb l'aplicació (.dfc) d'aquesta manera:

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

A la comparativa de la imatge en .jpg i al format de l'aplicació .dfc, es pot observar que la qualitat és pitjor que la de .jpg y que ocupa una mica més (com era d'esperar).

Però el resultat no està malament del tot.

Encara que donat l'alt temps de procesament que es pren per a comprimir, aquest tipus de compressió i la seva implementació a l'aplicació solo només tenen cert interés acadèmic.

05/04/2026 - 12/04/2026. Després d'haver recuperat l'evolució d'aquesta aplicació, em proposo fer proves amb imatges de veritat, i la provo amb una de "4000 x 3000" pixels.

Em trobo amb molts problemes:

• El procés s'eternitza a les iteracoins de split (degut a les extenses triangulacions de fins al voltant de 400.000 triangles, i que es repetia la comprobació de la condició de split per a tots el triangles a cada iteració)
• La memòria s'exhaureix desprès d'arribar al límit de 23 GB que tenia al meu sistema. Degut a que:
  • El resultat de les iteracions de split i merge es guardaven a una llista de boolean (al voltant de 16 iteracions x 2 tipus de triangulacions x 3 canals x 400.000 elements !!!!). Aixó fa un total de al voltant de 40.000.000 d'elements, cosa encara assumible)
  • A més, l'elecció del book de triangles més representatius (configurat a fog a 256), es feia amb un K-medoids (sobre 400.000 elements) (crec que la memòria necessària per aquest algorisme es O(n^2). Ara si que ja sens va de les mans ...)
  • I, per a més INRI, es feien aquest càlculs en paral.lel per als tres canals (rgb) !!
• Un cop solucionats aquest problemes, aconsegueixo que es comprimeixi la imatge de (4000 x 3000), però veig que tarde entre 6 y 8 hores a fer el treball.

I em proposo solucionar-los:

• Per a l'eternització dels split. Solució:
  • Augment de la mida mínima dels triangles per a fer split, de manera esglaonadamente proporcional al número de píxels de la imatge. Que resulta en una rebaixa del número de triangles de les triangulacions. A la imatge d'exemmple (4000 x 3000) es divideix el número de triangles per més de 4 (passem d'uns 400.000 triangles a uns 100.000 triangles).
  • A més, creo un Set amb els triangles que no compleixin amb el criteri de split (relatius a la variància dels valors dels seus píxels), per a no repetir-los a cada iteració. Ara vola !!
• S'exhaureix la memòria del sistema. Solució:
  • Resultat de splits i merges guardats a llistes de booleans. Solució:
    • Com a mida que avancen les iteracions ds split, el número de triangles que fan split es radicalment més petit, s'estalvia memòria guardant els índex dels triangles que fan split en un Set.
  • Memòria de K-medoids (presumiblemente O(n^2)). Solució:
    • Com hem dividir el número de triangles 4 ..., la memória necessària per a aquest algorisme, aquesta reducció de triangles implica dividir la memòria ocupada per un factor de al voltant de 16.
  • Tres K-medoids en paral.lel (un per a cada canal). Solució:
    • Seqüenciarem els cálculs de les triangulacions i de l'elecció dels triangles més representatius per al code-book (amb K-medoids).
  • Hem dividit la memòria necessparia per al K-medoids per 48!!
• El temps de processament amb imatges "de veritat", s'eternitza (la compressió de la imatge d'exemple tarda entre 6 y 8 hores) amb 3 fils, un per a cada canal. Solució:
  • Fer configurable el número de fils. (Configurant-lo a 23 fils (el meu sistema té 24 cores), el temps de processament es redueix a tres hores i mitja).
• Efectes de la solució:
  • L'efecte de dividir el número de triangles per 4 es tradueix, evidentement, en una pèrdua notable de la qualitat de la imatge comprimida. Però en tenir tanta resolució, doncs no és tan important.
  • En dividir el número de triangles per 4, també es produeix que es divideixi la mida de l'arxiu comprimit, suposadament de l'ordre de per 4.

També em poso com a objetiu intentar minimizar la mida de l'arxiu comprimit, reorganitzant la informació a guardar.

La idea és indicir sobre tot a la codificació de les llistes d'index dels triangles que fan split a cadascuna de les iteracions, que la codificació original trivial era guardar un bit per triangle, indicant si feia split o no.

Penso un algorisme per a tractar de minimitzar el número de bits necesari per a guardar cadascun d'aquests índex.

Crec que no té desperdici ... si tens curiositat a aquest lloc web parlo dels punts clau en els que m'he basat.

Encara que potser hagés valgut més la pena buscar un compressor general sense pèrdues tipus zip o 7z i aplicar-lo a la globalitat de l'arxiu comprimit ... Potser per a la propera.

A l'última versió de l'entrega s'inclou una aplicació d'interfície de comandes, que tradueix un arxiu creat amb versions del codificador menys optimitzades, a l'última versión del codificador, que presumiblement ocupa menys.

En la última versión de la aplicación 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.

Provant aquest petita nova aplicació sobre un parell d'arxius amb la codificació original (un de 143x143 i un altre de 4000x3000), es veu que la mida de l'arxiu comprimit es redueix al voltant d'un 4% en ells.