YUV bugs fixed in Max 8? corrupts tint, color, saturation, and brightness
Hi. This is for Cycling74 internal team. Were the series of bugs I reported in 2014 and 2015 on Max's YUV handling fixed with Max 8? Or are these bugs now permanently baked into Max for "legacy compatibility behavior"?
These are the bugs that cause shifts in YUV tint, color, saturation, and brightness due to incorrect and inconsistent implementation of formulas used for YUV manipulation, YUV to/from RGB, and colorspaces.
To date, I've told my customers to avoid YUV on Max due to these bugs. Asking so I can update my recommendations or continue to discourage.
hi Dale, the jit.movie and jit.record objects were updated around 2017 I believe for proper HD color profile support in both video engines. No changes have been made to the jit.*uyvy* matrix objects or built-in shaders.
Got it. I'll continue to advise my customers to avoid uyvy (technically YCbCr) on Max.
Underlying compression formats are usually chroma-based. When jit.movie decompresses and writes the r,g,b components into a jit_matrix...in what colorspace is that jit_matrix with red, green, and blue component pixels? That is...what transform matrix was used to convert the chroma-compressed datastream into an RGB datastream? sRGB, BT.601, BT.709, or BT.2020? These all have different primaries, whitepoints, etc.
Keep in mind (both you and readers) that the BT.709 seen with most HD/bluray videos is the ENcoding matrix and how the compressed datastream is tagged. The DEcoder can DEcode it into any colorspace it wants. That is the "handshake" that typically occurs between a Bluray player and a TV. They agree on the colorspace (often BT.709) and then the Bluray device decodes into BT.709. The same holds for jit.movie. jit.movie is choosing to decode into...something. What is that?
with the viddll engine the YUV decoder colorspace is determined by the ffmpeg frame colorspace member, if present, and will be set to either bt.709 or bt.601, and defaults to bt.601 if not present. with avf engine the handshake happens in the avf internals.
ewww. That means it is inconsistent. The RGB datastreams output by jit.movie change colorspace depending on the source material and sometimes unknown "avf internals" logic. Given that, all the processing in objects/nodes after that can't know how to manipulate RGB datastreams consistently and in high-fidelity.
When I did my research on this in 2014, I realized that Max can't robustly fix this until there is metadata that stamps every jit_matrix with the colorspace of the data it contains. That metadata is needed by all later objects so they know how to apply formulas/matrices. It will be difficult to do this metadata out-of-band because of the unknown logic in parts like "avf internals".
The unrobust fix is to chose a single colorspace for ALL jit_matrix and then to force all decoders/processors/shaders to always output in that single colorspace.
Looking at a competitor, TouchDesigner is also borked https://derivative.ca/UserGuide/SRGB.
I started to write my own Max colorspace fixer object in 2015, but as I got into it didn't see tremendous value for the effort when Max would skew color again on any manipulation including its display with jit.window or jit.pwindow.