Burn-In Subtitle color

[Carsten]

Okay, since this issue has nothing to do with outline, let's go from here to this new thread:

- I created a 5s DCP/MXF by using a full white (255,255,255) sRGB TIFF, using sRGB color conversion in DOM
- I created a new project in DOM and imported the resulting full white MXF, set it to 'no color conversion'.
- I added a basic srt subtitle, set it to full white (255,255,255) with the color picker, checked burn-in and outline, and created a new DCP/MXF

I grabbed a still through VLC, which I attach to this post. Clearly, the white sub comes out greenish-cyan, which it shouldn't (228,255,243).

When I use a bright gray (217,217,217) for subtitle color, I get (173,219,224). So it does seem there is something wrong with the subtitle color correction. I don't suggest we should consider VLCs snapshot color conversion being 100% accurate - but there is just too much difference between background and subtitle color, and I see the same issue in Doremis Cineplayer.

Now - the weirdest part of this: As the subtitle file was longer than my 5s full white MXF, the MXF created with the burn-in subs contained some black background with the remaining subs in them - and these subs did NOT show a color shift - when I open a VLC grab from the black+sub part, I get neutral grey (207,207,207)...

So this may not be an issue of color conversion of the subs, but an issue of compositing source and subtitle? Because the color conversion can hardly change with background footage?

If it's a compositing issue, it may well be that not only subs on MXFs suffer this issue, but all burn-in subs?

- Carsten

[carl]

This should be fixed in 2.9.15. Thanks for everybody's work in debugging.

So this may not be an issue of color conversion of the subs, but an issue of compositing source and subtitle? Because the color conversion can hardly change with background footage?

It can with DoM because the background footage may be in, say, sRGB (which will be converted to XYZ for the DCP) or XYZ (which will be left alone for the DCP). The compositing happens at that stage, and in the latter case the subtitle must be converted to XYZ. This was being done slightly wrongly pre-2.9.15.

[Carsten]

Ah, right, I forgot the black that DOM creates is created at render time and probably not in XYZ, but from sRGB, so there is a difference between the full white XYZ and the following black. I should have tested with white MXF and black MXF both in XYZ...

I'm redoing the project now with 2.9.15... yes, subs come out as neutral grey now.


- Carsten

[carl]

Cool, thanks for checking.

[Anders M Olsson]

Yes, the subtitle color problem seems to be solved now. A big thank you for that!

[Cantar4]

Hi Carl, now that you have solved all pending subtitle problems, may we have a cherry on the pie,
i.e. separated subtitle tracks (as you do for audio tracks),
for eliminating superpositions which are difficult to read, catch and drag.?
and while you are at it, why not two independant tracks for video and stills...

[carl]

OK, I've put that on the tracker.

[Cantar4]

DoM 2.9.18:
testing subtitle outlines (v good),
and fade ins / fade outs,
whatever their time length,
a weird preflash shows ahead of each.

[carl]

The flashing should be gone in 2.9.19 which will be along shortly.