- This topic has 7 replies, 2 voices, and was last updated 6 years, 3 months ago by
.
-
Posts
-
Hi I’ve just started playing with calibrating an eecolor. This is the current setup:
AppleTV → eecolor → Sony 46ex720 1080p
I’ve profiled several times with patch sizes from 100 all the way to several thousands and have pretty decent looking results for a eecolor 3D LUT targetting rec 709 gamma 2.2; There were issues with some of the profiles especially in the blue/cyan colors that were very apparent when I would display a grangier rainbow. The last profile with over 10000 patches seemed to finally solve that though and I’m pretty happy with the SDR result. I used the chromecast patch generator to a Nvidia ShieldTV (built in chromecast) for the last few profiles. It seemed to work well enough.
The main issue I’m still having is very noticable banding when trying to create a eecolor HDR-SDR 3D LUT from the same display profiles used in the SDR LUT above. This banding is mostly visible in light shades (clouds etc.) and has a pink tone to it. I’ve tried many different options with the tone curve (2084 roll off & hard clip at varying nits from 200-500), tried playing with the rendering intent settings but they all still show the same banding. I can force the AppleTV to 1080p HDR to view a grangier rainbow and the banding is very obvious in there.
Finally to eliminate my display profile as the issue I tried creating a synthetic display profile with the icc creator (rec 709, white level 100, black level 0.1, gamma 2.2 relative, output offset 70%). The same banding is there when I created a eecolor HDR-SDR 3D LUT with this profile.
I’m new to all of this so I’m not really sure what to try next. I’m very please the SDR 3D LUT has turned out, just feels like I’m missing something for the HDR-SDR 3D LUT.
I attached the eecolor LUT files here.
Please attach the complete set of files (“Create compressed archive…” in DisplayCAL with profile selected).
Thanks, I’ll do that later today. I was wondering though since I had the same result on the HDR-SDR LUT using the synthetic display profile wouldn’t that point to something else causing the banding like some sort of bitdepth issue or how the eecolor LUT is created?
I cannot reproduce the issue (neither using synthetic or actual display profiles), so I need to take a detailed look at your files and settings.
Edit: It would also help to have some test footage that shows the banding.
Here’s the compressed archive, I also attached some screenshots, sorry they’re not great I had to take them with my tablet since my pixel phone seems to add too much post processing and ruins the grainger rainbow image.
The last picture it’s pretty easy to see the pinkish banding / posterization in the clouds. Looks pretty good to me otherwise so I feel like this eecolor HDR method should be promising. This is from my appleTV 4K in 1080p hdr mode 4:2:2 playing a HDR clip through MRMC.
This banding is not introduced by the 3D LUT, it is introduced by the eeColor (this was discussed over at AVSforum at some point). They are quantization artifacts. This happens typically when the input/output bitdepth is 8 bits (the eeColor does not dither).
Thanks for the explanation, it does make sense that it’s a bitdepth issue and not the 3D LUT itself. Can you think of any way around this issue? Maybe it’s related to the AppleTV output? My TV reports 12bit and from what I read the AppleTV outputs HDR in 12bit.
Hi, I’m experimenting again with this eecolor HDR to SDR 3DLUT and have successfully removed the banding by creating the LUT with rec709 as the source colorspace instead of bt2020.
Somehow it seems there were issues going from bt2020. Is there something within Displaycal/Argyl that would be causing this or an internal limitation to the eecolor when it’s fed bt2020 source colorspace?
I attached the working LUT with 709 source colorspace. This is created from the same profile I used in the attachments posted in 2019.
