只支持4:2:0的话问题不大,但必须想办法支持alpha,不知道x264能否单独压缩灰度图.

crf+aq果然有效果了,crf和qp值等同时前者体积小了一些,图像中多了一些细节,但边缘噪点明显增多.降低crf值使文件体积与使用qp同大小时,噪点减弱了不少(但还是比使用qp稍多),总体质量感觉确实好多了.

x264好像不支持灰度，snow可以�

目前x264的1:20低画质最佳参数是这个:
crf=25:bframes=0:frameref=0:deblock=0,-4:subq=6:trellis=2:8x8dct:psy-rd=0.0,0.0
其中deblock的beta值不能再高了,否则一些地方会出现明显杂色.
回过头来再看snow,画质要差了不少,我不知道是否能调节什么参数能提升细节.

我准备自己写一个常用图片格式与y4m格式转换的工具,这样就不必再用mencoder去压x264了.

就目前看，x264也好，snow也好，它们的发展都是基于视频的，而hd-photo是基于图片的。那么将来对于它的应用将大行其道，为什么不针对hd photo多加优化？


还是期待dwing优化的hd photo编码工具

hd-photo的技术发展估计比较困难,毕竟只有微软开发.
而x264和snow有众多的社区人员开发,近几年有了可观的改进,尤其是x264,已经把DCT类编码发挥到极致.

以下参数可能对snow的编码有影响
vme=8
mbd=1/2
v4mv
obmc
lumi_mask
dark_mask
scplx_mask
naq
dia
trell
qns

这些参数对snow的影响都不大,snow和jpeg2000一样,对平滑过渡的图像的还原效果非常好,对高频细节丢失很严重.这是小波编码的通病,而DCT却恰恰相反,过渡色和边缘噪声是弱点,但通过loop filter已经很好地弥补了.

scplx_mask应该能起到deblock的作用�

小波编码天生就能deblock吧.我记得是可以不分块编码的.就因为如此,才适合压缩平滑过渡的图像.
x264不支持奇数宽高也比较麻烦,看来要自己处理一下了.

dwing，如果要使用H264解码怎么弄？用ffmpeg动态库�

使用ffmpeg动态库或者自己提取其中的H.264解码部分都可以,我都测试过了,后者体积会小得多.

那yuv->rgb怎么弄？还需要swscale吧�

Unix程序都喜欢和stdio打交道，数据在进程间传来传去…�