Using KF to compare renderings with SFT hacks

[3dickulus]

the glitch detection goes like this...

stage 1 reference = 0,0, flagging pixels as fail with if( fabs((c+dx)/dx) > 1E6 ||  fabs((ci+dxi)/dxi) > 1E6 )
stage 2 hunt for a blob and estimate locus, set as second reference, recalculate flagged pixels
stage 3 try to find the highest iteration location from the pixels that are left, set as third reference, recalculate flagged pixels

each reference uses the last one to pick the next one ? something like that.

as for comparisons KF is a much better program.

[Kalles Fraktaler]

Yes that is indeed Pauldelbrot's glitch detection!
Edit: That is similar to Pauldelbrot's glitch detection, but I cannot estimate what difference it makes by not squaring and adding the real and imaginary parts. Perhaps your method is faster and works, perhaps not.
KF is only repeating stage 2 until no more pixels are flagged as glitches

But you have showed one good and obvious point! One of the KFB files in your zip have maximum iterations on about 100,000 but the highest iteration in the result is some 10,000. So the reference calculation takes really unnecessary long time and I will make an update on that (+rotation!)

[3dickulus]

I also use (x-y)*(x+y) instead of (x*x)-(y*y) , only one mul

the max_iteration in at least one test is 25000 vs 2800000 but I think these were picked as upper limit by the programs themselves as the required max for that location. I will look at this and try to balance the counts for a better comparison,

over limit = bailout, so I think a few more than required is a normal thing?

I use KF for comparing because it's good and I trust that it renders correctly, I really don't like java so if a prog has a prerequisite of JRE and won't run without that monster then I'm not interested. Just a personal preference

[3dickulus]

But you have showed one good and obvious point! One of the KFB files in your zip have maximum iterations on about 100,000 but the highest iteration in the result is some 10,000. So the reference calculation takes really unnecessary long time and I will make an update on that (+rotation!)

just tested that and it makes a big difference, in both programs, I will definitely check all files for calculated vs preset and redo all tests with = iteration counts.

when zooming-in the iteration limit is increased but it is never decreased when zooming out (SFTC), I think KF does too? I will have to be careful not to muck about causing the program to calculate a new limit before a test render.

[Kalles Fraktaler]

just tested that and it makes a big difference, in both programs, I will definitely check all files for calculated vs preset and redo all tests with = iteration counts.

when zooming-in the iteration limit is increased but it is never decreased when zooming out (SFTC), I think KF does too? I will have to be careful not to muck about causing the program to calculate a new limit before a test render.

What I meant was that it probably doesn't make much sense to calculate the reference far beyond when it has reached bailout, because beyond that it just produce large useless numbers. But I need to test that carefully.
So you have made a very good tip for improvement! The reference iteration count should be slimmed.

[claude]

The reference iteration count should be slimmed.

What I do in mightymandel[1] is to compute the reference in parallel with the pixel iterations, interleaved in blocks - so I compute the next N reference values, then step all the pixels N iterations, and repeat.  This way I don't need to guess how many iterations of the reference might be needed in advance, and I don't have to store the whole reference orbit in memory at once.

[1] https://gitorious.org/maximus/mightymandel (specifically https://gitorious.org/maximus/mightymandel/source/HEAD:src/fpxx_step.c#L106 )
[1] http://code.mathr.co.uk/mightymandel (specifically http://code.mathr.co.uk/mightymandel/blob/HEAD:/src/fpxx_step.c#l108 )

[Kalles Fraktaler]

What I do in mightymandel[1] is to compute the reference in parallel with the pixel iterations, interleaved in blocks - so I compute the next N reference values, then step all the pixels N iterations, and repeat.  This way I don't need to guess how many iterations of the reference might be needed in advance, and I don't have to store the whole reference orbit in memory at once.

[1] https://gitorious.org/maximus/mightymandel (specifically https://gitorious.org/maximus/mightymandel/source/HEAD:src/fpxx_step.c#L106 )

Cool. Can we download the executable?

[claude]

Cool. Can we download the executable?

Sorry no, just source (I work on Linux).  I could switch out the gtkglext dependency and revert to GLUT to make it easier to compile on other platforms, if there is demand, but it's more a proof of concept / toy than a fully featured explorer at this stage.

[3dickulus]

What I do in mightymandel[1] is to compute the reference in parallel with the pixel iterations

is that as a result of the way GLSL works? or part of the plan by design?

I've been following some of your work (mighty mandel, mandelbrot-delta-cl), fascinating GLSL code.
Recursive/iterative stuff on the GPU using higher precision math has been slower than expected in my tinkering.

[claude]

is that as a result of the way GLSL works? or part of the plan by design?

It sort of falls out naturally from the computation of pixels all at once in parallel, combined with having to iterate in blocks to avoid the GPU driver taking too long for a given operation and blocking the OS.

[3dickulus]

EDIT: oops misunderstood which re/im parts you were referring to, you meant in the glitch detect test, a little faster?

, but I cannot estimate what difference it makes by not squaring and adding the real and imaginary parts

It works, gives the same answer, algebraically the same, saves one mul and reduces influence of cancelation when the numbers are very small (better accuracy)
when you are doing a few million loops it makes a noticeable difference.

It sort of falls out naturally from the computation of pixels all at once in parallel, combined with having to iterate in blocks to avoid the GPU driver taking too long for a given operation and blocking the OS.

I did one version of cudabrot that setup a screen sized array for each variable then applied the M formula in one go but it sucked up a LOT of ram and wasn't really any faster, but that was with no perturb or series approx, just straight iteration to max.
 

[3dickulus]

What I meant was that it probably doesn't make much sense to calculate the reference far beyond when it has reached bailout, because beyond that it just produce large useless numbers. But I need to test that carefully.
So you have made a very good tip for improvement! The reference iteration count should be slimmed.

So, calculate reference until x*x+y*y > 4.0  and not all the way to iter_limit?

I note that in the SFTC reference calculation there are 3 break points in the "while (count < mIteration_limit-1)" loop, but they don't look like the escape test, more like precision/accuracy tests.

how might this be done? is it as simple as the x*x+y*y > 4.0 test ?

[3dickulus]

The results are in

                      Comp-1          Comp-2          Comp-3          Comp-4          Comp-5          Comp-6
                     ---------------------------------------------------------------------------------------------------------
KF-2.5.6        05:02.014       00:52.587       06:31.486       04:43.667       02:15.123       06:07.371
KF-2.5.7        02:54.307       00:46.515       05:44.356       05:13.242       01:34.398       08:24.681
SFTC60         00:36.271       00:35.003       00:35.615       00:49.739       00:56.081       00:41.309

At the Polished Emerald location

                 zoom @E355         SFTC falls down @E405 can't zoom any more at this location
                 ---------------------------------
KF-2.5.6   00:00.863      00:26.193
KF-2.5.7   00:04.068     00:19.022
SFTC60    00:11.752     00:50.658

At Kalles Julia Morph location

                zoom@e500  zoom@e604
-----------------------------------------------
KF-2.5.6   00:29.960     06:58.014
KF-2.5.7   00:30.789     06:26.530
SFTC60    00:18.878     06:06.897

took a hit at the polished emerald location but over all performance is up

[Kalles Fraktaler]

I hope your honeymoon was great!
I have also done that (twice... )

The thing you are measuring is how clever the programs are to add additional references.
But does your program add more than 2 extra references? I don't think that sufficient to solve all glitches in all locations?

I realized that 2.5.6 did not add the references where it was intended. Sometimes that was a good thing and less references needed to be added, sometimes not and more references needed to be added. For example glitch blobs occurring after a close passage of a Minibrot's elephant wally have a spiral inside, and the center of that spiral is close to the edge of the blob and not the center.

[3dickulus]

Thanks very much Harrison Hot Springs Resort was really nice, soaking in the lap of luxury, oooo, ahhhh, but I only want to do that once 
...the honeymoon is over,  back to fractals

just 3 refs, yes, some images need more and in many cases it looks great until you pan or zoom, my method is not very good and needs work, but the engine is running and pulling hard towards a GPU version. I will rethink my approach to glitch solving, a.t.m. no manual selection or turning detection off/on and no re-use ref option, it should be automatic though, because having to make/save solutions manually for 100s of frames in the 1000s that make up a movie is too laborious, when it has been demonstrated (kf) that the machine can do it.

should impliment this way ?
------------------------------------------------------------------
using Grid method first ref @0,0
scan X for largest width blob in at least 3 places, 1/4 Y 1/2 Y and 3/4 Y
scan Y between min blobX and max blobX for largest height
x1,y1,x2,y2 == blob bounding box opposing corners
if circular (x2-x1 == y2-y1) use center else if peanut (x2-x1 != y2-y1) estimate locus with golden ratio logic
if no blob is found then use the location encountered with highest iteration value

second ref @estX,estY
render image

if glitchPixels != 0 scan again using "attract to highest" method
render only pixels

if glitchPixels != 0 repeat with higher precision?
------------------------------------------------------------------
that's not the way it works in SFTC but heading that way, I would also like to try (again) handing glitch pixels off to an arbitrary precision routine when they are encountered at the approximation stage, so far it hasn't worked well, I think because by the time a glitch pixel is detected the precision has already been lost... hack hack hack like when a location is < re-11 or ie-11 SFTC falls down, needs your custom fixed point type or I need to figure out how to use ArPrec's fixed point features and when to enable them