DCP-o-matic

@Carsten it looks like video/limited range sources aren't being expanded to full range for the preview/DCP ... there's this strange FFmpeg API where you ask it to convert video ranges but then it only does what you ask if both source and output are YUV or greyscale. I spotted that a while ago and added some code to DoM to do the conversion when the source is RGB, but missed the case when the destination is RGB (as it is for preview and DCP).

As you say, it's hard to believe, and maybe I missed something - it will be interesting to try it out.

Okay, I'll do some testing once you have a build.

carl wrote: ↑Thu Aug 11, 2022 9:51 pm I think you may have found a slightly unbelievable bug in DoM (in the sense that it's hard to believe it hasn't been spotted before) in which it handles "limited" (video-range) sources wrongly. I have a potential fix here; I'll make a test mac build overnight and send you a link with a new version to try as soon as I can.

Wow, amazing. Thanks Carl and Carsten for digging into this. I'm happy to test any bug fixes, please keep me posted!

Hmm. Strangely, the video monitor clearly shows blacks expanded downwards. I regularly see 'bad' conversions in cheap ads, showing raised blacks from limited vs. full range misinterpretation. I don't see that with his test clip, and I am sure I would have noticed with other footage. Maybe it only hits for certain parameter footage. Let's see...another case for priest's socks

I think I was wrong about the bug - I did some tests with white and black limited-range YUV frames and seem to be converted correctly to full range for the preview and DCP.

I converted the MOV you attached to TIFFs with `ffmpeg` and got this frame as an example. I'm struggling to be sure what is right and wrong. Does this TIFF have the washed-out problem?

Doesn't look washed out. But it looks the same as my attempt with the standard built. So, puh..., I think DCP-o-matic did it right before. There are very small highlight differences between DCP-o-matic and other players, but they are small enough to ignore them.


Can you try to replicate the issue with the brightness/gamma issue betweeen safe/simple and OpenGL mode in the player?


- Carsten

RIght, yes I can see the difference with the OpenGL renderer, I made a bug report. Looks like a silly mistake with the XYZ -> RGB gamma conversions being done backwards in the OpenGL code. Test version coming in a couple of hours...

What I can't understand is why it's wrong in the cinema. It doesn't look like the sort of place that would let things like this go!

This build should fix the incorrect colour levels with the OpenGL viewer.

How easy is it for either of you to test things on a projector? Maybe we could make a DCP of that short clip that is attached to this thread and then run it on a projector, and also examine its pixel values to see if we can work out what is going on?