Logo by mclarekin - Contribute your own Logo!

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

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Visit us on facebook
 
*
Welcome, Guest. Please login or register. March 19, 2024, 10:31:33 AM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: 1 [2] 3 4 ... 6   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: Pertubation Theory Glitches Improvement  (Read 27464 times)
0 Members and 1 Guest are viewing this topic.
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #15 on: April 18, 2014, 10:30:47 PM »

Sorry for a stupid non-mathematical suggestion but what if |Zn+dn|/|Zn| > 10+3?
Is there any point in testing that too?

I am not near a computer at the moment but I will give it a test when I am...
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
hapf
Fractal Lover
**
Posts: 219


« Reply #16 on: April 19, 2014, 09:23:05 AM »

Sorry for a stupid non-mathematical suggestion but what if |Zn+dn|/|Zn| > 10+3?
Is there any point in testing that too?

I am not near a computer at the moment but I will give it a test when I am...
There is a point in testing everything that could make sense. :-) But going for the max works not nearly as well
as going for the min in my tests.
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #17 on: April 20, 2014, 06:19:40 PM »

Checking |Zn+dn|/|Zn| > 10+3 did only make it worse.
Only checking |Zn+dn|/|Zn| < 10-3 is useful.

For your reference, here is my collection of locations which I ever have had problems with, which I (hrm... often) use as regression test of new versions of Kalles Fraktaler.
http://www.chillheimer.de/kallesfraktaler/glitches.zip
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #18 on: April 27, 2014, 08:17:01 PM »

I just want to mention also in this thread, that I strongly believe that this is the bullet proof method we all been searching for since mrflay published the perturbation and series approximation method just a little more than a year ago.

The trick is to test every iteration (after series approximation), since the interval were the condition |Zn+Dn|/|Zn|<10-3 is true can be very small.

This method doesn't only detect noisy borders around flat glitches and non-flat glitches with structure in it, it also prevents a program from examine one colored areas that are valid, and all of this in a reliable way.
This method can even detect one pixel sized glitches, and there are no need to compare a render with a full precision render anymore. smiley
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
Pauldelbrot
Fractal Senior
******
Posts: 2592



pderbyshire2
« Reply #19 on: April 28, 2014, 12:24:35 AM »

I just want to mention also in this thread, that I strongly believe that this is the bullet proof method we all been searching for since mrflay published the perturbation and series approximation method just a little more than a year ago.

The trick is to test every iteration (after series approximation), since the interval were the condition |Zn+Dn|/|Zn|<10-3 is true can be very small.

In theory, you could only check on iterations that are multiples of certain numbers -- I think the periods of minibrots that are smaller than about 10-10 wide, but large in comparison with their distance from the reference orbit ... where one would need a more precise definition of "large in comparison with" that isn't very intuitive, since the deeper you are the tinier and farther the minibrot can be and still "count", but "the reference orbit is far enough inside the period-doubling zone of the minibrot that it's inside an eight-fold repetition" seems like it might suffice; iterations where the reference orbit point is within some sufficiently-small distance of zero, which could be precomputed into a table when the reference orbit is calculated. (Nanoscope already does something similar, but more stringent, for a different purpose; it saves a 16-bit-mantissa unlimited-exponent-width reference orbit point for each iteration where the reference orbit point is within a tiny enough distance of zero that it denormalizes or snaps to zero when stored in doubles. These are kept in a hash table indexed by iteration number and used in an unlimited-exponent-width recalculation of an iteration if ndx or ndy denormalizes (this is also when delta squared gets calculated, when below 10-308); otherwise, flying past a very very deep minibrot (below e308) and then far enough to reach iters that are the next multiple of the minibrot's period produces a precision-blockied image and then, shortly, nothing. Note: ndx and ndy may sometimes denormalize on iterations where the reference point doesn't, and then Nanoscope uses the normal stored reference orbit point, in doubles, copying them into temporaries with unlimited exponent width; that is, it looks in that hash table at the current iteration for a wide-exponent reference point, and failing that creates one from the "regular" one. Then it uses it, and delta with its rescaling descaled, in an exact (delta squared included and unlimited exponent width) next-iteration calculation, before rescaling delta again so that it is O(1) before continuing, or just leaving it descaled if it's gone above e-308 at that point.)

In practice, it's probably easier to just check every iteration.
« Last Edit: April 28, 2014, 12:28:18 AM by Pauldelbrot » Logged

Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #20 on: April 28, 2014, 12:34:19 AM »

Hahaha yeah I agree with your last statement!  cheesy lol
Thanks so much for your discovery!
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
Pauldelbrot
Fractal Senior
******
Posts: 2592



pderbyshire2
« Reply #21 on: April 28, 2014, 01:03:12 AM »

Hahaha yeah I agree with your last statement!  cheesy lol
Thanks so much for your discovery!

yw
Logged

hapf
Fractal Lover
**
Posts: 219


« Reply #22 on: May 05, 2014, 02:17:53 PM »

I looked into iterating the epsilons but that showed no benefit so far. Checking minima of |Zn+Dn|/|Zn| or maxima of Zn|/|Zn+Dn| (single value or sums) seems to be the most efficient metric so far. While there is definitely correlation between this metric and actual error/corruption it is far from perfect. So the question remains where to set thresholds and how to deal best with all the pixels that are potentially corrupted. With a given threshold there can be 10000s, even 100000s of blobs (for large images) that need to be dealth with, or not.  crazy eyes
Logged
Pauldelbrot
Fractal Senior
******
Posts: 2592



pderbyshire2
« Reply #23 on: May 05, 2014, 03:04:01 PM »

I looked into iterating the epsilons but that showed no benefit so far. Checking minima of |Zn+Dn|/|Zn| or maxima of Zn|/|Zn+Dn| (single value or sums) seems to be the most efficient metric so far. While there is definitely correlation between this metric and actual error/corruption it is far from perfect. So the question remains where to set thresholds and how to deal best with all the pixels that are potentially corrupted. With a given threshold there can be 10000s, even 100000s of blobs (for large images) that need to be dealth with, or not.  crazy eyes

I noticed. Nanoscope maintains a memory of iteration numbers it encountered potential glitches at, as detected by these minima. When it encounters a new one (novel iteration count) it finds the approximate center of the region (using an algorithm previously described) and computes a high precision orbit there, as well as computing a point there while ignoring the "glitch alarm", and compares the iteration counts. If there's a significant discrepancy, it considers the glitch "real" and will use the just-computed orbit as reference for regions where the "glitch alarm" trips on that same iter. If there's no significant discrepancy, it marks that iteration as "ignore" and ignores future "glitch alarms" that trip on that iter. There's a separate such registry of alarm iters and ignore/use-this-ref-point info for each reference point.

The results looked accurate to my eye and fixed all the usual-suspect glitch cases (including noisy glitches) while generating relatively few high precision orbits per image, even for large (30ish megapixel) images. Most of the tiny "glitch alarms" end up being ignored, while the bigger ones sometimes end up getting their own local reference points, including (seemingly) all the ones hiding real actual glitches.
Logged

hapf
Fractal Lover
**
Posts: 219


« Reply #24 on: May 05, 2014, 06:50:07 PM »

That's an interesting approach. It is indeed so that even complex images usually don't need tons of new references, just a few, the right ones. I tried to characterise blobs with all kinds of measures (average iterations, shape properties etc.) but making sure that blobs with the same properties can be fixed with the same (new) reference proved difficult in the general case (but not the case with a minibrot in the center of the image). So I will look into this new property to see if it helps generally.
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #25 on: May 05, 2014, 09:51:14 PM »

100000 glitches in the same image? I guess almost all of them are one pixel in size?

I set all pixels identified as glitch to the same iteration value and recalculate all of them for every new reference added, regardless. This glitch detection method is so good so if the new reference doesn't solve one glitch, it is detected again as a glitch, and might get solved by the next reference.
I try to add the new reference in the center of the largest blob. But that is ineffective many times, especially on glitches caused by close passage of a minibrot's elephant valley where the spirals are in the edge of the blob glitches.
But you could as well place the new references randomly inside any glitch and recalculate them all. Eventually they all get solved - by far less full precision calculations than if they were calculated one by one.

And for one-pixel sized glitches, I just cover them by using the nearby pixel's values smiley
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
Pauldelbrot
Fractal Senior
******
Posts: 2592



pderbyshire2
« Reply #26 on: May 06, 2014, 09:33:08 AM »

100000 glitches in the same image? I guess almost all of them are one pixel in size?

I set all pixels identified as glitch to the same iteration value and recalculate all of them for every new reference added, regardless. This glitch detection method is so good so if the new reference doesn't solve one glitch, it is detected again as a glitch, and might get solved by the next reference.
I try to add the new reference in the center of the largest blob. But that is ineffective many times, especially on glitches caused by close passage of a minibrot's elephant valley where the spirals are in the edge of the blob glitches.

Nanoscope uses an iterative refinement approach here. After determining a blob region (left top right bottom rectangle around it) and computing a reference in the center and checking for discrepancy with calculating the center with the previous reference and disabled "glitch alarm" and finding a substantial discrepancy, it will use the hill-climbing net-contracting thingy in that rectangle with the new reference to find a smaller blob or high-iteration point, and if it hits a blob or the glitch alarm goes off, this will result in refining the choice of reference point. If it gets refined, it gets repeated. In the end it comes back with a reference point that's recursively in sub-sub-sub-peanuts, or in a spiral in the edge of the blob glitch, or wherever it needs to be. There might even end up being a chain of reference points, if necessary; the really old only-two-reference-points versions sometimes ended up with annular glitches with the center corrected but not a ring around the outside, particularly at one of Dinkydau's test locations (not Flake).
Logged

hapf
Fractal Lover
**
Posts: 219


« Reply #27 on: May 06, 2014, 10:48:46 AM »

The measure is very good in the sense that it will catch all potentially corrupted pixels as long as one does not set the threshold too low. So applying an unsuitable reference to corrupted pixels or pixels suspected to be corrupted is just wasting time, but not adding undetectable new corruption, which is very important. There is another measure/test that is pretty much 100% accurate in the sense that if it says corrupt, then the pixel is corrupt. Unfortunately that measure does not identify all the noisy corruption pixels. It can be used to prioritise blobs, though. The most efficient method is the one that uses not more references than needed and applies a suitable reference every time pixels are recalculated and every pixel is calculated at most twice. I'm not sure this is feasible, but it might be. And then there is the issue of how to get a new reference most efficiently.
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #28 on: May 11, 2014, 03:01:36 PM »

First I just want to mention that this glitch detecting method also works on 3rd degree Mandelbrot. Super!!

Secondly, I have found a location (in the 2nd degree mandelbrot) where pixels are detected as glitches and don't get solved even with an additional reference in the very same pixel!

In the latest version of Kalles Fraktaler all glitches larger than 1 pixel are solved and up to 30 references are added, and on the last reference no glitch detection is made, hoping that they all are so small at that time so that they don't get noticed by the consumer.

Also the location from hapf earlier in this thread has there 2-pixel sized glitches that are always detected as glitches. They keep being visible while KF add reference until the last reference is added, then they disappears and look good because detection was not applied.
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
hapf
Fractal Lover
**
Posts: 219


« Reply #29 on: May 12, 2014, 11:24:47 AM »

It all depends how you define "glitch" and "detected". The measure does not detect glitches per se. It just gives you an estimate for the likelihood of a glitch. And what is a glitch or corruption? Any deviation from the real value above some percentage threshold? Any deviation that is actually visible using a specific colour map and colouring algorithm? Depending on the threshold used with the measure you will get more or less corrupted pixels that are false alerts. Or bad pixels missed.
Logged
Pages: 1 [2] 3 4 ... 6   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Pertubation and 3rd degree Mandelbrot (new) Theories & Research « 1 2 » Kalles Fraktaler 21 1913 Last post November 15, 2016, 05:07:03 PM
by Kalles Fraktaler
Help: Mandelbrot pertubation fails when zooming deeper than 1E1400 Programming CFJH 10 1078 Last post January 08, 2014, 06:55:10 PM
by Kalles Fraktaler
About bugs and glitches Movies Showcase (Rate My Movie) SeryZone 2 1095 Last post June 02, 2014, 11:00:15 PM
by SeryZone
Nasty glitches... Kalles Fraktaler Gallery PieMan597 1 1306 Last post April 04, 2015, 01:56:14 PM
by Kalles Fraktaler
Glitches and crashes Mandel Machine CmdrKeen 13 4703 Last post August 04, 2015, 06:09:44 PM
by claude

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.193 seconds with 25 queries. (Pretty URLs adds 0.011s, 2q)