iterations count as a function of zoom and location?

[makc]

I have logged six random click-to-zoom sessions and plotted minimum iterations in the window (of the constant size). The result basically says that the function depends on location - what a surprise - and does so very "chaotically", e.g. red graph shows dramatic iterations slow-down where I suddenly went clicking sideways from original spot while already zoomed in a lot...

Any way, I came to conclusion that I can't really come up with useful approximation for this function from the graph, and that it's "ask the expert" time - so do you people know if such a function, or similar to it, was ever found, or is this still up to manual tweaking / guesswork?

p.s. I must add I did find a sort of "upper bound", i.e. max iterations it takes to avoid images like this. It is somewhere between log(zoom)^3 and log(zoom)^4, because I have seen under-iterated minibrots using former and never using latter. But minimum iterations do not seem to have any "lower bound" of that kind at all, so location has to be taken into account in some way, if one wants to estimate it.

[cKleinhuis]

hi there, i have not implemented such a function, i cant give you any hint right now for guessing a reasonable maxIter for
getting the optimal iteration when close to interesting area, it is harder than one might think and i guess to common fractal
programm writers have struggled with it as well

considerations:
- i think the distance estimator might come in handy here but i can not give you a hint on how to use it, the distance estimator basically measures the distance of the "iteration bands" the closer they are to eachother, the more iterations you need, hmm, but i guess finding a point that is NOT in the set
brings you down to a point finding where the change from inside/outside happens, a point close to this border - within/rounded pixel screen resolution - the estimated distance could give you a hint how to set this value

any other comments about this ?!

[makc]

re distance estimator, indeed you could track minimum achieved distance in the frame and, if that goes above some threshold, you know you should increase iterations. however, this actually defeats the purpose, since de is computationally expensive in itself and requires higher bailout values.

[panzerboy]

You talk of a graph, which suggests you are keeping a count of the numbers of pixels for each iteration count.
When your maximum iteration level has more than say 40 pixels (or any arbitary number based on resolution) increase the maximum iterations.
If that new maximum has more than 40 pixels, increase again perhaps by a larger, amount say twice the previous increase, and so on.

[cKleinhuis]

@panzerboy the problem here is that some points are definately always "in" so, with your suggested method you would just produce an endless loop
 
better use the "maxIteration-1" value to compare against

[makc]

You guys keep talking about maximum iteration cuont as if it was a problem to find the value that always works But, again,

...I did find a sort of "upper bound", i.e. max iterations it takes to avoid images like this. It is somewhere between log(zoom)^3 and log(zoom)^4, because I have seen under-iterated minibrots using former and never using latter.

If it turns out there is underiterated minibrot somewhere really deep with log(zoom)^4 you could just change to log(zoom)^5 or even something completely different - the point is, no matter what location, you can always find max iterations that will be sufficient for all of them (even if it will be overkill for most of locations).

My initial question, however, was about minimum iterations that you need for all the pixels in certain range around certain location. The only reason I would need it for is to look up the colors directly inside the loop; otherwise I would need to store iterations, check perimeter after the frame is done, and then use that found value to color everything. Yes, I know you could just make color from iteration number, but in this case I need to ensure color range... but whatever, this is not show stopper, I can do 2 passes just fine. Just thought that maybe there is some obscure paper that has some unknown formula that they do not put on wikipedia.