Artifacts in exported ProRes

[marcel]

When trying to convert an MKV file with PGS subtitles to ProRes 422 HQ using DCP-o-matic's export video function, I consistently see artifacts at the right side of those (then burned-in) subtitles. They appear as green and/or purple pixels like this:

Scherm­afbeelding 2025-11-06 om 21.18.50.png

The source of the MKV file is a blu-ray (but I don't think this matters, and it appears using all MKVs containing PGS subtitles):

Scherm­afbeelding 2025-11-06 om 21.49.50.png

I just load the MKV in DCP-o-matic, choose the container format 1.78 (for which you have to select the non-default container formats in settings), select 'use as open subtitles' in timed text tab and then export video to MOV / ProRes HQ. I'm using 2.18.24 on a Apple M1 Mac.

I know this is a bit beyond the intended scope of DCP-o-matic (which we happily use to render DCPs and never had such issues with PGS subtitles, but I know JPEG2000 rendering is something entirely different), but before I delve into more details and options, do you think this is an FFmpeg/Lavf issue or a DCP-o-matic bug?

[carl]

Strange - I tried it here with a file containing PGS subtitles and could not reproduce. I would guess it's a DCP-o-matic bug.

Is it possible to make a MKV clip which shows the problem?

[marcel]

I'll send you a clip by email. Also note that it can't be the version of MakeMKV which we used to create the MKV, the same problem exists with MKVs created with the newest version of that program.

[Carsten]

So, these artefacts appear only on ProRes exports from DCP-o-matic, but not if you create a DCP from the same project?

[marcel]

That's correct, or at least it's very likely: we consistently see them in those exports, at the right side of about 1/4th of the subs, but we never noticed them in DCPs we created from other blu-rays, when we had a screening room with a cinema server. On the other hand, we never burned those subtitles into the video of the DCP, but used the PNGs in a subtitle track.

[IoannisSyrogiannis]

[...] On the other hand, we never burned those subtitles into the video of the DCP, but used the PNGs in a subtitle track.

So, if you were creating PNGs in a subtitle track on the DCP, it would have been interesting to try and export a portion of such a DCP to ProRes with the subtitles burned in.
Isn't there an alpha channel on DCP PNGs?
Wouldn't that mean that the resulting ProRes would also reproduce the same artifact? (That is a guess I am making.)

[marcel]

Thanks for the suggestion, the issue remains after creating a DCP of a clip and then importing that DCP in DCP-o-matic again and creating a ProRes of it. (And there is an alpha channel on those PNGs, as well as those in PGS subs, otherwise you wouldn't be able to view the screen when a subtitle is shown, I guess. .)

[marcel]

Just a small addition, to be more precise: in the last case (MKV -> DCP -> ProRes) the issue appears at different (subtitle) positions than in the original conversion.

I just tried to do the original conversion again (MKV -> ProRes), but 'luckily' the artifacts appear at exactly the same spots.

EDIT: I re-did the MKV -> DCP -> ProRes conversion, now immediately using a 16:9 container for the DCP, instead of a Flat one and cutting of the edges in the DCP -> ProRes conversion step, and now the artifacts seem to appear at the same spots as when directly converting an MKV to ProRes.

[IoannisSyrogiannis]

Thanks for the suggestion, the issue remains after creating a DCP of a clip and then importing that DCP in DCP-o-matic again and creating a ProRes of it. (And there is an alpha channel on those PNGs, as well as those in PGS subs, otherwise you wouldn't be able to view the screen when a subtitle is shown, I guess. .)

It was a rhetorical question, leading to the next, but thank you all the same for taking the time to reason. If I may add to that course of reasoning, the size of the PNG files is most often not as big as the main feature.

[carl]

I think this is due to DCP-o-matic getting the alpha blending wrong if the subtitles are either at an odd position or have an odd width (so that they land in the middle of a subsampled pixel). I hope to have a fix soon.