Strange color noise in an actress' dress after conversion

[freezer]

Hi, have been silently reading here for a long time, but now I stumbled over a strange color phenomenon I've never encounter before.

I have been preparing a DCP of our latest indie feature for a festival.

Shot on a Sony FX6 in 4k DCI AVC Intra 4:2:2 10bit, slog3 cine.
Grading was done in Resolve 17.4.3 and the final export was made into a rec.709 1920x1080 24p DNxHD 4:2:2 10bit MXF.
Everything looks great.

Converting the master file into a DCP via DCP-o-matic had a problem first when writing the DCP back to the server over a 10Gbit connection, which seemed to somehow mess up DCP creation.
So I started to export the DCP locally and in parallel also started a DCP creation via Media Encoder Wraptor-DCP (just in case).
I had restricted the bitrate for DOM to 100 MBit because I was running out of time for the upload.
Wraptor-DCP does its own thing with the bitrate which resulted in only 42 Mbit.

After both finished I started to compare conversions out of curiosity, if I can spot a difference because of the bitrates.
That's when I came to a scene where one of the actresses is wearing a deeply purple-red colored dress.
First I thought (inspecting a still) well there I can spot a difference - DOM conversion does show much more details of the dress than Wraptor-DCP conversion. But after playing I saw that both versions did in fact show color splotches randomly dancing around in the dress.
It can be seen both in Media Player Classic MPC-HC and Resolve when importing back the DCP.

I made sure that this wasn't already in the master, and in fact the master was unproblematic.
So I thought maybe the bitrate was to blame and did a partially conversion of the scene with DOM set to its default 150 Mbit.
This did not help with the dress color splotches.

As this happens with two completely different tools I do think it is not an inherent bug of DOM, but rooted somewhere in my workflow.
My conclusion is atm, that there could maybe some corner case in the color conversion from the master file into XYZ color space.

I have provided a 50 sec sample of that particular scene from the master file MXF DNxHD and also my resulting DCP file which includes also the logs in the ZIP archive.

You can download the samples here for further inspection:
https://laufbildkommission.filemail.com ... irljbzppvu

Hoping for some input and advice.

EDIT A:
I have now tested a short clip with the dress exported as DNxHR 444 12bit and it shows similar dancing splotches, but finer splotches.

EDIT B:
Even from a 16bit TIFF sequence I get the dancing noise.

[Carsten]

Hi Robert,


we have noticed a certain weakness of JPEG2000 with fully saturated colors between high contrast transitions previously.

https://dcpomatic.com/forum/viewtopic.p ... =artefacts

The samples are gone, but the issue is still there, and we only found an acceptable workaround, not a solution back then.

Let me have a look at your footage.

Did you try Resolves Kakadu DCP export? That uses a totally different JPEG2000 encoder.

Sometimes it may be necessary to apply some very specific filtering to such scenes in order to avoid it. I have, though, never heard about these issues on major DCP/studio mailing list discussions (e.g. ISDCF). It must happen pretty rarely and under very specific conditions (e.g. reflecting micro surfaces under monochromatic LED/Laser light), creating a combination of highly detailed, high contrast, highly saturated image structures. Increasing the bitrate helps, but only to a certain extent. Also, some prominent servers may fail on higher bitrate DCPs, so, going beyond something like 230MBit/s may be problematic.

- Carsten

[freezer]

Hi Carsten,

yes, I have now also tried Resolves Kakadu export - same thing.
The dress seems to be of a very fine grid and slightly triggers moire in the camera. And the green channel is almost void of color information.
I think it is a combination of wandering moire in the red and blue channel and because of the lack of green luma.

There is another factor and that is the viewing monitor. I have a two monitor setup of a 21:9 screen with standard sRGB left and 16:10 screen with wide gamut on the right (both are calibrated, but obviously the wide gamut screen is the reference).
Watching the DCP on the left screen makes the appearance much worse, while on the right one it is less pronounced.
So there comes the viewing LUT into play too.

It really looks like a wild corner case.
I have a new EIZO ColorEdge monitor with true 10bit and internal 16bit calibration LUT on order. Will test out the DCP with that when it arrives in the next days.

[freezer]

Ok, I went back into the grading suite and reworked all shots.
1. apply Neatvideo at the first node with special care of the color channels
2. after the established look and the last node I added three additional nodes just for the dress treatment
2a. selection mask -> reduction of micro contrast -> very slight blur

that should take care of the dresses color problem, at least I hope so

[Carsten]

Yes, I noticed back then that Kakadu doesn't make a difference with that specific issue. It appears to be a specific JPEG2000 weakness.It even happens when using non-cinema JPEG2000 code, e.g. JPEG2000 still image formats from Photoshop, Quicktime, etc. It's similar to standard JPEG contrast ringing, and it hits only with very specific content.

A very simple way to identify the issue visually is to use VLC video snapshots.

Load your master into VLC. Cue to a specific time code. Play a sequence of video snapshot (SHIFT+S on windows) and 'E'' keyboard actions. These will create a decoded still image sequence of a few consecutive frames at source resolution. This will work both for your master, and the DCP MXF. VLC video snapshots are taken at source resolution, no filtering applied, and if you use a lossless format like PNG or TIFF, it will not introduce secondary artefacts. Also the inverse X'Y'Z' -> sRGB transformation of VLC is quite okay.

Then start pixel peeping. I usually load a short sequence of these stills into e.g. Quicktime Player as an image sequence, so I can quickly play them at source frame rate, and zoomed to the pixel level, and also judge the motion aspect of the artefact.

It doesn't solve the issue, but I gives some insight.

That said - with some filtering/antialiasing and higher bitrates applied, I never noticed the issue from this older thread on our cinema screen, I could only see it pixel-peeping on my monitor. I can try to convert your sample and check it on our 4k projector.

[Carsten]

Okay, I just took a quick look - while that dress certainly carries a lot of saturation, I don't think this is a special JPEG2000 issue as the one I mentioned above in this case. At first, just watching it 1:1, I couldn't see any issue. Then I noticed that in some parts of the image, there is some moving moire artefact. And I think the problem is indeed a coincidence of the dress fabric and a camera image that is too sharp. Of course, the compression will mess around with these structures as well, but mostly, I think it has to do with debayering, sharpening, saturation, etc.
There is also a lot of noise visible in that magenta dress, and I also think that JPEG2000 has trouble rendering that at lower bitrates like 100MBit/s.
I guess I would try to create a moving mask for that dress and apply some decent filtering to it. Does that dress appear more often in that feature?

[freezer]

Thanks for having a look and advice, Carsten!

I have now reworked all 4 scenes in the grading suite, HSL qualifier was my friend.
And I created the latest DCP with a bitrate of 150 Mbit.
So far everything looks nice - just a very faint dancing noise in some areas, but nothing the audience would ever notice.

[Carsten]

The amount of noise and moire in that dress color is weird. Probably a combination of that specific color (the complete absence of green bayer sensor signal) and the fabric. Wondering how that looks in the source 4k.

- Carsten

[freezer]

On Thursday I'll get the chance to preview the new DCP in one of the Diesel Kinos near Graz on a 4k projector.
I am optimistic it will turn out great now

[freezer]

OK, lesson learned. Do not web transfer the whole DCP as one ZIP file (via filemail service).
I use ZIP normally only as a fallback solution when I know nothing about the receiving person and their technical abilities, because it is more likely to work out for them than RAR (most non-technical persons do know ZIP but have never heard of RAR).

The cinema did have troubles to download it at once through the browser (they didn't know about the filemail app) and then could not unzip the file (probably a transfer error during download - although I have downloaded dozens of TB over the years without ever encountering a transfer error).

So I am using now WinRAR 6 to create RAR5 10GB parts with recovery data and Blake2 hash checksum.

The cinema got from us a USB stick now and is ingesting the DCP, but this takes too much time for today, so we had to reschedule the screening for tomorrow. Keeping my fingers crossed that now everything goes well.

Carsten, the cinema told me they could not read the USB stick on the projector system (although they say it is a very new one). The stick is a USB3.2 256GB SanDisk Extreme Pro, NTFS formatted. They were able to read it on the Dolby library system and will then have to transfer the DCP via their network.

I am a little surprised this still seems to be a non-smooth process despite them having a very new projector system (got no information which one that is, unfortunately).

EDIT 1:
The Dolby library system throws a verification error after validating the DCP...
I am beginning to think that this project has been cursed...
The cinema now tries to ingest the DCP into another projector system where the USB stick can be read. Cudos to them for still trying to help!