View Bug Details

IDProjectCategoryView StatusLast Update
0001375DCP-o-maticBugspublic2024-02-16 09:02
Reportercarl Assigned To 
PriorityhighSeverityminorReproducibilityhave not tried
Status acknowledgedResolutionopen 
Summary0001375: Colour accuracy in the player probably isn't great

This needs checking out.

Estimated weeks required
Estimated work requiredMajor


related to 0000499 confirmed Colour transformations are slightly off 
related to 0000908 acknowledgedcarl Correct colors when scaling? 
related to 0000421 acknowledged Some means of previewing changes in gamma / colour correction 



2018-12-20 22:23

administrator   ~0002811


2018-12-20 22:23

administrator   ~0002812


2019-02-02 16:30

manager   ~0003041

Last edited: 2019-02-02 16:56

I think, for now it is more important to get the playback performance right on higher resolution displays. It seems that the current video rendering can sometimes slow down the playback more than the j2k decoding (or at least in the same ballpark). I think users are more concerned about stuttering than color.

VLC can use GPU aided decoding/rendering (I don't mean J2K) across all platforms it seems, so, DCP-o-matic may be able to do it as well?
Maybe you can profile the issues about the actual viewport rendering (scaling, color conversion, etc.) somehow?

I think in Windows there are so many different APIs to render videos, and some of them may bypass system color management, some not. I am sure it's a nightmare. Professional color graders use dedicated output hardware for monitoring (e.g. a HDMI card for rec.709, or HDSDI for P3) to make sure they see proper colors.

I think most users simply underestimate the effort needed to establish and maintain a solid calibrated display pipeline between capture, editing, color grading and playout. They assume that what they saw during the editing on 'some' display has to be the same what DCP-o-matic player is showing on the same or a different display. We simply have to communicate that a DCP can only be judged by playing it back on a calibrated cinema projection system.

There may be some 'hard' issues around color misinterpretation though that need to be addressed (e.g. full/limited range, etc.). These can cause considerable differences beyond the screen calibration issue.

I have seen similar color rendering complaints about NeoDCP. NeoDCP offers some display gamma options to adjust playback. As soon as you mention them, the discussion ends. Which typically means, users then simply choose a different gamma for playback until it suits their taste, but do not care wether that is an educated decision towards truthful color rendering. Then they may be surprised or not in the cinema again.

Again, I would love to see a cursor based xyz and x'y'z' display in video waveform monitor, as that would make it easier to pinpoint issues. We need to make sure that the proper values go into the DCP first.

  • Carsten

Bug History

Date Modified Username Field Change
2018-09-29 22:20 carl New Bug
2018-10-17 10:33 carl Priority normal => high
2018-10-17 10:33 carl Status new => acknowledged
2018-10-17 10:33 carl Estimated work required Unknown => Major
2018-12-20 22:23 carl Note Added: 0002811
2018-12-20 22:23 carl Note Added: 0002812
2019-01-06 23:39 carl Target Version 2.14.0 =>
2019-01-06 23:43 carl Target Version => 2.16.0
2019-02-01 01:00 carl Relationship added related to 0000499
2019-02-01 01:01 carl Relationship added related to 0000908
2019-02-01 01:02 carl Relationship added related to 0000421
2019-02-02 16:30 Carsten Note Added: 0003041
2019-02-02 16:34 Carsten Note Edited: 0003041
2019-02-02 16:45 Carsten Note Edited: 0003041
2019-02-02 16:46 Carsten Note Edited: 0003041
2019-02-02 16:47 Carsten Note Edited: 0003041
2019-02-02 16:50 Carsten Note Edited: 0003041
2019-02-02 16:53 Carsten Note Edited: 0003041
2019-02-02 16:56 Carsten Note Edited: 0003041
2019-12-17 08:10 carl Target Version 2.16.0 => 2.18.0
2022-09-10 21:41 carl Target Version 2.18.0 =>
2024-02-16 09:02 carl Tag Attached: player