sfsuvival

这是ziya186发现的问题
https://www.yukict.com/bbs/viewt ... ;extra=&page=15

用crass提取天神乱漫的立绘有色差问题，不能用来合成
但如果是提取原始文件(即解密后的tlg)再交给ExtractData转换，立绘并没有问题，可用来合成

我做了一些试验
我现在有五个版本的crass
crass-0.4.10.0 (kirikiri2插件版本1.3.7)
crass-0.4.10.8 (kirikiri2插件版本1.4.5)
crass-0.4.13.6 (kirikiri2插件版本1.4.9)
crass-0.4.13.13 (kirikiri2插件版本1.5.3)
crass-0.4.14.0 (kirikiri2插件版本1.5.4)
将解密后的tlg用ExtractData和这五个版本的crass转换至32位bmp
发现ExtractData，kirikiri2插件1.3.7和1.4.5转换出来的立绘相同，均没有问题，可用来合成
kirikiri2插件1.4.9，1.5.3和1.5.4转换出来的立绘相同，都是有色差问题的


比较

引用:

kirikiri2插件1.4.5解出来之后合成的
http://i609.photobucket.com/albums/tt172/sfsuvival/01_kiri145.png
kirikiri2插件1.5.4解出来之后合成的
http://i609.photobucket.com/albums/tt172/sfsuvival/01_kiri154.png

引用:

kirikiri2插件1.4.5解出来之后合成的
http://i609.photobucket.com/albums/tt172/sfsuvival/02_kiri145.png

kirikiri2插件1.5.4解出来之后合成的
http://i609.photobucket.com/albums/tt172/sfsuvival/02_kiri154.png

游戏截图
http://i609.photobucket.com/albums/tt172/sfsuvival/02_capture.png
1.4.5解出来的立绘和游戏显示的相似
1.5.4解出来的立绘线条和游戏显示有偏差

引用:

2009-02-17 20:00 ver 1.4.9 修正了对game=love类型进行二次解密的错误；对32位bmp进行alpha blending
2009-01-31 19:55 ver 1.4.8 加入game=chower2解密参数
2009-01-29 17:28 ver 1.4.7 加入game=lovelaby解密参数
2008-12-24 20:29 ver 1.4.6 加入game=c_emp解密参数
2008-12-12 20:25 ver 1.4.5 修正了seek64错误计算参数的问题

由1.4.6至1.4.9，只有1.4.9有修改32位bmp，其余只是增加解密参数
所以我推断是kirikiri2插件1.4.9开始，crass将tlg转换至32位bmp有色差问题
不过我没有kirikiri2插件1.4.8，所以不能证实...

有兴趣的可以自己试试
http://d.namipan.com/d/0b7904511 ... 3694d4f0d50a64b7400

[ 本帖最后由 sfsuvival 于 2009-11-02 22:51 编辑 ]

haibara

目前已知天神乱漫有问题

其他至少要合成都没问题，因为基本我都会去合成

引用:

        if (tlg5_header->colors == 4) {
                BYTE *b = out;
                DWORD pixels = tlg5_header->width * tlg5_header->height;
                for (i = 0; i < pixels; ++i) {
                        b[0] = b[0] * b[3] / 255 + (255 - b[3]);
                        b[1] = b[1] * b[3] / 255 + (255 - b[3]);
                        b[2] = b[2] * b[3] / 255 + (255 - b[3]);
                        b += 4;
                }
        }

引用:

        BYTE *b = out;
        DWORD pixels = tlg6_header->width * tlg6_header->height;
        for (i = 0; i < pixels; ++i) {
                b[0] = b[0] * b[3] / 255 + (255 - b[3]);
                b[1] = b[1] * b[3] / 255 + (255 - b[3]);
                b[2] = b[2] * b[3] / 255 + (255 - b[3]);
                b += 4;
        }

看代码好像没问题

完整的blenging应该是

                for (i = 0; i < pixels; ++i) {
                        b[0] = ( b[0] * b[3] + background * ( 255 - b[3] ) ) / 255;
                        b[1] = ( b[0] * b[3] + background * ( 255 - b[3] ) ) / 255;
                        b[2] = ( b[0] * b[3] + background * ( 255 - b[3] ) ) / 255;
                        b += 4;
                }

汉公设置blending背景色为白色，也就是说background是0xFF，即255，化简就是上面的

[ 本帖最后由 haibara 于 2009-11-03 01:23 编辑 ]

haibara

sfsuvival说的是边缘锯齿，而我说的天神乱漫是指合成上的问题

至于sfsuvival说的由于汉公只使用确定的白色，而非原图象符合平滑色，所以一定会有边缘锯齿

准确地说汉公保留了alpha，使得边缘锯齿可见，如果忽略alpha，只看白色背景的话，是无边缘锯齿的，而正常的alpha blending的结果也是不保存alpha的，比方ExtractData

目前可能有边缘锯齿的cui：
AZSystem
ExHIBIT
FVP
kirikiri2
LiosGame
NEJII
SOFTPAL ADV SYSTEM
System4

CIRCUS?
Leaf?
RioShiina?
ags?
IPAC?

[ 本帖最后由 haibara 于 2010-07-01 23:16 编辑 ]

竹宮綰軒

嘛...LZ好强...
放弃Crass吧,还是咱ws好使

sfsuvival

引用:

原帖由 haibara 于 2009-11-05 23:10 发表
sfsuvival说的是边缘锯齿，而我说的天神乱漫是指合成上的问题

至于sfsuvival说的由于汉公只使用确定的白色，而非原图象符合平滑色，所以一定会有边缘锯齿

准确地说汉公保留了alpha，使得边缘锯齿可见，如果忽略 ...

看了你的说明我更加不明白汉公为什么要为带alpha的图做alpha blending
alpha blending是为了输出移除了alpha的图而做的处理
既然保留alpha，为什么要做alpha blending?
这会破坏原图...
这样做是否有其它目的?

[ 本帖最后由 sfsuvival 于 2009-11-08 03:22 编辑 ]

haibara

引用:

原帖由 sfsuvival 于 2009-11-08 03:21 发表


看了你的说明我更加不明白汉公为什么要为带alpha的图做alpha blending
alpha blending是为了输出移除了alpha的图而做的处理
既然保留alpha，为什么要做alpha blending?
这会破坏原图...
这样做是否有其它目的 ...

很简单，很多小白要求的

在windows下，32位bmp不象32位png那样是直接白色blending，是直接显示24位的内容，很难看，因为通常会搞平滑内容

finalord

ws是什么软件？

haibara

引用:

原帖由 finalord 于 2009-11-08 16:22 发表
ws是什么软件？

westside