artefacts in plain colour

Anything and everything to do with DCP-o-matic.
Carsten
Posts: 2664
Joined: Tue Apr 15, 2014 9:11 pm
Location: Germany

Re: artefacts in plain colour

Post by Carsten »

Hmm. Interesting thing, that's the reason I spend time on forums, you often learn something new. :idea:

Now, I have not yet screened my tests at our cinema to find out how much of these artifacts can actually be noticed visually.

But I did some tests in order to find out why the blotching appears in the white and red. I tried to reduce saturation and contrast, e.g. lifted blacks vom 0 to 5 and reduced white and reds from 255 to 250. But no change. Also changed color conversion (though I didn't expect that to make a difference, and it didn't). I also created a DCP with FinalDCP (completely different J2C encoder - Kakadu) - no real change.

I also created still tests using the standard JPEG and Apple JPEG2000 codec - and the blotching appears with them more or less the same, so, even when I'm not using DCP-o-matic or FinalDCP.

But I finally found out what causes the blotching - it's the edges. Yes, they do have some antialiasing applied in your source footage, but simply not enough. I used a still image and created a version with a 0.5pixel and a 1pixel Gaussian blur, and the blotching was immediately reduced. So, you need to apply some more unsharpening to your source footage. The result is immediately visible in the histogram after the J2C decompression.
Increasing data rate towards 250MBit/s also helps somewhat. I even created a 800MBit/s version ;-)

It shouldn't be a surprise, as most common transform codings have their issues with high frequency content/signal edges. I was mislead in this case initially because blotching was visible in larger constant color areas, and not just the usual ringing around the edges. But it seems that's the way it works.

- Carsten
Last edited by Carsten on Fri Mar 11, 2016 12:28 pm, edited 2 times in total.
Carsten
Posts: 2664
Joined: Tue Apr 15, 2014 9:11 pm
Location: Germany

Re: artefacts in plain colour

Post by Carsten »

Gerhard - I think you are safe. I screened all my tests this afternoon in our cinema on our Sony. The yellow blotching becomes visible below 100MBit/s (I tested down to 40MBit/s). I also checked various levels of softening. There should be a sweet spot above 200MBit/s and with a minimum of filtering. I did a test with a 0.5 and 1pix gaussian blur with a still, the switch from 0.5pix to 1pix was visible close to the screen. I also converted your test-clip using Quicktime PlayerPro and added the softening filter at level 4 - that was already too much loss of detail. So, I suggest, export your footage from QT-Player Pro with a level of 1 or 2 for softening, and use 250MBit/s rate. Use animation codec at highest quality setting, original resolution, 24fps. You will lose nothing through that recompression, except for the slight edge filtering.

Your footage will not even come close to that 250MBit/s rate effectively (very few footage really hits the upper margin).

BTW - I also checked the audio, as you are only using L/R, I think you can boost the level by another overall 6dB (peak is at -8.2dB at 0dB gain) . I don't know about the levels in the rest of your animation, but I think it can sure have a bit more punch. I verified against our usual cinema level.

The imagery is striking, so should be the audio. 8-) Too bad it is not multichannel, those percussion sounds could be used very nicely in the surrounds...

- Carsten