67楼的图可能是256彩色,不是灰度,所以不能以c2(灰度)去压缩.

这是目前所用的RGB到YUV的转换公式,很明显灰度图(RGB相同)的时候,UV是单色(128).误差可以控制到1以内.
Y = (B * 98 + G * 504 + R * 257) / 1000 + 16;
U = (B * 439 + G * -291 + R * -148) / 1000 + 128;
V = (B * -71 + G * -368 + R * 439) / 1000 + 128;

to 73L:
这是UCI所用的YUV->RGB公式,只要保证UV都是128,那么就可以保证RGB等值.
B = FIX(((Y - 16) * 1164 + (U - 128) * 2017) / 1000);
G = FIX(((Y - 16) * 1164 - (U - 128) * 392 - (V - 128) * 813) / 1000);
R = FIX(((Y - 16) * 1164 + (V - 128) * 1596) / 1000);
从直观和测试来看,X264编码纯色通道几乎是无损的,也没有理由加入瑕疵.
-----------------------------------------------
to 74L:
因为看到此处:
Color model : RGB
如果是灰度图,应该写gray而不是RGB.

虽然不是一一映射,但误差只要不大就不会感觉出异样.
UCI本可以选择全范围映射YUV的公式,只是权衡考虑最终没有选择.

YUV色彩空间转换其实是很有必要的,转换之后对自然图像的压缩率会明显提升,至少比分别用RGB通道去压缩大部分是灰色的图要有效得多.

另外,YUV420对于大部分自然图像的质量也是足够好的.

to 80L:
1)JPG的YUV没有经过放缩,不能直接用.
色彩在总体上有点差异对主观感觉的影响非常小,主观感觉对图像的颜色变化更为敏感,这就是为什么PSNR和主观不相符的原因,而且事实上视频用的编码器都更注重主观感觉,而wdp和jp2却相反.
2)75L和上面已经解释了,不想只为了灰度图再定义一种没意义的格式.
3)YUV一般都会比RGB更好压缩,当然这个比以上2点更有意义,以后考虑支持这种高画质压缩.

to 82L:
请上传此图像.

to 85L:
YUV->RGB->YUV的转换不是为了提高主观感觉,我也从未说过RGB->YUV的过程能"提高",其实我是说在尽量保证一定的主观画质下,缩减YUV的幅度可以提高压缩能力,所以说从客观上画质肯定有所下降,只是对于更好地压缩来说是值得的.
一般的软件都没办法避免YUV->RGB->YUV的过程,绝大部分图像格式转换软件重新压缩JPG的过程都有这种转换,但几乎没人抱怨过色彩空间转换这个过程的损失.

to 86L:
那个图其实是24位色图,只是使用了256色的调色板,是否使用RLE压缩还未判断.
ucienc不支持输入有调色板或者使用RLE压缩的BMP.不过可以使用imgdec做转换,方法如下,已测试通过:
imgdec 0.bmp - | ucienc - -o 1.uci

JPEG和UCI所用的变换矩阵差别不小,不比两次变换的误差小多少.
真正影响主观画质的是与原图色差是否均衡,而总体略微色偏是不重要的.当然关于色差转换矩阵我会再微调一下,不过不会考虑专门为JPG而专门处理.想直接用YUV的可以自己写imgdec这种工具,ucienc支持输入YUV.

to 86L:
wmpenc也不支持某些格式的BMP,需要先自行转换,它的帮助信息里有支持的格式:
bmp: <=8bpc, BGR
tif: >=8bpc, RGB
hdr: 24bppRGBE only

画面偏暗是以前发现的问题,估计是转换时整数舍入导致,后来加入Y通道+1修正基本解决,UV通道也有此问题,不过影响较小,只有多次反复转换才能察觉.
x264和ffmpeg支持所有偶数宽高,没有mod16的问题.UCI对奇数宽高扩展1像素成偶数宽高再编码,解码时忽略多出来的1像素宽高.
RGB与YUV420的相互转换使用XVID里以下几个函数:
yv12_to_PCbgr_mmx_asm 
yv12_to_PCbgra_mmx_asm
bgr_to_yv12_mmx_asm   
bgra_to_yv12_mmx_asm  
与YUV444的转换使用自己写的程序,公式前面列出过.

是的

压缩比是可以调节的, 可以根据自己的画质要求来选择最佳的平衡点, 默认的参数可以满足多数情况.
DLL体积可以选择0.493版的, 只有几百KB, 但0.5版的UCI有很大改进, 除非有特殊情况, 还是不要在意不到2M的DLL体积了.