Animation rendering bug

Rendering animations to png image sequence usually has several unfinished images. This also happens often when just editing a fractal. Refreshing zoom then gets rid of it.
Typical example included.

This is a very long-standing bug in Ultra Fractal that I've never been able to reliably reproduce. Until a few weeks ago. I noticed that if you render a very quick animation, there will always be a frame or two with this problem, so that enabled me to zoom in on the problem so to speak. Approaching it this way, I've been able to finally fix it. There will be a 6.03 release with this bug fix later this year.

Thanks!
(That was too short to post.)

Is 6.03 still coming out? This animation bug is a bit of a show stopper.

Yes, still working on other stuff that I want to put in this update... As a workaround, you can reduce the min/max threads settings in the Fractal tab of the Preferences dialog. This will make things slower (because less parallel processing is going on), but also less likely to go wrong.

I'm not a believer in the "Release early, release often" strategy, and mostly prefer sparsed and well tested releases. But in this case a known bug of this type, solved many months ago, deserves, in my humble opinion, an update release even if no other bugs are patched.

It looks like a punishment to the app's best customers, those paying for the animation capabilities.

You are right. What kept me from releasing the fix earlier is that there are also other things in the upcoming 6.03 release that I want to get right -- I'm moving to the latest development tools on Mac that require a lot of changes to keep everything working. I'm also currently finishing full support for Dark Mode on Mac. This particular bug has been in Ultra Fractal since forever so I assumed that it wasn't hurting many people. What's happening though is that systems with many cores are far more common now than before, so people are hitting the bug more often. So I could have released a 6.03 version with this fix only but it didn't seem urgent enough for that. I'm working towards a release now.

Yes, still working on other stuff that I want to put in this update... As a workaround, you can reduce the min/max threads settings in the Fractal tab of the Preferences dialog. This will make things slower (because less parallel processing is going on), but also less likely to go wrong.

No problem here, a workaround seems to be to increase framerate to something like 120Hz.

Not a bug fix of course, but a feature I would like more than anything else is a way to declare additional variables (e.g., the derivative dz/dc or dz/dz0 or both or more) in the fractal formula to be made visible in the coloring formula.

I definitely see how that could be useful, but you're also tying the fractal formula to the coloring algorithm in that way, so they're not universally exchangeable anymore. What you could also do, is put the entire formula and coloring system in the coloring algorithm, and use the Pixel fractal formula to basically bypass that fractal formula.

Well, the only universally exchangeable coloring is some orbit trap.

Doing everything in the UCL is of course possible but quite horrible. All the formula and coloring controls would be mixed up and appearing in the wrong place. Yikes!

I have 2 generic (pretty universal) distance estimation coloring UCL files needing #z as well as its derivative. The hack is in the formula file after the loop terminates I stuff |z| and |z'| in z and the UCL file then unpacks those from the z variable to make a DE. Other "custom" colorings I deal with in the same way.

Coloring based on 3 parameters however is not possible this way, and all has to be done in the UCL.