FYI: ReAuthorist/Scenarist Subtitle Transparency/Contrast Tidbit

[Kedirekin]

I thought I'd share this tidbit about subtitle transparencies (AKA contrast) - probably more for people searching the forums than anything else.

The symptom I was trying to solve was that the black borders around my subtitles weren't showing up.

After a couple of hours of looking in Scenarist and at the ReAuthorist.SCP file, I came to the conclusion that the color mappings assigned to E2, E1, P and BG were correct (hint: ignore the E2, E1, P and BG 'labels'; they can be misleading. Just see what bitmap color is getting mapped to what display color. Example: red->yellow, white->black, blue->white (but transparent)).

In the process though, I noticed that the transparencies weren't importing correctly.

In ReAuthorise.SCP, I saw the following:
Color 1(E2)=100%
Color 2(E1)=86 %
Color 3(P)=0 %
Color 4(Bg)=86 %

But in Scenarist, I was seeing:
E2 - 100%
E1 - 100%
P - 0%
BG - 0%

In my case, BG was being used as the subtitle outline (white->black), and the transpancy of zero was making it invisible. Zero must be the default transparency for BG (which makes perfect sense normally, but not for this project).

[Incidentally, in this project, E1 was being used at the subtitle face, but the default 100% worked fine.]

In rolling through the transparency setting in Scenarist (version 2.6) I noticed that it doesn't go to 86% - it goes to 87%.

On a lark, a did a search and replace in ReAuthorist.SCP to replace
Color 2(E1)=86 % with Color 2(E1)=87 %
-And-
Color 4(Bg)=86 % with Color 4(Bg)=87 %

I started a new Scenarist project from the modified script and viola! - the subtitle transparencies were now 87%. The subtitle outlines showed up fine.

In conclusion, if something about your subtitles isn't working properly (face or outline not showing up, background *is* showing up), check to see if the transparency settings in scenarist match the transparencies in ReAuthorist.SCP. If they don't match, find the closest matching setting in Scenarist, and search and replace in ReAuthorist.SCP to make them match.

PS. this mismatch tidbit might only apply to Scenarist 2.6

[Eyes`Only]

That's a great tip, thanks! I wonder why Scenarist accepted 87% but not 86%?

[Chu]

Had a very similar problem with a dvd i'm working on. This does effect 2.7, and I *REALLY* wonder who decided the values should be ~mod7. Anyways, I am wondering. in the script file I see something like the following foreach subtitle.

Color=Color
{
Color 1(E2)=7
Color 2(E1)=3
Color 3(P)=8
Color 4(Bg)=12
}
Contrast=Contrast
{
Color 1(E2)=86 %
Color 2(E1)=86 %
Color 3(P)=0 %
Color 4(Bg)=86 %
}

I definatly noticed the contrast settings are directly editable in scenarist, but what exactly is the color setting corresponding to in scenarist? I don't think it is the actuial color since the RGB values for E1/E2/P/Bg are explicitly defined elsewhere. I am also curious if they must fit that crazy ~=mod7 scheme that transparency uses.

-Chu

[Chu]

Never mind . . . I guess I should go to google before I start asking questions:scared:

[Stigmata]

Thanx alot Kedirekin for your post! :D

I also had the problem with my black borders.
I needed to change BG from 46% (Scenarist putted that to 0%) to 47% (which Scenarist did recognize and putted to 47%).
It seems that Scenarist only recognizes values *0-*3-*7.

Greetingz

[Tobytl]

The reason why it only accepts certain values for contrast is quite simple. Those arent really percentages, just percieved percentages. Contrast is stored in a single nibble (half byte), ie: one hex value. Values 0-15, 0 being transparent, 15 (F) being completely visable. Scenarist just displays and stores these in a manner more readily recognizable to most people. If you dont believe me, go to a tab where you can set the contrast (either buttons or subs) go up to 100% and count the number of clicks on the down arrow it takes to get to 0%...

[Eyes`Only]

That really doesn't make any sense, as there would be 16 divisions of 100%, with 6.25 between selections. starting at 0, you'd get 43.75, and the next choice would be 50. Neither of these are 47 OR 48.

[Chu]

Here is a Ruby script file that should fix the problem. It looks at the transparcy values, and rounds them to the nearest scenarist friendly value. Run it with one argument, the name of the Scenarist script file to edit. It should be fairly easy to convert to your favorite scripting language (tm) if you don't have/like Ruby.


def roundStuff(input)

value = case input[/\d+/].to_i
when 0..3 then 0
when 4..10 then 7
when 11..16 then 13
when 17..23 then 20
when 24..30 then 27
when 31..36 then 33
when 37..43 then 40
when 44..50 then 47
when 51..56 then 53
when 57..63 then 60
when 64..70 then 67
when 71..76 then 73
when 77..83 then 80
when 84..90 then 87
when 91..96 then 93
when 97..100 then 100
end

return value.to_s + " \%"
end

## Begin Main Program
#####################

input = File.open(ARGV[0], "r+");
tmp = File.new(ARGV[0] + ".tmp", "w");

input.each_line do |line|
if (line =~ /Color \d\((E2|E1|P|Bg)\)=\d+ \%/) != nil
line[/\d+ \%/] = roundStuff(line[/\d+ \%/])
end
tmp.puts(line)
end

input.close
tmp.close

File.delete(ARGV[0]);
File.rename(ARGV[0] + ".tmp", ARGV[0]);

[Tobytl]

Originally posted by Eyes`Only
That really doesn't make any sense, as there would be 16 divisions of 100%, with 6.25 between selections. starting at 0, you'd get 43.75, and the next choice would be 50. Neither of these are 47 OR 48.

Yes, but you made an extremely simple (and incredably often duplicated) mistake. To get the difference between values on a given range you take (MaxValue-MinValue)/(TotalValues-1) or (100-0)/(16-1). If you forget to subtract the 1, which it looks like you did (and is often done, even in universities across the country), you get 17 total values { 0, 6.25, 12.5, 18.75, 25, 31.25, 37.5, 43.75, 50, 56.25, 62.5, 68.75, 75, 81.25, 87.5, 93.75, 100 } , instead of the desired 16.

100/15 = 6 2/3, which would be why the numbers when put into groups of three have diffenrences of 7,6,7. ie (0,7,13) (20,27,33). Rounded values are easier to read...

Quick table
HEX DEC Scenarist percentage
0 0 0%
1 1 7%
2 2 13%
3 3 20%
4 4 27%
5 5 33%
6 6 40%
7 7 47%
8 8 53%
9 9 60%
A 10 67%
B 11 73%
C 12 80%
D 13 87%
E 14 93%
F 15 100%

[Eyes`Only]

ahh so I did!

Thanks for the correction.

[n1ck0s]

I had some issues with subtitles lately so I made some research. Anyway, I'd like to add that it seems like a rounding problem. Only values 6, 26, 46, 66, 86 are wrong in the scenarist script (it should be 7, 27, 47, 67, 87). I think its because a floor() function is called instead of the round() function at some point. Maybe a litle bugfix in the program that is responsible (SubRip? ReAuthorist?) would solve that issue permanetly.

[dazzle]

Okay, so I just got me one of these...:(
Didn't get any errors while importing or compiling, but when I checked the subs in WinDvd they were not there.

I checked in Scenarist, and they were all there.

The problem for me is that both the RA.scp and SA.scp, reported:
Color 1(E2)=0 %
Color 2(E1)=0 %
Color 3(P)=0 %
Color 4(Bg)=0 %
Which is then also what is shown i Scenarist (2.6).
When I increase the values in Scenarist I see the subs in the Simulation Window, if left default I can't see them.

So, how do I fix this?
Can I just increase the values, and make them stick for the whole substream...or do I have to do it for every single bpm?

Or is there a better way to take care of this?

[Trahald]

from jel - in the track editor.. click on the sub track itself( the bar with the all the sub names will highlight ). then pick tools-> change color . uncheck 'change text color' (only change display color should be checked ). then edit the colors (and/or increase the opacity values) as you like.

[dazzle]

Thanks Trahal, will test it at once!
:)
By the way: I have no idea what colors/opacity to use...is:
E2 - white 93%
E1 - grey 93%
P - grey 0%
BG - black 93%

...you think?
Took those numbers from another movie. :)

[dazzle]

Just wanted to let you know that it worked like a charm! :)
I used the settings above.

Thanks!