View Bug Details

IDProjectCategoryView StatusLast Update
0001246DCP-o-matic[All Projects] Bugspublic2018-03-28 00:11
ReporterrobnAssigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Platformx86_64OSFedoraOS Version27
Product Version2.11.0 
Target Version2.12.xFixed in Version 
Summary0001246: Burnt-in bitmapped subs always wrong with DOM (please bring back the 1920x1080 container!)
Description

DOM seems to scale bit-mapped subtitles wrt the DCP-container instead of
the video-content (for which they were designed). Because of this
the size and position of these burnt-in subtitles are always wrong with DOM.

I create quite a lot of DCPs from Blu-rays (and sometimes DVDs) for screening in our cinema.
Often these Blu-rays have a separate bitmapped subtitle track ("PGS" subs) that I use.

A typical situation is that you put a 1920x1080 (hd) Blu-ray in a 1998x1080 (flat) DCI-container.
The problem is that the bit-mapped subtitles are stretched horizontally by DOM by approx. 4%
(factor 1998/1920 = 1.041).
This degrades the quality of these pre-rendered pixel-perfect (for 1920x1080) subtitles
a bit and deforms the aspect ratio of the font.

So it would seem a solution to use a DOM "X Scale" factor of 96% (1920/1998 = 0.961)
to compensate for this. This indeed mostly neutralizes the scaling problem, but it also introduces
a new problem: the horizontal position of the subtitles is wrong (they shift to the right).

Now one could try to use a a DOM "X Offset" to compensate for the shifting.
But the problem with that is that the amount of shift introduced by the scaling depends on
the width of a subtitle .. You can never get this right: if you tune it for narrow subs,
the wide ones will be wrongly positioned. If you do it right for the wide ones the
narrow ones will be wrong ..

We could think of a complex solution where one can specify wrt to what container or resolution
the bit-mapped subs should be handled.
Or we could always pick the source video resolution.
Or we create an "always center subs" toggle that forces center-alignment to the DCP container.
All these options require (possible confusing) UI changes. Or they have other unwanted
side effects (like wrongly positioning of carefully designed non center-aligned Blu-ray subs).

But there is one easy thing that could be done to eliminate many of the problems above:
just re-introduce the 1920x1080 (and 3840x2160) DCI-container! By having a 16x9 DCP-container
it becomes possible (and very easy) to put Blu-ray subtitles on the correct position with the
right size.

As I understand it a 1920x1080 container is perfectly legal within DCI (because it is
explicitly mentioned in the standard). And I think there is no DCI-server that actually
has a problem with 1920x1080 DCPs.

Sometime ago the 1920x1080 container was removed from DOM with only Full/Flat/Scope remaining.
I suggest to put 1920x1080 and 3840x2160 (HD and UHD) back in DOM: it's DCI-compliant and it solves problems!

Additional Information

I've added some screenshot to illustrate the problem:

subs_correct.jpg                : 1920x1080 frame with correct subs
subs_dom.jpg                    : 1998x1080 DOM frame with stretched subs
subs_dom_corrected.jpg  : 1998x1080 DOM frame with un-stretched subs at the wrong position
TagsNo tags attached.
Estimated work requiredUnknown

Activities

robn

2018-03-20 23:51

reporter  

subs_correct.jpg (341,789 bytes)
subs_dom.jpg (388,964 bytes)
subs_dom_corrected.jpg (388,712 bytes)

carl

2018-03-21 00:07

administrator   ~0002313

SMPTE 429-2-2009 forbids the 1920x1080 container, so I'm not so keen to bring it back, unless that standard has been superceded. It sounds like we should scale based on the source resolution.

carl

2018-03-21 00:10

administrator   ~0002314

Some discussion here http://www.film-tech.com/ubb/f16/t003081.html

robn

2018-03-21 03:18

reporter   ~0002315

It is probably an old discussion and I certainly don't want to start a resolution war .. :-)
but it seems that 1920x1080 is explicitly allowed by sections 8.4.3.2. and 8.4.3.3. in:

http://dcimovies.com/specification/DCI_DCSS_v12_with_errata_2012-1010.pdf

and this is not changed by all the errata (up to January 2018) listed on:

http://www.dcimovies.com/specification/

But I believe you when you say that SMPTE 429-2-2009 forbids 1920x1080.
Unfortunately this spec does not seem not to be publicly (freely) available?
(can't find it) Would love to have access to it ..

Anyway, back to the subject of this bug report: of course having bit-mapped subs
scaled to the source resolution would be fine too!

In the (common) case of 1 video source with a (resolution-wise corresponding)
bit-mapped subs-track this "source resolution" is obvious.

But with mixed, cropped, scaled content or content with non-square pixels that needs
to be stretched, determining the proper source resolution might require some extra thinking.

Carsten

2018-03-21 22:10

manager   ~0002320

Last edited: 2018-03-21 23:32

View 4 revisions

We were able to read the SMPTE spec, and it is true that only flat, scope and full container is allowed, both in 2k and 4k. Actually we were glad to find this, since for many users, the proper application of scaling and DCP container was too confusing, as both the scaling and DCP container choices used the same names. When doing workshops for DCP-o-matic users, and also following the forum and mailing list, it turned out that scaling vs. container choice was most confusing problem for DCP-o-matic users.

And, as a matter of fact, there are indeed some servers that have trouble to display non-standard containers - at least they need to be setup in a special way to prevent image artifacts.

As a tester and tech-savy user, I would love to have any imaginable option in a DCP tool. But, it doesn't make usage of DCP-o-matic easier, so, even if I cut may own finger, I think we should stay on that road.

Another issue that turned up a few times recently for Carl is that of validation tools rejecting DCPs created with DCP-o-matic because of 'minor' formal standard violations. For years, DCPs created with DCP-o-matic haven't caused playback issues, but since some time, DCP entries for festivals or distribution get rejected by qc or validation tools because of these 'inaccuracies'. It is very bad for the reputation of a free software, and Carl can not just sit back and say 'as long as it plays okay on all servers, I don't care'. Festival entries are actually rejected because of these complaints. So, there is no other way for DCP-o-matic than to stick to the standards, especially now that SMPTE DCPs come into widespread use. I could imagine that at some point, non-standard containers would be rejected as well. Another similar issue is DCPs without any sound reel. I think all servers support this kind of silent DCP, but to my knowledge, it is not compliant. So, in DCP-o-matic, a minimum of 2 channels is used.

We have seen (a) few complaints about the 'missing' container types, so far I guess we manage to resist. The biggest issue for myself was that it forces letterboxing/pillarboxing to be applied for exports of non-DCI aspect ratio footage. But this may be dealt with by other means at some time.

Let's see what happens when 2.12 stable is released. In theory, we could have an advanced pref setting 'allow non-standard containers', as we have it for non-standard frame rates or j2k bandwidths >250Mbit/s. But I hope we don't need to.

I am sure that Carl finds a better way to deal with bitmap subs. I do quite a few subtitled BD conversion, but never came across your problem. Maybe I don't care enough about subtitle appearance in this application, as long as they are readable and complete.

  • Carsten

carl

2018-03-26 23:58

administrator   ~0002332

I'm sure this isn't the whole story, but if you scale subs DoM is supposed to move them to keep them centered; however there's a bug in this code that e7d33e4 (2.13.6) fixes.

carl

2018-03-26 23:59

administrator   ~0002333

From a few quick tests it looks like maybe DVD subs are prepared for the pixel size of the source (i.e. 720x576) without taking into account any non-square pixel aspect ratios that are in effect.

carl

2018-03-27 00:07

administrator   ~0002334

Subtitle path:

  • FFmpegDecoder::decode_bitmap_subtitle; emits (ContentTime, Image, Rect<double>); rect is scaled to 0--1 depending on source size.
  • Player::image_subtitle_start; content's translation/scale applied to 0--1 rectangle; put into _active_subtitles as a PlayerSubtitles [list of ImageSubtitle]
  • Player::transform_image_subtitles; 0--1 scaled to _video_container_size and image scaled accordingly.
  • put into PlayerVideo to go onward.

Carsten

2018-03-27 11:32

manager   ~0002335

Hi Carl - you mention some test versions up to 2.13.6 - have any of these been online yet? I can't see them on the test download page.

  • Carsten

carl

2018-03-28 00:11

administrator   ~0002339

2.13.7 is trickling up there now.

Bug History

Date Modified Username Field Change
2018-03-20 23:51 robn New Bug
2018-03-20 23:51 robn File Added: subs_correct.jpg
2018-03-20 23:51 robn File Added: subs_dom.jpg
2018-03-20 23:51 robn File Added: subs_dom_corrected.jpg
2018-03-21 00:07 carl Note Added: 0002313
2018-03-21 00:09 carl Target Version => 2.12.x
2018-03-21 00:10 carl Note Added: 0002314
2018-03-21 03:18 robn Note Added: 0002315
2018-03-21 22:10 Carsten Note Added: 0002320
2018-03-21 22:36 Carsten Note Edited: 0002320 View Revisions
2018-03-21 22:46 Carsten Note Edited: 0002320 View Revisions
2018-03-21 23:32 Carsten Note Edited: 0002320 View Revisions
2018-03-26 23:58 carl Note Added: 0002332
2018-03-26 23:59 carl Note Added: 0002333
2018-03-27 00:07 carl Note Added: 0002334
2018-03-27 11:32 Carsten Note Added: 0002335
2018-03-28 00:11 carl Note Added: 0002339