现在对XnView的支持是最好的,兼容性和效率都比susie高.

UCI 0.5 TODO:
add some MMX-optimized code in H.264 decoding functions such as IDCT.

变成24bit不用担心,其实UV通道会被压得很小,对体积的影响可以忽略.
变暗的问题我会找时间测试一下,"+1 fix"就是之前发现解码后略微变暗而做的调整.

色彩空间转换的问题也会找时间检查一下,我想主要是Y通道scale导致的.

没有+1fix的测试:
BMP -> UCI -> BMP
00　　 ->　　 00
80　　 ->　　 7F
FF　　 ->　　 FD

上面的测试直接用YUV作中转也是一样,说明是色彩空间转换带来的误差.毕竟有0-255到16-223的缩放映射,再加上运算结果的截断,肯定会有微小的误差.

更换11个IDCT等函数为MMX版之后测试发现解码速度提示非常有限,估计不到10%.
而FFmpeg里很少有仅MMX的优化,而对MMX2优化的要多很多.
谁清楚支持MMX2的最低CPU类型(Intel&AMD)?

UCI其实和JPG格式的适用范围是一样的.
JPG也不适合颜色数比较少且分明的图.
它们都对图像做某种相似变换再去压缩的,对颜色自然的图像来说很有效,但和普通的数据压缩算法差别很大,对于颜色分明的图来说更适合用常规的压缩算法.

楼上请给出测试结果,或者测试原图.

56楼被系统HX了,请换个方式发帖.

找不到网页 
您要查看的网页可能已被删除、名称已被更改，或者暂时不可用。

uci默认参数压缩(24bit): 186KB
wdp使用-q 60压缩(8bit): 197KB
观察发现wdp从噪点控制和与原图还原度上远不及uci.

用XnView转换只能设置画质参数,这个与-q不一样,我设置成76转换的结果和刚才测试的大小差不多,画质也差不多.而且奇怪的是转换8位灰度色时仍然提示要先转成真彩色再做转换.

嗯,命令行版确实是根据默认使用的24bit去压的,如果指定-c 2参数就可以真正以8bit压缩,此时只减少了2KB(1%)的大小,画质不变.

正常情况下,解码速度: jpg >> uci > wdp >> jp2
jpg解码速度还是快很多的.
灰度图用这几种编码都合适,因为它们都是单独处理Y通道的,即使转换成24位色去压缩,也不会增加明显的体积.