END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

There is only one list of reference values, main reference or additional reference, and if the reference is to be reused, it is not re-calculated for the next key-frame.
I have never tested to combine these two, but the last additional reference, to solve glitches, would be used for the next key-frame.

For locations that do not pass too close too many deep minibrots, it is enough to use one reference only, no auto glitch solve, and only a few or not at all glitches needs to be solved manually.
But for all locations the key frames are of course much faster rendered with one reference only, and the glitches to be solved manually are fewer than when exploring since such reference is deeper than the rest of the pixels.

And finally, I have made a new version, 2.2.8.
Because I have solved a rare problem that I have seen a few times, which is sometimes impossible to solve in another way.
Here is a glitch that the auto function did not solve, because the smooth coefficients did not have the same colors inside the blob, which is unusual (but maybe related to this problem...)

If a new reference is added in that blob, a new glitch occur, because unfortunately those pixels had the exact same color (i.e. iteration count value) as the blob, but those pixels were correctly rendered at the first time, and got incorrect with the new reference:

The nasty thing with this particular new glitch is that it is not a blob glitch but a gradient glitch, and many new references would be needed to solve it, causing other areas in the view to become incorrect.
The solution is to cancel the changes, check the "Use near pixel method" check-box, and add the reference in the first blob again. This time only the connected pixels, i.e. the pixels in the blob, are re-rendered, and all other pixels are untouched.

Since these images are only the left corner of the whole frame, the same blob glitch occur 4 times and 4 additional references needed to be added.
Usually only one additional reference is needed to solve all similar glitches on the same view.

I wait for 2.2.10)))

Yeah. A man from youtube wanted to help me improve the movie maker program, which indeed take long time when color cycle and rotation are applied.
His first suggestion was to combine the two tabels iterations (int) and smooth coefficients (float) to one float table.
The reason I had them separated was that I didn't want to risk that the floats would be truncated on my very deep locations. According to Wikipedia a float is only reliable to 6 decimal digits. And unfortunately I was right. So I reverted the KFB file format for now.
But he had also other better suggestions regarding making as narrow jumps as possible in memory to take advantage of CPU memory caching, something I have never considering.
So there will indeed be more versions

That is bad, and hard to replicate for me.

I have never resumed a sequence from only one key-frame so I don't know if it works. I think it uses the last 2 frames to calculate the zoom level, so I hope you have selected 2 already?
3 days for the first frame is a long time on depth e450. The time to render following frames will decrease, but slowly and I think it will take many months to complete the sequence. (My 2-month render took a little more than 1 day on the first frame)

Yes it was.
2 month was also the time for the infinite Julius tree, but I don't remember how long the first frame took.
But if it goes ok now it will indeed be fantastic to see the result of your render!
And you are not afraid of long time render, I know

Cool. You are really driving my program to extremes. And I like it very much, thanks a lot, it is pleasant challenges.

First I just want to say that at all times 6 key-frames are combined in FKMM, which results in that the center of the movie is antialiased with between 32x32 and 16x16.
The images are cached in memory, so your sequence requires 6*7680*4320*16 = 3GB, impossible to allocate for a 32-bit application.

But I would never criticize you and tell you to redo you render.
Instead I have a plan, KFMM should not allocate more than 1920x1080 (or maybe 3840x2160) or in memory and should do the antialiasing calculations.

I need some days to do this though, I hope you can wait?

That is a beautiful image and an amazing movie, with the cracked flakes that EricB inspired us.
So, maybe antialias in KF is more useful than being able to create huge image files then?

Strange that the jpegs get the same, but they aren't necessary anymore, maybe I can discard them in future versions.
Sounds like the bitmaps in KF get corrupted/destroyed, I have seen it a couple of times but it was a while ago now.
It doesn't affect the iterations and smoothing data which are stored separately, but the program doesn't display the content correctly.
What resolution did you use? There is probably a maximum on 3840x2160, at least KFMM cannot handler higher resolution.

And I have discovered that it is not possible to do anti-aliasing (at least with reasonable effort currently) using the iteration count values and smoothing coefficients. It is easy to do anti-aliasing with the resulting RGB values to display images, but to make color cycling movies with various density, the iteration and smooth values are needed.

Next version will have a size limit, and check that reference reuse is not used with auto glitch correction, but currently I am not able to access my page to upload anything (however since my image is displayed, the site is working)