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

 找回密码
 加入社区
查看: 2498|回复: 4

[已解决] InitFont函数的is_outline参数设为1时,有时脚本不能正常解析 [复制链接]

Rank: 5Rank: 5

发表于 2011-11-22 13:30:31 |显示全部楼层
帖子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?

Administrator

TCAX Dev.

Rank: 7Rank: 7Rank: 7

发表于 2011-11-22 13:47:07 |显示全部楼层
推断为Bug, 已移动至Bug汇报区. 待下一版本处理. 感谢汇报.

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

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

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

Rank: 5Rank: 5

发表于 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的效果。不知道我的测试准不准,还请牛奶大指正。

Administrator

TCAX Dev.

Rank: 7Rank: 7Rank: 7

发表于 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级灰度图. 另外, 也不存在放大缩小这个过程. 所以两者渲染结果存在细微偏差是难免的...


Administrator

TCAX Dev.

Rank: 7Rank: 7Rank: 7

发表于 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


您需要登录后才可以回帖 登录 | 加入社区

GitHub|TCAX 主页

GMT+8, 2018-12-17 07:21

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部
RealH