InitFont函数的is_outline参数设为1时，有时脚本不能正常解析

lijingjie

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



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



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



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

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

milkyjing

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

补充:

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

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

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

lijingjie

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

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



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



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

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



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



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

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

milkyjing

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

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

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

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

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

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

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

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