White balance auto-adjusted half way through recording Unbeknownst to me at the time, the camera I was using to record a talking head (so fixed environment and lighting) seems to have drastically altered its colour temperature part-way through recording. I put my hand in front of the lens at one point, and as well as refocusing to the hand (thankfully temporarily) the camera appears to have shunted everything toward blue from that point on. The talking head goes from warm and 'naturally skin-coloured' to beyond pallid.

It was recording to an Atomos Ninja in ProRes 422 HD, which I understand 'bakes' white balance directly into the recorded data as opposed to storing it as metadata like RAW.

Q1: Am I correct here, or is it actually possible to retrieve per-frame colour balance settings from a ProRes .mov file? If so, this would be my preferred option as I can then 'objectively' reverse it. I've tinkered with ffprobe but it doesn't yield anything useful-looking.

Q2: If I am correct that the colour shift exists in the video data itself, what's the best post-recording correction method? Working in my favour is a) the background never changes so before/after can be compared on a per-pixel basis, and b) The shift occurs at a single time, with the colour stable before and after. So only one correction need be applied, and I know when.

I'm using MATLAB (this is computer-vision related), which at first glance offers white point, grey world, and PCA-based correction.

For visualisation here's two frames from before and after the camera auto-corrected, with pixels plotted in RGB space. Right now I'm thinking of computing some rigid transform in RGB space to overlap one with the other, but this question is asking whether there's a more 'standard' solution.
A1: Links like these mention that ProRes 'bakes in' the white balance (as opposed to storing it as separate metadata): blackmagicdesign.com forum ; reduser.net forum ; reduser.net forum ; cinematography.com forum ; bmcuser.com archive

(I am surprised this is not more obviously stated on the web anywhere - it seems to be assumed knowledge)

A2: I did end up computing the least-squares solution that brings the 'bad' pixels over to the 'good' ones in RGB space. This gave me a 3x3 transformation matrix that could be applied to each pixel of the bad frames. After this their colour looked very much like that of the good frames.

In MATLAB this is as simple as reshaping one's image matrices into long 3xN lists of pixels (A = the bad frames, B = the good frames) and computing M = B/A, i.e. solving MA=B for M.