Botond Kósa
|
|
« Reply #60 on: February 22, 2014, 07:04:59 PM » |
|
A 32bit version is planned, but there are some features I am currently working on and have to be finished first (automatic blob correction being the most important one).
|
|
|
Logged
|
|
|
|
Botond Kósa
|
|
« Reply #61 on: February 22, 2014, 07:47:21 PM » |
|
As Botond Kósa write - all pixels in the blob get the same iteration count. But - But!!!!! This is only a special case, when only the main Mandelbrot have influence, i.e. no minibrot. If your zoom path pass close to one (or several...) minibrot there are many variations: * The blobs can contain a couple of iteration values, randomly spread through the blob * The blobs can contain an iteration count value that is lower than other ares in the same view * The blobs can have gradient content * The blobs can have structured pattern * etc etc etc
I have also experienced all these types of blobs, but I think the 3rd type with a gradient content is actually the same as the 4th, and the gradient is just part of a structured pattern. Botond Kósa I have a question for you - do you use only double datatype for calculating the pixels? It seems you use more precision than what is possible with the double datatype, since Mandel Machine get fewer glitches than Kalles Fraktaler when one reference only is used...
I use the regular double datatype, so this can't be an explanation for the fewer glitches is Mandel Machine. But I did a little investigation regarding the 3rd type blobs (the ones with structured pattern) and came up with some interesting conclusion. The following images are part of Dinkydau's "Flake" location, rendered with Kalles Fraktaler and Mandel Machine in different modes. (The reference is in the minibrot in the lower right quarter, which was the center of the image, but I cropped the images to highlight the differences between them.) Kalles Fraktaler with double data type. The large light green areas look like ordinary structures but are actually blobs. Kalles Fraktaler with long double data type. The blobs' color is different (the iteration values inside them are a little higher), the structure inside looks the same, but a strange abrupt shift appears in the gradient. Mandel Machine with perturbation. Very similar to KFR with long double (not counting the slight palette offset), the abrupt shift is also present, but in a different location. Mandel Machine without perturbation. No blobs, this is how the image should look. (Rendering took 23 minutes 44 seconds compared to 1.5 seconds with perturbation). Kalle, when "Use long double always" is turned on in KFR, do you also store the reference orbit in long double precision, or do you use it for the calculations only?
|
|
« Last Edit: February 22, 2014, 09:28:33 PM by Botond Kósa »
|
Logged
|
|
|
|
Botond Kósa
|
|
« Reply #62 on: February 22, 2014, 09:43:49 PM » |
|
Kalle & hapf, could you post some locations where you found blobs that cannot be corrected by using additional references? It would be extremely helpful.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #63 on: February 22, 2014, 11:01:42 PM » |
|
Kalle, when "Use long double always" is turned on in KFR, do you also store the reference orbit in long double precision, or do you use it for the calculations only?
Yes, I store the reference as long double values when long double is used (but the main reason for that was that otherwise the large exponents would get lost). And when I have compared, MM get as few glitches as KF with long double, with one reference. Kalle & hapf, could you post some locations where you found blobs that cannot be corrected by using additional references? It would be extremely helpful.
So far it is only the nasty flake location that I couldn't solve at all, at least not when using long double. One more glitch to add to the list - the view that has the exact same iteration count value on areas that are already correctly rendered, and that will be incorrect if the new reference is simply applied on all pixels with the same value. That is when I had to add the "Solve glitch with near pixel method" , which is just a simple flood fill.
|
|
|
Logged
|
|
|
|
hapf
Fractal Lover
Posts: 219
|
|
« Reply #64 on: February 23, 2014, 12:41:22 AM » |
|
Kalle & hapf, could you post some locations where you found blobs that cannot be corrected by using additional references? It would be extremely helpful.
I don't think there are locations that can not be rendered correctly with additional reference points, in theory. There are certainly locations that would require a new reference point for every pixel, at which point the perturbation method degrades to a computation with full precision and becomes slower than that one. This would only be the case for locations that are so deep that it won't be practical to even try to go there for the time being, I guess. For locations that are routinely done these days a couple of reference points should suffice, if necessary some dozens, even hundreds. It depends on the resolution of the image too. The more pixels the more reference points are needed as a general rule. It all depends a lot on the exact region, of course. With regions that have a minibrot in the center the structures where blobs usually show up are in circles around the center minibrot. The blobs ares in these circles. Different circles need different reference points. References in inner circles render more correctly pixels in outer circles than references in outer circles those in in inner circles. They often corrupt a whole disk around the center and parts of the circles closer to the center. Depends on location. A reference in a circle may render the whole circle correctly or just part of it. Again the more pixels the more likely parts of the circle will show blobs within blobs (e.g. fix the main blob and it splits in a fixed part and one or several still blobby parts). Without a reliable test if a pixel is corrupted or not the deblobbing is more an art form than anything else. The flaky location from above is a nasty one since the corruption enters the picture on toes and presents itself as if it were genuine structure. The real structure gently dissolves into something else. The location can be rendered pretty nicely with one reference point, but lots of small spirals further away from the center will still dissolve prematurely. They need additional references. I suspect one or 2 might do the trick. The problem is to decide which pixels these additional references should process. They will ruin the center part of the image again when they are applied there. And vice versa. Update: A clean version of this region. 3 references used.
|
|
« Last Edit: February 23, 2014, 12:02:13 PM by hapf »
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #65 on: February 23, 2014, 07:51:27 PM » |
|
Update: A clean version of this region. 3 references used.
Nice, and I know how you did it (because I done it too here http://www.fractalforums.com/movies-showcase-(rate-my-movie)/flake-second-attempt/) If you begin with a point not in the center of this view - then the glitches wont contain the structure and can easier solved with just a few extra references But to automatically decide in a program is impossible I think, unless someone find a mathematically way to certainly identify glitches. KF latest version is able to skip 23653 iterations in this view (min 29674), how many can you skip
|
|
|
Logged
|
|
|
|
hapf
Fractal Lover
Posts: 219
|
|
« Reply #66 on: February 24, 2014, 12:44:16 AM » |
|
Nice, and I know how you did it (because I done it too here http://www.fractalforums.com/movies-showcase-(rate-my-movie)/flake-second-attempt/) If you begin with a point not in the center of this view - then the glitches wont contain the structure and can easier solved with just a few extra references But to automatically decide in a program is impossible I think, unless someone find a mathematically way to certainly identify glitches. The first reference used does indeed decide what corruption you get. None or easier to detect or harder/impossible (?) to detect. KF latest version is able to skip 23653 iterations in this view (min 29674), how many can you skip I checked for a test image and average iterations were ~30500. Skipped 8358. It depends how much error you allow. 23653 looks impossible for 3 terms. What's your max error and average error here? Do you use 5 terms instead of 3? I looked into more than 3 terms but found it not helpful. Maybe I overlooked something and should retest it.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #67 on: February 24, 2014, 04:00:43 PM » |
|
I checked for a test image and average iterations were ~30500. Skipped 8358. It depends how much error you allow. 23653 looks impossible for 3 terms. What's your max error and average error here? Do you use 5 terms instead of 3? I looked into more than 3 terms but found it not helpful. Maybe I overlooked something and should retest it.
Yes, it is using 5 terms and allowing 0.1% error. The 4th and 5th terms of Series Approximation get intermediates with extreme exponents, perhaps not even possible to express in long double. I need to use my floatexp class that takes an integer as exponent and double as mantissa to calculate this. But with the previous version, using 3 terms and only allowing 0.0001% error, and using double datatype only, I could still skip 15769 iterations, so 8358 sounds very low. I've also tried 6 and 7 terms but it did not yield anything, at least not for the tick-tock location, not even though I used long double as mantissa. On locations with millions of iterations I could see a small gain, but I thought it was not worth it. If the view is divided in sections it may be possible to be able to skip more pixels in centered sections, but I doubt it is worth the effort since from what I have seen so far it is tens out of tens of thousands
|
|
|
Logged
|
|
|
|
hapf
Fractal Lover
Posts: 219
|
|
« Reply #68 on: February 24, 2014, 05:53:03 PM » |
|
Yes, it is using 5 terms and allowing 0.1% error. The 4th and 5th terms of Series Approximation get intermediates with extreme exponents, perhaps not even possible to express in long double. I need to use my floatexp class that takes an integer as exponent and double as mantissa to calculate this.
I compute the skip start value with arbitrary precision so this would not stop me. But with the previous version, using 3 terms and only allowing 0.0001% error, and using double datatype only, I could still skip 15769 iterations, so 8358 sounds very low.
Are you testing the whole picture?
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #69 on: February 24, 2014, 08:05:18 PM » |
|
Are you testing the whole picture?
No, only the 4 pixels in the corners. I thought they would give the most errors since they are farthest away from the reference.
|
|
|
Logged
|
|
|
|
hapf
Fractal Lover
Posts: 219
|
|
« Reply #70 on: February 25, 2014, 09:00:08 AM » |
|
No, only the 4 pixels in the corners. I thought they would give the most errors since they are farthest away from the reference.
Could you test the whole picture for comparison? Like 0.1 % of all pixels, regularly sampled?
|
|
|
Logged
|
|
|
|
Botond Kósa
|
|
« Reply #71 on: February 25, 2014, 11:13:37 AM » |
|
No, only the 4 pixels in the corners. I thought they would give the most errors since they are farthest away from the reference.
The error does not primarily depend on the pixel's distance from the reference. It depends on the pixel's orbit's distance from the reference orbit. If a pixel is in a dense region, the likelihood of an error is higher than for a pixel that is inside a slowly changing gradient. I found that testing the 4 corners is not always enough. If the corners are in sparse regions you could get visible error in the dense parts of the image. The more pixels are tested, the less is the chance of having all of them in sparse regions. Mandel Machine tests for the 4 corners and the 4 edge midpoints, for performance reasons. Ideally all edge pixels should be tested.
|
|
|
Logged
|
|
|
|
lycium
|
|
« Reply #72 on: February 25, 2014, 11:53:59 AM » |
|
I kind of expected this situation when the perturbation method was first described: you have a new chaotic system approximating another chaotic system, and until there's a lot of mathematical analysis and heuristic half-fixes etc, there will be random spurious problems.
I've resisted asking until now: is this really worth the headache and uncertainty? What exactly is wrong with the existing (trustworthy!) methods, that do not require any kind of checking to make sure the result is correct? If it's purely a matter of computation, then surely GPUs are up to the task...
|
|
|
Logged
|
|
|
|
hapf
Fractal Lover
Posts: 219
|
|
« Reply #73 on: February 25, 2014, 12:07:48 PM » |
|
I kind of expected this situation when the perturbation method was first described: you have a new chaotic system approximating another chaotic system, and until there's a lot of mathematical analysis and heuristic half-fixes etc, there will be random spurious problems. I've resisted asking until now: is this really worth the headache and uncertainty? What exactly is wrong with the existing (trustworthy!) methods, that do not require any kind of checking to make sure the result is correct? If it's purely a matter of computation, then surely GPUs are up to the task...
GPUs are limited to double precision. Rather restrictive for zoom depths. There is nothing wrong with older methods if you want to go deep and don't mind waiting a couple of hunded times or more longer.
|
|
|
Logged
|
|
|
|
hapf
Fractal Lover
Posts: 219
|
|
« Reply #74 on: February 25, 2014, 12:15:27 PM » |
|
The error does not primarily depend on the pixel's distance from the reference. It depends on the pixel's orbit's distance from the reference orbit. If a pixel is in a dense region, the likelihood of an error is higher than for a pixel that is inside a slowly changing gradient. I found that testing the 4 corners is not always enough. If the corners are in sparse regions you could get visible error in the dense parts of the image. The more pixels are tested, the less is the chance of having all of them in sparse regions. Mandel Machine tests for the 4 corners and the 4 edge midpoints, for performance reasons. Ideally all edge pixels should be tested.
All edge makes sure you hit close to the set since the set is connected (unless it's an uproblematic featureless region). But how can you be sure there is nothing inside the image that requires additional reduction of skipping? Of course a few pixels way off can be ignored if the rest stays well behaved.
|
|
|
Logged
|
|
|
|
|