我用的xnview,它可以直接保存wdp
我用它对比的

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

我用cl版编码也是不能直接输入8bit的bmp
我知道比较差别大的原因了：
用xnview另存为wdp后，虽然当前显示的图片文件名是wdp的，其实它的画面仍然是原文件。

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

c 2我测试过，仍然不行啊

0.bmp : Success
    Format               : Windows Bitmap
    Name                 : bmp
    Compression          : Rle
    Width                : 3811
    Height               : 2800
    Components per pixel : 1
    Bits per component   : 8
    Depth                : 8
    # colors             : 256
    Color model          : RGB
    Bytes Per Plane      : 3812
    Orientation          : Bottom Left
    Xdpi                 : 72
    Ydpi                 : 72
    Page(s)              : 1
这样的不行

xnview自带的hd photo解码插件效率太低了
就算它的压缩率高（实际上根本不是），也忍受不了它的解码速度
就我实际使用效果来看，uci和jpg的解码速度相差很少。
btw，就目前而言，处理灰度图的最佳格式应该是什么？

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

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

我之前说过了，灰度图转成RGB再转YUV会有误差，UV平面并不完全是单色

这是目前所用的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;

那你怎么保证Y800转RGB时是RGB都相等呢？
而且这个转换是白做掉的，直接压B通道不是更好吗
0~255 -> 16~235显然不是一一映射，再转回来时必然有损失

to 70l
你是怎么判断它是彩色的呢？

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的公式,只是权衡考虑最终没有选择.