View Bug Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002590 | DCP-o-matic | Bugs | public | 2023-07-07 17:23 | 2023-12-22 22:32 |
Reporter | overlookmotel | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Platform | Mac | OS | OS X | OS Version | 10.14 |
Product Version | 2.16.59 | ||||
Target Version | 2.16.x | ||||
Summary | 0002590: ProRes export reduces luminance and produces artefacts in dark regions | ||||
Description | When exporting a DCP to ProRes with DOM, there's a noticeable reduction in luminance and unpleasant colour artefacts appear in areas of image very close to black. This isn't at all new - have been seeing this consistently for years in 2.14.x, 2.15.x and 2.16.x. But have only just found time to properly investigate. Example below:
Below are the 3 as seen on Resolve's scopes. The DCP is an accurate representation of the original ProRes (except for noise in blacks - in practice not visible). The conversion back to ProRes, however, noticeably alters the image in 2 ways:
The diagonal line in the scopes image is the black-to-white gradient in bottom half of the colour bars. In the original, it's a straight line proceeding in small steps. In the DCP to ProRes export, however, there's a large step at the bottom of the gradient, and the colours diverge from each other. In real footage, this manifests as banding artefacts which appear as dark green blocky splodges in dark areas. This is mostly not visible, but very dark scenes e.g. "don't go down to the basement" in horror films can be very badly affected. I believe this is actually the fault of FFMPEG. I get exactly the same result doing the same conversion with FFMPEG (recent nightly build of 6.0).
I'm going to raise a bug report on FFMPEG. However I'm not sure how easy it'll be to get it fixed upstream, so thought I'd raise it here too. Since DOM already knows how to do XYZ-Rec709 colour space conversion, I wondered if it might be better for DOM to handle that conversion, before passing it to FFMPEG? | ||||
Tags | No tags attached. | ||||
Branch | |||||
Estimated weeks required | |||||
Estimated work required | Undecided | ||||
|
|
|
FFMPEG bug report: https://trac.ffmpeg.org/ticket/10451 |
|
I'm wondering if the reduction in levels is due the conversion missing out the inverse of the "Normalize values" step outlined in https://dcpomatic.com/manual/colour.pdf which is a roughly 8% reduction in levels. What is this "Normalize values" step anyway? In the colour document, it seems rather arbitrary/unexplained. |
Date Modified | Username | Field | Change |
---|---|---|---|
2023-07-07 17:23 | overlookmotel | New Bug | |
2023-07-07 17:23 | overlookmotel | File Added: ProRes source image.png | |
2023-07-07 17:23 | overlookmotel | File Added: ProRes source.png | |
2023-07-07 17:23 | overlookmotel | File Added: DOM DCP.png | |
2023-07-07 17:23 | overlookmotel | File Added: DOM DCP export annotated.png | |
2023-07-07 17:23 | overlookmotel | File Added: bars premiere 1998x1080 ProResHQ.mov | |
2023-07-07 18:22 | overlookmotel | Note Added: 0005852 | |
2023-07-08 15:31 | carl | Target Version | => 2.16.x |
2023-07-08 15:31 | carl | Estimated work required | => Undecided |
2023-07-10 10:28 | overlookmotel | Note Added: 0005856 | |
2023-12-22 22:32 | carl | Status | new => acknowledged |