TCAX 字幕特效制作工具官方论坛 | ASS | TCAS | Python | Aegisub | Lua

标题: InitFont函数的is_outline参数设为1时，有时脚本不能正常解析 [打印本页]

作者: lijingjie 时间: 2011-11-22 13:30:31 标题: InitFont函数的is_outline参数设为1时，有时脚本不能正常解析

帖子ASS对白时间轴文件转TCAS (附完整工程)中第11行代码InitFont函数的最后两个参数是1和0，也就是边框厚度为1，包含字体主体结构。这样最后生成的文字效果是由前后两个文字组合而出的，文字主体部分叠加。于是我试着将第11行代码InitFont函数的最后两个参数改为1和1，也就是只含1个像素厚度的边框，不包含字体主体。这样组合以后，主体部分不会叠加，文字显示的效果能与ASS显示的文字效果相同。可是问题出现了，当修改以后解析文件时出现如下图的错误。

原始.jpg

于是我又更改了一些参数，将TCC文件中的字体改为隶书时，同样会出现错误，但是可以处理到5.15%，如下图。

隶书.jpg

如果将TCC文件中的字体改为黑体，则可以成功解析，如下图。

黑体.jpg

如果使用原来的字体，将InitFont函数边框的参数改成3或更大的值，也可以正常解析，不会出现错误。

所以我想问InitFont函数最后一个参数is_outline设为1时，参数bord有什么限制吗？还是程序有Bug？

图片附件: 隶书.jpg (2011-11-22 13:17:52, 38.75 KB) / 下载次数 6461
http://www.tcax.org/forum.php?mod=attachment&aid=MTE2fGVlNTU2YWM4fDE3NjU4MjczMjF8MHww

图片附件: 黑体.jpg (2011-11-22 13:17:47, 30.54 KB) / 下载次数 6452
http://www.tcax.org/forum.php?mod=attachment&aid=MTE1fGE4ZjRkMmYwfDE3NjU4MjczMjF8MHww

图片附件: 原始.jpg (2011-11-22 13:17:46, 38.17 KB) / 下载次数 6494
http://www.tcax.org/forum.php?mod=attachment&aid=MTE0fGYxYTViZmNkfDE3NjU4MjczMjF8MHww

作者: milkyjing 时间: 2011-11-22 13:47:07

推断为Bug, 已移动至Bug汇报区. 待下一版本处理. 感谢汇报.

补充:

这样组合以后，主体部分不会叠加，文字显示的效果能与ASS显示的文字效果相同。

实际上一开始就去掉边框的文字主体部分, 或者是之后被覆盖, 两者效果应该都是相同的. 见下图, (上面一行为ASS, 下面一行为TCAS)

唯一的区别就是生成的TCAS文件大小, 如果一开始就去掉, 则可以节省一定的文件容量. 不过通过事先的混合渲染(使用函数CombinePixs), 这个问题就不再存在了... (所谓的事先渲染, 就是在写入文件之前, 先把两个图层混合成一个图层... 节省了大量空间), 参考 http://www.tcax.org/forum.php?mod=viewthread&tid=136

作者: lijingjie 时间: 2011-11-22 15:14:13

我刚刚又重新测试了一下，有如下结果：

当is_outline为1时，文字效果如下：（上面一行为ASS, 下面一行为TCAS）

不叠加.png

当is_outline为0时，文字效果如下：（上面一行为ASS, 下面一行为TCAS）

叠加.png

使用CombinePixs函数混合渲染以后：

当is_outline为1时，文字效果如下：（上面一行为ASS, 下面一行为TCAS）

不叠加_组合.png

当is_outline为0时，文字效果如下：（上面一行为ASS, 下面一行为TCAS）

叠加_组合.png

可以看出当is_outline为1时，TCAS与ASS效果几乎一样，而当is_outline为0时，TCAS的文字比ASS文字稍微偏红。使用CombinePixs以后与不用该函数显示效果不变，但是生成的TCAS文件变小了。嘿，CombinePixs确实是个好东西。

通过以上测试感觉，当把is_outline设为1时，TCAS的效果更接近ASS的效果。也就是边框与主体叠加比带边框的主体与主体叠加更接近ASS的效果。不知道我的测试准不准，还请牛奶大指正。

图片附件: 叠加_组合.png (2011-11-22 15:00:07, 20.18 KB) / 下载次数 6466
http://www.tcax.org/forum.php?mod=attachment&aid=MTIwfGEzMzJmOTI4fDE3NjU4MjczMjF8MHww

图片附件: 叠加.png (2011-11-22 15:00:03, 20.18 KB) / 下载次数 6409
http://www.tcax.org/forum.php?mod=attachment&aid=MTE5fGZmNTYzODljfDE3NjU4MjczMjF8MHww

图片附件: 不叠加_组合.png (2011-11-22 15:00:01, 20.13 KB) / 下载次数 6425
http://www.tcax.org/forum.php?mod=attachment&aid=MTE4fDMzMDNmOWFlfDE3NjU4MjczMjF8MHww

图片附件: 不叠加.png (2011-11-22 14:59:59, 20.13 KB) / 下载次数 6462
http://www.tcax.org/forum.php?mod=attachment&aid=MTE3fGQ1MjEzN2VkfDE3NjU4MjczMjF8MHww

作者: milkyjing 时间: 2011-11-22 21:04:57

lijingjie 发表于 2011-11-22 15:14
我刚刚又重新测试了一下，有如下结果：

当is_outline为1时，文字效果如下：（上面一行为ASS, 下面一行为TC ...

你测试(观察)的很仔细. 恩, 理论上确实会存在一定偏差, 原因:

设置is_ouline为1时, 会事先把"主体"部分挖空, 采用算法 borden_alpha - original_alpha (注意: 文字的边缘部分通常不是完全不透明的), 所以叠加后, 最终的结果为如你测试的那样(不挖空的情况下, 细微地更红一些). 这是TCAS的横向比较.

对于与ASS渲染结果比较, 这个就稍微复杂一些了. 以前我看过VSFilter的一些源代码, 并与X大有过交流, VSFilter的工作原理(字体渲染部分)是, 先把画布(Canvas)拓展为8*8倍大小, 通过函数GetGlyphOutline (Win32 API), 获取文字的像素化信息, (实质上是一张65级灰度图, 灰度等级越高, 抗锯齿效果越好, GetGlyphOutline函数可以获取5级, 17级, 或者65级灰度图), 然后缩小为目标尺寸, 渲染出来.

TCAX使用的字体处理库是FreeType, (VSFilter使用的是GDI自带的), 可以直接获取257级灰度图. 另外, 也不存在放大缩小这个过程. 所以两者渲染结果存在细微偏差是难免的...

作者: milkyjing 时间: 2012-1-17 21:49:23

详细检查了下相关代码, 发现问题的起因是, 有时, 加边框后的文字, 其图片宽, 高不仅可能保持不变甚至会比原来还要小...
我设计算法的时候, 是以加粗后, 文字图片肯定是会变大, 来进行的...
虽然查明原因后, 可以用别的方法解决之, 但还真是不好理解为啥有时会更小...

-----------------------------------

比如 (在例子当中), "小" 字宽, 高加粗前后分别为 35, 34; 35, 34 (相等)
"有" 字, 35, 37; 37, 36 ... (加边框后, 高比原来还小了...)

-----------------------------------

一个合理的解释是, 通过肉眼无法准确判断细微差距, (边缘部分存在一些透明度较高的像素点), 还是应该以数据为准...
这样就有动力去修正算法了... 233

-----------------------------------

本BUG已修复: http://www.tcax.org/forum.php?mod=viewthread&tid=218

图片附件: screenshot.png (2012-1-19 13:10:51, 46.38 KB) / 下载次数 6490
http://www.tcax.org/forum.php?mod=attachment&aid=MTk2fDU2MmFhNWY4fDE3NjU4MjczMjF8MHww