Miscoloured subtitles again

[Anders M Olsson]

I haven't had any reason for making a DCP in more than a year, but I suddenly got a job that requires me to create a DCP with burnt-in subtitles from an existing DCP. However, I found that the latest versions of DCP-o-matic have a new problem with miscoloured subtitles.

You don't even have to create the DCP - you can even see it in the preview window. (The samples below have been blown up to accent the problem.)

Also, some letters get very strange outlines. For example, take a look at the left side of the Danish character "ø" above.

Tested with versions 2.12.4 and 2.13.19.

So I installed an old version which I have had success with before (2.9.21), and sure enough, the problem went away:


The samples above are screenshots from the preview window, but the problems are in the finished DCPs as well. The font is common Arial with a reduction to 66% of its size, and an outline of 4 pixels.

[Carsten]

Weird. I don't see that with 2.12.4. Is it possible this coloring only happens with specific source content/color space?

I tested with a simple JPEG still as the background. I don't see significant coloring - neither in preview nor final DCP in player 2.12.4.

Can you check your source content, so I may try it with a similar sample? What is the data rate of your DCP, and do you play back in DCP-o-matic player at full or reduced decoding resolution?

Keep in mind, burning in will always cause a minor smear between subtitles and background, that is how J2K works. High contrast and/or color saturation between background and subtitles will inevitably cause some smearing even at very high bitrates.

Can you attach just the metadata file so we may have a look at your settings?

- Carsten

[Anders M Olsson]

Try setting X Scale and Y Scale to 66% and Outline width to 4.
I'm sure you'll see the problem if you make a screen shot and zoom in on the subtitle.

This is a quick test with a still image and just a single subtitle:


Decoding is at full resolution.

The problem is perhaps not as apparent as in the preview window, but it's still there.

Also, look at the left edge of the letters "t" which have broader outlines than the other letters.
When I use the font "Arial Rounded MT", I get some very strange looking lower case v:s.:


None of these issues are there with the older version of DOM.

[Carsten]

Hmm... Honestly, in your own JPEG example it is hard to see any of that issue. Also, a 66% subtitle with an outline 4 is REALLY small on an actual cinema screen.

Now - how do you create these screen shots? When I create a screenshot in DCP-o-matic player and enlarge - I see a lot more coloration than when I do an actual grab of the decode full res image. At least on my notebook, DCP-o-matic player does not display a full-res decoded image at full 2k resolution. Hence the screen-shot may contain some rescaling artifacts that are not actually contained in the DCP.

When I do a VLC video snapshot on the same DCPs mxf, the burn-it subtitle looks a lot cleaner, no coloration. VLC video snapshots are taken at full decoded native source resolution. That's a clear advantage compared to taking screenshots of DCP-o-matic player. Also, again, a screenshot of my preview with a font at 66% and a size 4 black outline does not show any miscoloration at all.

See attached screenshots. Can't comment on the difference to your previous DCP-o-matic version without your issues, but so far, I am not entirely convinced that we do actually have an issue here. No insult intended, but it may even be that your screen settings, graphics card, screen shot utility, etc. created these artifacts. I know there is a longish discussion on Mantis when subtitle coloration appeared first, I may need to look that up again for some explanations on what happens there.

Again, in your initial test, I assume you placed burn-in subtitles over a video. What format/source color space and resolution does that video have?

- Carsten

[Carsten]

Another VLC video snapshot from a DCP/mxf created with a cyan-outlined burn-in subtitle (66% - outline 4).

- Carsten

[Anders M Olsson]

I first noticed the problems when testing a DCP on a cinema screen. I could tell that there was something wrong with the subtitles, but I wasn't sure what it was. The subtitles just looked "dirty" compared to another DCP which I had made a year and a half ago. Also, the strange shadows on the left side of the letters "v" stood out. So I went back home to try to figure it out. That's when I found the very slight shades of colour inside the letters.

You are right that the issue is not there in your examples, Carsten. Do I remember correctly that you're using a Mac? Perhaps that's the difference, since I use Windows 10.

I have now tried a completely different computer to rule out any problems with the processor or graphics card. Same problems. The first one uses an AMD processor and an AMD (ATI) graphics card. The second one uses an Intel I7 processor and its internal (Intel) graphics.

I also tried DOM version 2.10.5 which does NOT fix the problem.

However, the old version 2.9.21 does indeed solve the problem! Since I'm beginning to run out of time for my project, I see no other solution than to revert to the old version for the time being, and hope that Carl will take a good look at the problem for a possible later fix.

And to answer your question about the source material. The source is a DCP of 1998x1080, same as the destination.

[Anders M Olsson]

These screenshots should illustrate the problem more clearly.They were taken from the final DCPs with the VLC snapshot funtion, and blown up to 4 times their original size for clarity. You can't say that you don't see it now, can you?

Bad: (With DOM version 2.12.4)
Note the colouring inside the letters, and the strange shape of the outline around the letter "v"!


Good: (With DOM version 2.9.21)

[Carsten]

I will try on a Windows machine as well. I understand windows uses system wide font smoothing technology (clear type), and I read some articles about how that technology may render chars in a weird way. I know that some people complain about the way clear type creates false colors in creating RGB subpixel rendering of chars. Maybe this font display technology even reaches out into DCP-o-matic for windows by using system functions?

You may also try this:

http://www.thewindowsclub.com/disable-f ... ng-windows

- Carsten

edit - it's not the source video format (could be a possible cause because of different color conversions between different source color spaces and RGB subtitle color space) - the attached screenshot is from the official SW8 trailer, so, DCP/j2k. Again, done on a Mac.

[Anders M Olsson]

Yes, disabling ClearType seems to solve the problem.

It's also possible to disable smoothing of screen font edges completely, but that gives a very hard appearance to the subtitles. I think getting rid of ClearType is sufficient for a pleasing result.

Question is - can Carl make it so that DOM ignores ClearType locally within the program, so you don't have to set it globally in Windows? ClearType is only intended for personal LCD-screens and is useless for a DLP projector in a cinema.

[Carsten]

I would assume that the font rendering bypassed ClearType somehow in DCP-o-matic 2.9.x, so, maybe there is a way to do it intentionally? Agree that it doesn't make sense for cinema subtitling.

Hmm. At some point I encouraged Carl to implement antialiasing for burn-in subtitles. Maybe that is the result of it?
I filed a bug on Mantis.

There is some detailed info and examples of the ClearType color fringing issue on the ClearType Wikipedia entry:

https://en.wikipedia.org/wiki/ClearType

- Carsten