bmp格式版本很多，https://en.wikipedia.org/wiki/BMP_file_format有说明Alpha有BITMAPV4HEADER或BITMAPV5 ...
xnview和xnconvert无疑是会将32bit PNG (RGBA各8bit)转换为32位BMP
数据容量一样至少图像是无损转换，metadata会不会变动...无法保证
至少我用python的pil生成的带alpha的png经过xnview转为bmp再转回png会得到hash值不一致，不过读取两个png中的图像数据是完全一致的
xnview转出的带alpha的png再转为bmp再转png的hash是一致的
jojo测试图:https://i.loli.net/2018/02/07/5a7b0b2e39df8.png
另外关于压成视频的说法，我在前面的贴里已经做过ffmpeg无损vp9("-lossless 1 -quality best")编码的测试，比不过lmza2极限的7z而且耗时多得多，另外压成视频还会遇到图片分辨率不一致和alpha，还有没法保存文件名的问题，麻烦多了 lwa190212 发表于 2018-2-7 22:41
xnview和xnconvert无疑是会将32bit PNG (RGBA各8bit)转换为32位BMP
数据容量一样至少图像是无损转换，met ...
hash值不同只是因为 header 部分不一样……举个例子，假设文件头部分原本包含作者姓名，你用的库生成的文件作者姓名为空，hash值就不同了。
关键帧处理的方案，压两张图看不出效果，几十张图以后效果显著。
归根结底，压缩算法的本质是寻找数据的规律。 本帖最后由 lwa190212 于 2018-2-8 00:03 编辑
余生皆假期 发表于 2018-2-7 23:37
hash值不同只是因为 header 部分不一样……举个例子，假设文件头部分原本包含作者姓名，你用的库生成的文 ...
找到原因，我用pillow生成的png没有dpi属性，xnview转换到bmp时会把dpi默认设为72
转为视频的测试我用了78张图，不是2张
至少我觉得h264，vp9之类的动作预测，并不能很好地处理立绘和cg这些接近闪现的效果
另外x264只支持yuv/y4m输入，如果源文件是rgb那转过去必然有损，这里只谈无损就不测试h264了
mozilla 发表于 2018-2-7 21:19
bmp格式版本很多，https://en.wikipedia.org/wiki/BMP_file_format有说明Alpha有BITMAPV4HEADER或BITMAPV5 ...
以前写过一个 bmp 格式转换器，转换都是无损的。 lwa190212 发表于 2018-2-8 00:01
找到原因，我用pillow生成的png没有dpi属性，xnview转换到bmp时会把dpi默认设为72
转为视频的测试我用了7 ...
264/265用ycocg就能无损了
像8楼那类立绘为样本，作为动画用flif进行压缩都能超过lzma2的
如果是归档，体验上估计没什么能跟固实比了 kvll32 发表于 2018-2-8 15:32
将所有png拼成一个大文件
不是做成一张PNGsprite图哦，是十六进制意义上的拼接
例如:
这跟固实是一样的 本帖最后由 w酱 于 2018-2-8 17:04 编辑
我们之前做了一个项目，立绘图是把png解压出RGBA32，完全透明的像素用(0,0,0,0)清理掉，然后做一遍LZ4 HC，压缩率大概比BMP压zip要强，主要是解压十分快，虽然这么搞非常吃内存。
然后在工程里对图片分类，颜色少不重要的图片跑一边dxt5，重要的图片走无损压缩的RGBA。
解压速度的话，eroge的立绘图大概是10-20ms一张
这楼里面有几个是真做对象存储的么？
有没有群一起加一下？
-- 来自 有消息提醒的 Stage1官方 iOS客户端 https://tieba.baidu.com/p/5153765630
大量相似图片的话,有人开发了这个,lz可以试试 嘿不知道有没有人试过r*nchonyi当年用来压缩游戏硬盘版的jpgcomp——顾名思义，本来是用来疯狂压缩jpg图片的工具。
没亲自用过，求证？ 关注一下
-- 来自 有消息提醒的 Stage1官方 Android客户端 7z+bmp 爬了半天楼终于有人提了。不过，看LZ的意思是保存，而不是用来传播，有损压缩就不好了，另外上网的话，WEBp毕竟狗弄得就是为了对抗专利的，所以用的没有限制的VP8，更好的压缩算法都是受专利权限制，非商业用没啥问题，大规模商用就不太好了。
----发送自 Sony G8441,Android 8.0.0
页:
1
[2]