hue function loses precision too quickly

[jmil]

I'm trying to create an animation where the palette hue "rotates" through. I've noticed that with the current logic of the hue function, a 36-step rotation (a hue(10) call) causes the rgb value to differ by as much as 5% between the start and end frame. I'm not sure if the rounding errors are coming from the value normalization or the hue normalization.

To see what I'm talking about, I have attached a script. It demonstrates the error. Just use it with any flame. Pay attention to the first and last hue values, as they should be equivalent but aren't and that results in the RGB values being wrong and the palette slowly goes to crap.

[jmil (john-jj-miller)]

I played more with it, and it seems that to keep the precision the palette would need to be stored in both rgb and hsv mode. I've made a workaround script for animating, but it's a problem that will manifest if someone adjust the hue of a palette too many times.

[Vitor Bosshard (algorias)]

Yes, we'd have to keep the info in both formats, but how would we write that to disk? it would only introduce more problems than it solves. The GUI has a workaround for this too: it keeps a copy of the original palette around and applies the accumulated hue shift from there in 1 single step if the hue is modified several times in succession.

I assume you're using the same workaround for your script.