I think this is pretty much predictable and will always crop up somewhere.
Imagine you have an RGB color like 100,90,0 - a yellow hue. If you scale it down by a factor of 10, you get 10,9,0 - perfect proportions, and identical hue. But if you scale it down by a factor of 20, your ideal result would be 5,4.5,0 - again with the color proportions unchanged. But the pixels themselves only operate on integer values, so what you get is 5,4(rounded down),0. Now the color proportions aren’t quite right, but maybe it’s the best integer match possible.
But go further: if we scale 100,90,0 down by a factor of (let’s say) one hundred, the ideal result you want would be 1.00,0.90,0. And again, since the output can only be integers, you get 1(.00),0(.90),0 aka 1,0,0. But soft, what light through yonder window breaks our approximation?! It is the integers, and 1,0,0 is RED, not yellow at all. This is what you’re seeing in the video. Yellow fades to dim yellow, to dimmest yellow, to red.
Now that I think about this though, oddly, we already know how to prevent this: use the “{blah}_video” variations of scaling functions instead of “{blah}_raw” to scale down the color channel values. Functions like scale8_video make sure never to round a non-zero channel value down to zero. They exist for exactly this reason.
I’ll see if I can see where in the data path we’re not using it; maybe we can improve things a bit.
