Feedback from a video expert:

[It is possible to] convert everything to XYZ and return Y. This is well-founded but always requires accessing UV data (and knowing the source color space).

There isn't anything truly consistent we can do with just Y/Y'. That said, a supermajority of (current) content is in formats that have a plane that is at least called Y', so it may be acceptable to just ignore (or reject) other things. In this sense you can straightforwardly get Y' from a supermajority of decoded data.

If we accepted this pull request, and we realized in the future we wanted a more rigorous notion of luminance, how would we accomplish this in the future?

Resolution:

• Still think this is useful
• Don't define the color space strictly, better to define it so a UV plane never has to be sampled

IMO: Likely luma (nonlinear) rather than luminance (linear), to avoid gamma conversion. TBD

If we accepted this pull request, and we realized in the future we wanted a more rigorous notion of luminance, how would we accomplish this in the future?

A new function like textureLoadLuminancePrecise?

A textureLoadLuminancePrecise would need to load all planes anyway, in many cases. So it only makes sense if the user can specify their destination Y axis (based on their video source metadata) in such a way that the impl will still end up on the fast path. I'm optimistic this might be doable but not sufficiently informed.

An alternative would be to provide a luminance value and metadata telling them what it means. (Could be either provided at the API level, or returned by the WGSL function.) IMO this seems better suited for a WebCodecs path.

Discussed again. Conclusion this time was we think this can be punted to post-MVP. In the meantime we can experiment to determine how much performance can actually be gained.