Originally Posted by madshi
This is technically not possible. You seem to lack the technical background knowledge, I'm sorry to say, and you're not listening to me, either. As I've told you before, xvYCC does not exist of a "core" and an "extension". It's not possible to only decode the BT.709 information and skip the xvYCC information. Any and every decoder out there will always output the full xvYCC information (or clip it, introducing hue shifts), and it will seem to be like any other BT.709 Blu-Ray video stream to the Blu-Ray player, although it isn't. Practically, if "Mastered in 4K" Blu-Rays are really using xvYCC, then every Blu-Ray player which doesn't know what xvYCC is will still send xvYCC information to the display. Only it will not be marked as such. And this will result in bad clipping and shifted hues. At least that is my understanding. I could be wrong, but I do understand these things better than the majority of AVSForum users.
I'm not overcomplicating anything. I'm just giving you the facts straight.
If the source isn't compatible, it will still send the data to the display. It will be the full xvYCC data, but it will be "disguised" as simple BT.709 data because the source will not know that it's xvYCC.
We don't know yet which gamut 4K Blu-Ray will use. It's not unlikely that it will be BT.2020. It could also be DCI. Or something completely different. I don't think it will be BT.709. It seems that the EBU is going to use BT.2020 for broadcasting, though. The end result might be that there might be different 4K sources using different gamuts. That will make things "interesting" because if the gamut for broadcasting differs from the gamut for 4K Blu-Ray then how will the display know which gamut the source device is sending? It is quite possible that xvYCC could be used as a general communication platform for 4K, and that both BT.2020 and DCI will be transported as xvYCC to the display. But these are questions I can't answer today.
, unlike BT.709 and BT.2020, DCI does not have a color decoding matrix, because DCI is always RGB and never YCbCr, I think. But HDMI 2.0 doesn't have enough bandwidth to do 10bit RGB at 4Kp60. So if they use DCI, they will have to either invent a new color decoding matrix for YCbCr <-> RGB conversion, or they will have to encode as RGB and convert to another gamut in the source device before outputting the data via HDMI. That might be an argument for using xvYCC as the communication platform between 4K source devices and displays. We'll have to wait and see...
First of all I know who you are and how knowledgeable you are. Like most here, I am very grateful for your contribution to this forum (and to the wider community through your work), and usally agree with most of what you are saying. While I don't post much most of the time, I do read these forums regularly.
There is absolutely no question that you are more knowledgeable in this subject in general than most AVS Forum users, including me:).
However, you started by saying that you weren't sure, and didn't know for sure. Hence why I'm not taking for granted your suppositions regarding xvycc, even if they are more likely to be true than mine:).
Second, I linked to quite a few precise quotes either from the wiki or from users you accepted seemed to know what they were talking about (KMO), and they ALL point to the fact that:
1) xvycc content cannot be sent to a display that doesn't explicitly support the extension
2) this is part of the HDMI 1.3 specs. The specs have been changed specifically for this.
I am listening, and I am absolutely ready to accept that I am wrong, and that I am totally misunderstanding, and that I've misread all these quotes, but could you please provide a link from a source that clearly explains why?
While I'm far from having your technical understanding of these issues, I'm not a complete beginner either. I do calibrate displays in an extensive and advanced way, I do master a variety of material using various compression codecs (I work in the film industry) so I'm not the entire noobie you seem to believe I am.
If we put this point aside, what you say in the second part of your last post is very interesting indeed. I had no idea that you could use xvycc as a transport mechanism for other gamuts. This would make it even more interesting, and potentially would make the absence of rec2020 support in the vw500es less of a sore point.
The UHDTV standard is already set to rec2020, so obviously it would make much more sense to chose the same gamut for bluray 4K and other sources. But just like you have to select the correct gamut (smpte-c for NTSC or bt.601 for PAL) when you insert a DVD, or even the correct gamut (smpte-c or rec-709 depending on how they were mastered) when you insert a bluray, it wouldn't be either unprecedented or the end of the world if we had to select the correct gamut depending on the UHD source we are playing.
What I find interesting, again, is not xvycc in itself, but the fact that provided the source is xvycc aware, it could offer a mechanism to provide backward compatibility with rec 709 displays.
If I read you last post correctly, you seem to not only agree with me on that point, but also suggest that we could have our cake and eat it, ie not only have the backward compatibility, but also the more interesting gamut (rec2020) instead of the xvycc gamut, for which I have no particular liking in itself (except if projectors like the vw500es or the new JVCs could miraculously support it).
Indeed, the main reason why this question is on topic in this thread is to assess whether 1) the vw500ES stands any chance to be compatible with the upcoming bluray 4K standard and 2) if it isn't fully compatible because it lacks support for the wider gamut, could we still take advantage of all the benefits from the new 4K bluray standard (color depth. better compression, increased pixel resolution, less chroma subsampling), bar the wider gamut. This would be not only good news for the VW500Es but also for all the other "stop gap" projectors that have arrived this year, although the lack of HDCP 2.2 might be fatal in their case.
Again, as I said earlier, I have no idea where xvycc falls between rec709 and rec2020. If it is smaller than rec2020, maybe it will make it easier for more displays to support it?
To clarify, I have no agenda here, except the pursuit of knowledge.
I started this day being a friend and a fan of yours, I'm hoping to end it the same way:).