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

perhaps this will illustrate my "hunt and peck" reference selection, a picture is worth a thousand words
the straight lines are from ref@0,0 estimating a ref point in the blob (not where they meet but a ratio of the h/w) corrects the blobs
the spiral path is route taken by the "attract to highest" routine selecting the third ref at the end of the path, corrects the antlers

coords...

edit: at the end of the spiral path you can see it kind of bunch up, that's where there is a tight group of the highest iter antlers so it catches all of them and not just one or two outer levels

I mentioned earlier that SFTC has no special provision for locations close to 0.0 like this with i@nE-22 so... I'll give it a try anyways...

26.12 seconds  

edit:KF 12.5 seconds I'm surprised that SFTC rendered that location at all, a little rough, approaching limits.

I really don't know, maybe it's just 3 refs instead of 70 not as much approximation data so more iterating?
and the math is only what was in the original SFT Java code, no extra approximation or additional terms.
ArPrec lib uses fft and a modified Taylor series internally to speed up operations

The straight lines represent the pixels tested when doing an initial search for a blob after generating the first reference @0,0 testing for a group of failed pixels larger than 20.
Plotted them only for illustrative purposes, they serve no function other than a visual aid so I can tell what's going on.
The spirals are the same thing but for the search after generating the second ref from a point in the blob.

On the second pass, after rendering an image from the first (blob) reference you can check in the rendered data instead of calculating the iterations for points when testing for more blobs, but SFTC currently is calculating iterations and looking for the highest location on the second pass when looking for the third ref.

edit: I find it rather amusing that we think of 26 seconds as a long time to render an M set image @E79

if glitches are one pixel they will be very likely to get lost in jpeg or mpeg compression, this is why I am not getting too picky about single pixels and concentrating on the larger areas, it seems that when you nail the big ones a lot of the small ones get covered by the new reference.

in the stage 1,2,3 pics, (page 2) the antlers look messy, it's the palette, light bands next to dark bands in a tight pattern, looks better with an adjustment to color spread, the two clips are from the same iteration data.