规格说明

你好,我认为这是一个相当不错的图像格式,我已经在开发 Swift 实现。我有几个关于边缘情况的问题: **截断数据** 在参考解码器中,如果没有足够的数据来覆盖所有像素,它将继续用当前像素填充图像的剩余部分。因此,没有像素数据的文件,仅包含头部和填充数据,将完全为黑色。规范中并没有对此进行讨论,因此我的问题是: 1. 我是否应该在此处与参考解码器的行为保持一致? 2. 如果图像的剩余部分与当前像素相同,编码器故意提前结束是否安全? 我之所以提出这个问题,是因为该格式对于长时间运行来说相对较差,我只需提前结束就可以在我的使用案例中节省大量资源。(理想情况下,我会用扩展的 14 位运行代替 DIFF 操作码) **初始颜色和索引** 参考解码器将所有操作码的像素结果存储在索引中,但编码器不会将像素存储到索引中,也不会将像素存储到索引中。对于索引操作码,这无关紧要,但对于运行有个小的边缘情况: 如果图像以黑色开始,则它将编码一个运行,因为初始 `prev` 像素是黑色。如果下一个像素完全不同,则可能会执行 RGB/RGBA。如果我们再有更多的黑色,我们发现初始黑色从未被放入索引中,因此我们必须再次执行 RGB/RGBA。规范中并没有明确涵盖此内容,但我可以看到在代码中可以做出一些可能的改进,具体取决于什么被视为有效: 1. 编码器可以将运行存储到索引中(或者仅存储初始黑色),以此为微小的大小优化此边缘情况。当前的解码器将正确处理此情况。 2. 或者,解码器可以假设初始黑色从未被放入索引中,因此可以安全地忽略在索引中存储索引和运行操作码,以提高性能。 3. 上述两点,其中解码器首先将初始黑色存储到索引中,以覆盖此边缘情况。无论如何,在规范中对此进行一些说明都会有所帮助。