I have put another update on my web-page, version 2.2.2
It will be the last update for a while now I think, if not an obvious bug is found.
I haven't implemented requested functions like side-scrolling or rotation, the time I have managed to spend on this I've spent only on automatic glitch-solving.
And I have found a promising way of identifying glitches.
The following image is a detail of the location sent by hapf some posts ago.
This image have only one reference, in the center of the image:
One type of glitch is marked with 1, another one with 2 which is probably but not surely the same as 3, these glitches are areas with one color/iteration count, shown as big one-color blobs.
A big area with correctly one color/iteration count is marked with 4.
So how to find that 1, 2 and 3 are glitches but not 4???
The float error detection show nothing in this image.
The iteration count it not good enough either, since the iteration count in 4 is actually higher than 3, as indicated in this image with lowest iterations as black and highest as white:
I have rather newly added a smooth color transition function to my program.
This smooth color transition coefficient, used to blend the iteration count color with it's neighbor color, is calculated from ( |Z[n]|-2 ) / ( |Z[n]| - |Z[n-1]| ) (but maybe the standard function log ( log ( |Z[n]| ) ) / log(2) also could work). This is because I wanted a coefficient number between 0 and 1 in order to blend one index color with the next index color. I thought "how close was the previous iteration to reach bailout" (a.k.a Runmo-coloring
)
Now look at how these coefficients looks when lowest value is black and highest white:
Glitch 1, 2 and 3 are clearly shown as one color blobs, and the big area 4 has a distinct gradient color from white to black.
By combining the one-iteration count area with the smooth coefficient value, the glitches can be identified and ideally only 2 more references need to be added to create the final image
Of course it is not that easy, and there are many situation where the coefficient blobs don't have the same value all over, or don't lies exactly on the same area as the one iteration count blob. And fine tuning one image makes another image not work. I have some 30 different locations that I go through every time I do a change, and I also have a couple that I still cannot solve automatically, for example Dinkydau's Flake.
But the improvement is still significant and much better than only examine iteration counts or float calculation errors.
The float calculation errors maybe I should have removed since it doesn't work well and it makes the render much slower.
And on some locations the glitches can be solved only when long double is used always because of incorrect pattern appears on the blobs, or the smoothing coefficients doesn't have the same values in the blob area.
January 27, 2014, 12:08:08 PM
Dilber MC Theme by HarzeM