版本 v1.1 中的新特征是在应用程序中添加一个与图像IO 兼容的折形压缩图像阅读器。

因此,您可以用以下应用程序阅读压缩图像(.dfc):

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

用.jpg 格式和应用程序的.dfc 格式比较图像时,可以看到质量比.jpg 的要差一些,而且它需要略大一点的文件(如预期的那样)。

但结果并不坏

然而,鉴于压缩需要较长的处理时间,这种压缩及其在申请中的实施只涉及学术利益。

04/05/2026 - 04/12/2026 。在恢复了该应用程序的进化后,我提议用真实图像进行测试,然后用“4,000 x 3000”像素之一进行测试。

我遇到很多问题:

• 这个过程在分裂迭代中需要永远的时间(由于三角形的广度高达400,000个三角形,而且每个迭代中的所有三角形都重复了分割状况检查) 。
• 记忆在达到我的系统23GB的极限后就耗尽了。因为:
  • 拆分和合并迭代的结果存储在布林列表中( 大约 16 个迭代 x 2 种三角对调 x 3 个通道 x 3 个通道 x 400 000 元件!!!!!! ) 。 这使得总共 约 4 000 000 000 元元素, 仍然可以接受 ) 。
  • 此外,选择最有代表性的三角形(设为256个)的书时使用了K型类动物(超过400,000个元素)(我认为该算法使用的内存是O(n)2),现在它失控了...)
  • 而对于更多的INRI来说,这些计算是同时为三个频道(rgb)进行的!
• 一旦这些问题得到解决,我设法压缩图像(400x3000),但我看到完成这项工作需要6至8小时。

我提议解决他们:

• 分裂的永久化 解决方案:
  • 我将三角形的最小大小增加为分裂, 与图像中的像素数量成正比。 导致三角形数量减少。 在用图( 4000 x 3000) 中, 三角形数量除以 4 (我们从大约 400 000 三角形到 大约 100 000 三角形) 。
  • 此外,我还创建了一个三角形的Set, 其三角形不符合分裂标准( 与其像素值的差异相对), 以免在每次迭代中重复这些三角形。 现在飞!!
• 系统正在耗尽内存。 解决方案 :
  • 在布林列表中保存的拆分和合并结果。 解决方案 :
    • 随着分裂迭代的进展,分裂的三角形数量大大小得多,使用的内存通过存储在 Set 中分割的三角形的索引而保存。
  • K- medoids 的内存( 假定为 O( n% 2) ) 。 解析 :
    • 由于我们把三角形数除以 4, 这个算法所需的内存, 三角形的减缩 意味着用大约 16 系数来分隔内存 。
    • 3个K-米多型平行(每个频道1个) 。 解决方案 :
      • 我们测算三角坐标和选择代码簿中最具代表性的三角形(与K-Medoids)的计算顺序。
    • 我们把48岁K型血型所需的记忆力 分开了!
• 使用“ 真实” 图像的处理时间需要永远的时间( 示例图像压缩需要6至8小时), 3 条线, 每个频道各一条线 。 解答 :
  • 使线条数可以配置 。 (通过将线条配置为 23 条线( 我的系统有 24 个核心), 处理时间将缩短为 3 个半小时 ) 。
• 解决办法的效果:
  • 三角形数除以 4 的效果显然导致压缩图像质量的明显下降。 但以如此强烈的分辨率, 这并不重要 。
  • 当三角形数除以 4 时,它也会导致压缩文件的大小被分割,据推测也是按4的顺序划分。

我还力求尽量缩小压缩文件的大小,重新编排要储存的信息。

想法是首先在每个迭代中分裂的三角形的索引列表的编码中显示,这些三角形的原始小编码是每个三角形使用一位数,表明它是否分裂。

我设计了一种算法 尽量缩小存储每一套索引 所需的尺寸

我想它不是浪费 如果你好奇的话 在这个网站上,我告诉各位我所依赖的要点。

虽然也许更值得寻找一个普通的无损压缩机, 比如拉链或7z, 并将其应用到压缩文件的全球性... 也许下一次。

在发送的最后一个版本中,包含一个命令界面应用程序,该应用程序将使用较不优化版本的编码器创建的档案翻译为最新版本的编码器,该版本可能占用的空间较少。

在一对带有原始编码的文件(一个是143x143,另一个是4000x3000)上使用这个小的新应用程序,就是压缩文件的大小减少了约4%。