O novo recurso na versão v1.1 é a adição de um leitor de imagem comprimido por fractal dentro do aplicativo que é compatível com ImageIO.

Portanto, você pode ler uma imagem compactada (.dfc) com o aplicativo da seguinte forma:

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

Comparando a imagem no formato.jpg e no formato.dfc do aplicativo, você pode ver que a qualidade é um pouco pior do que em.jpg e que ocupa um arquivo um pouco maior (como esperado).

Mas o resultado não é nada mau.

No entanto, dado o longo tempo de processamento necessário para a compressão, esse tipo de compressão e sua implementação na aplicação são apenas de interesse acadêmico.

04/05/2026 - 04/12/2026 . Depois de ter recuperado a evolução desta aplicação, proponho fazer testes com imagens reais, e eu tento com um dos "4000 x 3000" pixels.

Eu encontro muitos problemas:

• O processo leva para sempre nas iterações divididas (devido às extensas triangulações de até 400.000 triângulos, e que a verificação da condição dividida foi repetida para todos os triângulos em cada iteração)
• A memória acaba depois de atingir o limite de 23 GB que eu tinha no meu sistema. Porque:
  • O resultado das iterações de divisão e fusão foram armazenados em uma lista booleana (cerca de 16 iterações x 2 tipos de triangulação x 3 canais x 400.000 elementos!!!!). Isso faz um total de cerca de 40.000.000 elementos, que ainda é aceitável)
  • Além disso, a seleção do livro dos triângulos mais representativos (definido como 256) foi realizada com um K-medoides (mais de 400.000 elementos) (a memória usada por esse algoritmo é O(n2)). Agora está ficando fora de controle...)
  • E, para mais INRI, esses cálculos foram realizados em paralelo para os três canais (rgb)!!
• Uma vez que esses problemas são resolvidos, consigo comprimir a imagem (4000 x 3000), mas vejo que leva entre 6 e 8 horas para concluir o trabalho.

E proponho resolvê-los:

• Para a eternização de divisões. Solução:
  • Eu aumento o tamanho mínimo dos triângulos para dividir, de forma proporcional ao número de pixels na imagem. Resultando em uma redução no número de triângulos nas triangulações. Na imagem usada de (4000 x 3000) o número de triângulos é dividido por mais de 4 (passamos de cerca de 400.000 triângulos para cerca de 100.000 triângulos).
  • Além disso, eu crio um conjunto com os triângulos que não atendem ao critério de divisão (em relação à variância dos valores de seus pixels), para não repeti-los em cada iteração. Agora voe!!
• O sistema está ficando sem memória. Solução:
  • Resultado de divisões e fusões salvas em listas booleanas. Solução:
    • medida que as iterações de divisão progridem, o número de triângulos que se dividem é radicalmente menor, a memória usada é salva armazenando os índices dos triângulos que se dividem em um conjunto.
  • Memória de K-medoides (presumivelmente O(n2)). Solução:
    • Como dividimos o número de triângulos por 4..., a memória necessária para esse algoritmo, essa redução de triângulos envolve dividir a memória usada por um fator de cerca de 16.
    • Três K-medoides em paralelo (um para cada canal). Solução:
      • Sequenciamos os cálculos das triangulações e a seleção dos triângulos mais representativos para o livro de códigos (com K-medóides).
    • Dividimos a memória necessária para os K-medóides de 48!!
• O tempo de processamento com imagens "reais" leva para sempre (a compressão da imagem de exemplo leva entre 6 e 8 horas) com 3 threads, um para cada canal.
  • (Ao configurá-lo para 23 threads (meu sistema tem 24 núcleos), o tempo de processamento é reduzido para três horas e meia).
• Efeitos da solução:
  • O efeito de dividir o número de triângulos por 4 obviamente resulta em uma perda notável da qualidade da imagem compactada. Mas com tanta resolução, não é tão importante.
  • Ao dividir o número de triângulos por 4, também faz com que o tamanho do arquivo comprimido seja dividido, supostamente também da ordem de 4.

Também pretendo tentar minimizar o tamanho do arquivo compactado, reorganizando as informações a serem armazenadas.

A ideia é indicar acima de tudo na codificação das listas de índices dos triângulos que se dividem em cada uma das iterações, cuja codificação trivial original era usar um bit por triângulo, indicando se se dividia ou não.

Eu desenvolvo um algoritmo para tentar minimizar o tamanho necessário para armazenar cada um desses conjuntos de índices.

Eu acho que não é desperdiçado... se você está curioso neste site eu digo os pontos-chave em que eu confiei.

Embora talvez valesse mais a pena procurar um compressor geral sem perdas como zip ou 7z e aplicá-lo à globalidade do arquivo compactado... Talvez pela próxima vez.

Na última versão da entrega, um aplicativo de interface de comando está incluído, o que traduz um arquivo criado com versões menos otimizadas do codificador, para a versão mais recente do codificador, que presumivelmente ocupa menos espaço.

Usando esta pequena nova aplicação em um par de arquivos com a codificação original (um de 143x143 e outro de 4000x3000), é que o tamanho do arquivo compactado é reduzido em cerca de 4% neles.