Originally Posted by bobof
If you pause the content during the yellowing, does the content remain on screen in yellow, or does it become white - ie is it that the colour shift is the "end result", or a transitory state shifted through as the DI and gamma are adjusted together? And if you at that point disable the DI, and then re-enable it, does the text go back to yellow or remain white?
If it remains on screen in yellow (ie this is a result, and not a transitory state), I'd be tempted to analyse that text using diffuser mode on the Discus to quantify exactly what the magnitude of the shift is. I'd then use the TPG in madvr in various patch sizes and stimulus levels to see at which point the grey axis shifts in this way.
The tighter you can define the test case the better progress will be. Once you have a static test (assuming there is a static test for this) it becomes much easier to figure out what is going on.
Of course if the yellow only exists as a transitory state, and not with static images, things are much more difficult.
I don't really care about the text, there are variations there but not as offensive as on real content.
The gamma shift always goes away if you disable the DI. For example, if you pause on any gamma artifact and open the menu, the iris opens up to the manual iris position, and there is neven any artifact in the picture itself. It is always caused by gamma manipulation that is not part of the picture itself. The blooming is usually worse when the DI opens, but you can see it when the DI stays in a fixed position, it's then just the gamma manipulation causing this. Part of this issue existing on older models. For example the gamma manipulation artifact can be seen on the e**** models using MI:Fall Out at 00:05:57. The car headlights are turned inot a poorly defined blob of white/yellow and the highlights are clipped. This happens even if the iris position isn't moving. It stays if you pause, but if goes away if you open the menu/disable the DI.
I honestly don't have the time to analyse further what is causing this. I'm trying to get a few users listing precisely the source, colorspace, colorimetry, HDR/SDR, bit depth and calibration used (gamut, gamma, manual iris setting) when they observe the issue, which no one has done yet.
Once we have more data, hopefully we'll be able to see a pattern. If we don't, then yes we might have to dig further into what exactly triggers this, but ideally I'd let JVC do this. If we can tell them "set a XBOX like this, play Lucy at 00:01:30 to reproduce", then hopefully they reproduce and fix. But if they can't reproduce, and it looks like if they use a standalone UHD Bluray player they can't, well then it's not going to be easy to resolve. I'd rather be able to list a mainstream source such as a XBOX rather than a HTPC because the combinations of OS, GPU, drivers, settings, players is just too much to ask JVC to match. Again it's not HTPC or madVR specific. An HTPC with madVR doesn't show the issue if you set HDR to passthrough for example. And it's not about the tonemapping itself, because as I understand it the XBOX doesn't tonemap and sends HDR to the PJ.
But until we get the exact info requested, we are not making any progress. I was hoping it would be easy to get a few reports from users, but it doesn't seem to be the case. Maybe we'll have to create a separate thread to not clutter the owner's thread with this issue.
Many people are not seeing any problem either because it's not there, or because it doesn't bother them, or because the manual iris is low enough to minimize the issue when the DI is enabled.
I don't want this to be blown out of proportion. If it's present and you see it, it can be offensive, but it doesn't take away the quality of the picture and even with the DI disabled, the contrast is excellent.