test chart black and white issue

[TonyK]

Hi everyone,

I’m hoping someone on the team can review this issue for me.

I’ve created a DCP using some test charts, but I’m noticing that the whites and blacks are not reproducing correctly in the final DCP.

For reference, here are the source image details before conversion:
• Format: PNG
• Resolution: 3840x2160
• Colour space: RGB
• Colour profile: sRGB IEC61966-2.1
• Alpha channel: Present

After conversion to DCP, the contrast seems off, with whites not appearing true and blacks looking lifted.

Has anyone experienced this before, or can advise if this is related to colour space conversion (sRGB to XYZ), gamma handling, or possibly the alpha channel?

Any guidance would be greatly appreciated.

Thanks in advance,
Anthony

please see NOTE below

HOW TO USE THE CALIBRATION IMAGES.

One image has white rectangles on a bright background, and one has black rectangles on a dark background.

The purpose of the images is to ensure that your monitor is set up correctly. You should not be able to perceive the edges of the very darkest rectangle, nor the edges of the brightest rectangle. You should be able to just barely perceive the edges of the second darkest rectangles, and the edges of the second brightest rectangles. 

If you’re seeing all of the dark rectangles, your monitor is too bright. If you can’t see the second darkest rectangles, your monitor is too dark. 

If you’re seeing all of the brightest rectangles, your monitor too dark. If you can’t see the second brightest rectangles, your monitor is too bright.

Please adjust the brightness and contrast settings on your monitor until you can see all the rectangles apart from the brightest and darkest.

All of the rectangles should be neutral - there should be no colour cast or tint on any of them.

Some monitors are simply not capable of displaying accurate brightness and colour balance. If this is the case, the images need to be viewed on a professional, calibrated monitor, for an informed assessment to be made.

[Sami S]

Did you import the PNG's direct to Dcp-o-Matic?

You could try to make the test charts in Resolve (make sure it looks correct in Resolve) and export a Prores HQ file that is Rec 709 Gamma 2.4 and then in Dcp-o-matic choose Rec1886 (Equals Rec709 2.4 in Dcp-o-Matic) and see if the DCP comes out right and fixes the issue?

[elmermakkinga]

I was able to reproduce this issue. The blacks are clearly lifted. However, when I change the colourspace of the PNG from sRGB to rec709 inside DCP-o-matic and re-render, the issue seems to disappear. The difference in the whites is much harder to notice, I'm not sure my eyes aren't deceiving me there.

If I convert the image to JPEG first, the issue persists, so the alpha channel can't be what's causing it here unless the conversion software (just the mac preview application) handles it in the same way DOM does.

I'm at work right now, so I had to use DOM version 2.16, since I don't have the password needed to update it.

[TonyK]

Hi,

Thank you for taking the time to look into this issue, it’s much appreciated.

I’ve had a chance to run some additional tests and wanted to share my findings, as well as ask for a bit of clarification around how DCP-o-matic is handling gamma and colourspace.

Using the same source material, I created a DCP with the default settings and noticed that the blacks appeared lifted as mentioned after conversion. I then manually adjusted the input gamma from 2.6 to 2.2, from the projector and this corrected the issue, with blacks and overall contrast appearing as expected.

From what I can see, this suggests there may be a mismatch between how the source gamma is being interpreted and how it is being converted into the DCP colour space.

This raised a couple of questions:

• Is the source gamma being misinterpreted (for example assuming sRGB or a different gamma than intended)?
• Is the conversion pipeline applying a transform to DCI gamma (2.6) based on that assumption, which could explain the lifted blacks?
• Or is there something else happening in the way PNG or still image sources are being handled?

Additionally, I wanted to ask whether there is (or could be) an option to explicitly define gamma within the workflow, similar to how we can select full or legal range. At the moment, it seems that controlling gamma requires manually overriding the colourspace rather than adjusting gamma directly.

Thanks again for your help, and I really appreciate the support.

Best regards,
Anthony

[carl]

Just for clarification, are you judging the lifted blacks etc. by looking at a projected image (from a DCI projector)? Or some other way?

[TonyK]

Yes that’s right I’m using a DCI NEC 4K projector

[elmermakkinga]

My quick-and-dirty test was done by comparing the j2c MXF and the source image on the nicest monitor I could find.

[carl]

I took your PNGs and made DCPs from them using the default DCP-o-matic settings (with version 2.18.37) and the black in the border of the black test looks right to me (XYZ is 0, 0, 0 in the DCP's MXF) so I'm a bit at a loss as to how that can look lifted.

The full white is indeed a little low (but only a little) due to a rounding error that I should be able to fix.

Are you saying that even the border of the black calibration test (i.e. the total black) looks lifted? Can you send me the video MXF file of the DCP you made? (carl@dcpomatic.com)

Thanks!