Board logo

標題: [心得] 看来pna蒙版还是有用的…… [打印本頁]

作者: 林卯    時間: 2009-3-29 16:34     標題: 看来pna蒙版还是有用的……

因为新版的ssp支援32位的png图片,于是打算做个无pna蒙版的橘花。
可是:
surface0100.png——大小: 39756 字节,24位彩色;
surface0100.pna——大小: 9274 字节,8位灰度;
surface0100.png——大小: 50950 字节,32位彩色带alpha透明通道~
所以,24位+8位<32位……

立刻将这个工程终止了。实在不划算。
作者: reiv    時間: 2009-3-29 22:27

本质上surface0100.png(24bit)+surface0100.pna(8bit)和surface0100.png(32bit)的信息量是一样的,
24bit+8bit < 32bit无非是png压缩的原因。

根据上面的数据,32bit也不过大了3.8%而已。
文件占用的空间一般是某个数值的整数倍(例如4KB),
因此分两个文件来存储可能浪费的更多。
作者: 林卯    時間: 2009-3-30 19:20

引用:
原帖由 reiv 於 2009-3-29 22:27 發表
本质上surface0100.png(24bit)+surface0100.pna(8bit)和surface0100.png(32bit)的信息量是一样的,
24bit+8bit < 32bit无非是png压缩的原因。

根据上面的数据,32bit也不过大了3.8%而已。
文件占用的空间一般是某个数值 ...
这个与文件系统格式有关。我记忆中,新的文件系统应该没有这种限制。
而且事实上的体积增大不利于网络传播。
话说要是能做试验验证就好了。
作者: reiv    時間: 2009-3-30 22:49

win32上的fs无非是fat32或ntfs,fat32肯定是有最小文件的说法的。
ntfs我不太清楚,参考http://en.wikipedia.org/wiki/NTFS后感觉文件大小必须大于一个簇(cluster,默认是4KiB)。对于我现在用的ext3,显然也有这个限制,印象中只有reiserfs有专门对小文件处理。

关于网络传输,可以先压缩再传输。由于两者的信息量相等,所以理论上可以压缩到同样大小。
作者: 林卯    時間: 2009-3-30 23:40

引用:
原帖由 reiv 於 2009-3-30 22:49 發表
win32上的fs无非是fat32或ntfs,fat32肯定是有最小文件的说法的。
ntfs我不太清楚,参考http://en.wikipedia.org/wiki/NTFS后感觉文件大小必须大于一个簇(cluster,默认是4KiB)。对于我现在用的ext3,显然也有这个限制,印象中 ...
要是有个人出头试验一下就好了。
作者: Pygmalion    時間: 2009-3-31 21:44

引用:
要是有个人出头试验一下就好了。
从理夢作者的官网 http://khmix.sakura.ne.jp/download.shtml 上下载伺か用PNG変換機
打开pnacon.exe,选第二项PNG和PNA转32bitPNG。
将PNG和PNA拖入(可批量转),点右下的按钮。32bitPNG生成。

结果自己试吧。。。




歡迎光臨 中文偽春菜後援會論壇 (http://cuc.moe.hm/) Powered by Discuz! 6.1.0