DCP-o-matic

Hi,
not sure if there's already been discussion and/or a bug report about this issue, but here goes.

To reproduce:
1) Add a file with 4:2:0 chroma (such as a Blu-Ray rip from MakeMKV)
2) Set "Scale to" to "No stretch"
3) Find a scene with distinct areas of bright red color
4) Increase "Left crop" one pixel at a time, while keeping a close eye on the red areas

With certain "Left crop" values, I'm seeing two things:
A) the overall brightness of the image decreases slightly
B) there's a horizontal shift to red chroma that doesn't match the rest of the picture

Depending on your container size and other variables, this may happen when "Left crop" is set to eg. 2, 3, 5, 6 or 7. With other values (such as 0, 1, 4 or 8), the problem is less apparent or even nonexistent.

Setting "Scale to" to something else than "No stretch" fixes issue A, but not the more serious issue B.

On the other hand, converting the video file to ProRes 422 HQ before importing to DoM fixes issue B, but not issue A. So it would seem like we're looking at two different bugs...

Hi, thanks for the report - I see what you mean! That's a nasty one!

I made a bug report and I'll take a look as soon as I can.

Do we know which versions are affected? I understand it is limited to 4:2:0 sources?


- Carsten

It happens at least on `master` (v2.14.x) and `v2.15.x`. I would guess it's been there for a while.

At least 4:2:2 and 4:4:4 ProRes files seem to be immune to the red shift, but they're still affected by the darkening (which is really a non-issue compared to the nasty red bug).

Yeah, I'm afraid it's been there a while, not sure about the oldest affected version though... Sorry for not reporting earlier!

No problem!

Things should be better in 2.14.43 if anybody wants to try it.

The red shift is gone for me – yay! The luma drop is still there, though, which would seem to confirm that it's a completely separate issue.

Also, the player crashes on start now with this error message (I'm on Ubuntu 20.04):

ASSERT INFO:
./src/common/sizer.cpp(2112): assert "!(flags & wxALIGN_CENTRE_VERTICAL)" failed in DoInsert(): Vertical alignment flags are ignored in vertical sizers

BACKTRACE:
[1] main
[2] __libc_start_main

The luma drop could be a regular result of the color conversion!? How do you verify it is actually a 'drop'?

- Carsten

I think it's some weird artefact of a bug where

- the user asks to crop to a width of 931
- that's an odd number so because of YUV subsampling we decide to crop to 930
- but we still scale to 931

so as we crop from 0 pixels upwards we go through scales of 1:1 and 1:very-close-to-1 which I think is causing the luminance changes. Anyway if I make the scale work with the crop it looks better; there's a 2.14.44 nearly ready which should show that.

Ah, missed that, the luma drop is with certain crop values, not with others, so that is obvious.

- Carsten