View Bug Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002361DCP-o-maticBugspublic2022-10-27 20:312024-01-03 23:51
Reporteroverlookmotel Assigned Tocarl  
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
PlatformMacOSOS XOS Version10.14
Product Version2.16.31 
Summary0002361: Encoding glitch in 4K DCP from ProRes
Description

With a particular input file (ProRes422) I'm seeing nasty artefacts in the resulting DCP. The artefacts could largely be described as "ringing", but there's also a nasty red splodge (the film is black and white). The artefacts are seen in dark areas (close to black). It's quite noticeable.

Input is encoded with gamma 2.4 so am using input colour space setting Rec. 1886.

Observed in 2.16.32 (and also 2.16.18 and 2.14.54 - i.e. it's not new), although it's a bit better in 2.16.32 than in older versions.

Variations I've tried:

  • Converting input to ProRes444 before bringing in to DCP-o-matic (in case related to sub-sampled source)
  • SMPTE and Interop output
  • Setting input colour space to Rec709 (the red splodge disappears, but other artefacts still present)
  • Pre-scaling input to 3996x2160 before bringing into DCP-o-matic, so DOM doesn't have to scale
  • Encoding at lower bitrate (150 instead of 200)

None of these solve the problem. Making DCP 2K does largely solve it, but obviously images loses resolution.

Steps To Reproduce

Carl I'll send you a repro case.

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work required

Activities

carl

2022-10-27 22:22

administrator   ~0005278

Hey, I think I can see the general grottiness in the dark areas, but I can't see the red splodge - whereabouts in the image should I look?

overlookmotel

2022-10-28 03:15

developer   ~0005279

All the action is towards the bottom left corner. Red splodge is in far bottom left corner at 00:00:01.15.

There's another unpleasant artifact at 00:00:01.03 - a weird stripy blot.

Looking at it now in DCP-o-matic, it doesn't look so bad, but perhaps that's because it's only decoding the 2K layer. In Resolve or EasyDCP Player (demo), decoded at full 4K res, it's much more evident.

I've made also tried making DCP from the same file in Resolve and it also produces some grimy compression artifacts in the same area of the picture - so evidently there's something about this picture which is hard to encode. But the artefacts are much less pronounced in Resolve's DCP than in DCP-o-matic's.

overlookmotel

2022-10-28 03:18

developer   ~0005280

The artifacts are also visible if you unwrap the raw J2K frames with asdcp-unwrap and view them in an image viewer.

carl

2022-10-31 22:50

administrator   ~0005281

I had a look at the file you sent, and it does more-or-less seem like the JPEG2000 encode/decode (in OpenJPEG) mangles this file quite badly, as you have described. From a purely mathematical diff of the pixels before/after encode, things get better as you go up in J2K bitrate.

I still need to look at whether other parts of the processing pipeline are also doing things badly, to exacerbate the problem.

Bug History

Date Modified Username Field Change
2022-10-27 20:31 overlookmotel New Bug
2022-10-27 22:22 carl Assigned To => carl
2022-10-27 22:22 carl Status new => feedback
2022-10-27 22:22 carl Note Added: 0005278
2022-10-28 03:15 overlookmotel Note Added: 0005279
2022-10-28 03:15 overlookmotel Status feedback => assigned
2022-10-28 03:18 overlookmotel Note Added: 0005280
2022-10-31 22:50 carl Status assigned => in progress
2022-10-31 22:50 carl Note Added: 0005281
2024-01-03 23:51 carl Status in progress => confirmed