Logo by Maya - 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 the official fractalforums.com Youtube Channel
 
*
Welcome, Guest. Please login or register. July 20, 2018, 10:54:58 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   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: Auto solve glitch problem  (Read 1608 times)
0 Members and 1 Guest are viewing this topic.
Pauldelbrot
Fractal Senior
******
Posts: 2592



pderbyshire2
« Reply #15 on: June 30, 2016, 06:57:12 PM »

Yes, more terms are used, starting with 10 for 640x360, more for larger views e.g. 60 for 3860x2160, down to 5 for small glitches.
And it is checking against 8 points on the edges (centers and corners), these points are calculated with perturbation from iteration 0 while the approximation is calculated and each iteration is compared for a threshold of 0.00001 for high tolerance and 0.001 for default low tolerance.
Also, my own class floatexp is used for the approximation algorithm instead of standard double datatype.
That is because most of the terms easily reach out of bounds for the double datatype, but later in the process these terms may grow and influence the result (chaotically)

I'll note that for later.

Meanwhile, on the topic of redoing the same point over and over in an endless loop, Nanoscope's solution to this is very simple and doesn't clutter up memory with a list of pixels previously used as references: when it picks a glitched pixel and calculates a reference there, it also uses that iteration to color in that particular pixel. Combined with it specifically selecting a glitched pixel (even if the glitch has a hole, and the barycenter is a nonglitched pixel), this guarantees it won't try the same pixel twice, and that it will eventually finish the image, by hook or by crook.
Logged

Fractal universe
Explorer
****
Posts: 50



« Reply #16 on: September 22, 2017, 05:11:38 PM »

Here is an example of the worst glitch of this type.
the 2 references + 1 added is a simulation of keyframes after autosolve glitches (always 10 references).
http://www.fractalforums.com/index.php?action=dlattach;topic=23731.0;attach=12811;image

Hello, after a long time without Kalles Fraktaler, I downloaded Kalles Fraktaler 2.11.1 GMP. I test to render a zoom sequence with many parturbation glitches. With "Auto solve glitches" checked while rendering, there isn't bug, but with the function "Examine zoom sequence → Autosolve glitches", the same bug since 2.9.7 version appear. I tried to recompute entirely a frame with this function, I noticed that Paudelbrot method doesn't work when the bug appear.

try to render this location with "reuse reference" checked, and try to solve glitches with "Examine zoom sequence" and "reuse reference" unchecked. It take about 5-10 minutes.

Code:
Re: -1.7692026523595072889383857467776111524931174128810441858206091009582682358361714060565188845736378999999999999999999700
Im: -0.0569076698576771144575618191177937971946160499670677653396147999149822235591500415257488642677904400000000000000000000
Zoom: 3.34680029051E46
Iterations: 275250
IterDiv: 1.000000
SmoothMethod: 1
ColorMethod: 0
ColorOffset: 0
Rotate: 0.000000
Ratio: 360.000000
Colors: 255,0,255,0,0,0,0,0,255,0,255,255,0,255,0,255,255,0,255,0,0,
Smooth: 1
MultiColor: 0
BlendMC: 0
MultiColors:
Power: 2
FractalType: 0
Slopes: 0
SlopePower: 100
SlopeRatio: 50
SlopeAngle: 45
imag: 1
real: 1
SeedR: 0
SeedI: 0
FactorAR: 1
FactorAI: 0


* problem.jpg (192.81 KB, 653x528 - viewed 39 times.)
Logged

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



kallesfraktaler
WWW
« Reply #17 on: September 23, 2017, 10:41:26 PM »

Yep, seems that pauldelbrot's method of detecting glitches is not bullet proof after all.
Also this move is based on a location where the glitch is not detected. The movie begins with the image rendered in mandel macine and there are some small pattern in the middle of the four structures that is lost when rendered in kf. However on the large image on his deviant-art page shows that also mm renders this part distorted.
https://olbaid-st.deviantart.com/art/Deep-Mandelbrot-Set-023-10-1086-695492737

Seems that when the main reference has "contact" with a deeper minibrot parts from another minibrot can be distorted. This phenomen gets more common now this the extremely effective newton-raphson method of zooming.
I know how to solve this but it could make kf slower:
* have a lower threshold for glitch detection.
* not add the main or any reference in the center of the image, only in centers of glitches.
* move the result after a newton-raphson zooming by a fraction of a pixel - so that the "contact" with the minibrot is broken.

I think the last suggestion would be most effective, so if claude reads this, this is my best suggestion.

<a href="http://www.youtube.com/v/2tojn_ax_-8&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/2tojn_ax_-8&rel=1&fs=1&hd=1</a>
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
Fractal universe
Explorer
****
Posts: 50



« Reply #18 on: September 24, 2017, 01:48:21 AM »

I just tested to render the same location (Store Zoom-out images) with auto solve glitch checked. The bug never appears.
When I render without auto solve glitch, The bug appears only when I solve glitch with "examine zoom sequence".

I have a deep zoom project to 10^2126 with all frames rendered without solve glitch (many glitches), and I don't want to solve by hand.
Logged

claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #19 on: September 25, 2017, 05:02:34 PM »

I can confirm the bug in 2.12.2+git (unreleased) with examine zoom sequence auto solve glitch.

Steps to reproduce:
* start kf.exe
* load the settings file posted by Fractal universe
* select "reuse reference"
* save zoom out sequence (doesn't take long at default resolution 640x360)
* deselect "reuse reference" or restart kf.exe
* select "examine zoom sequence" and load the previously saved sequence
* select "save and previous" to go to last (deepest) frame
* select "autosolve glitches"

What should happen:
* glitches are solved in all frames from the current until the first (least deep)

What actually happens:
* glitches are solved in the deepest frame only, nothing happens on other frames (including when advancing automatically after solving glitches on the last frame). the timer is running and it looks like kf should be working, but CPU usage is close to 0

Possible causes (speculation, there may be others too):
* some kind of timing race condition or logic error between the glitch solving code and the KFB loading code, so nothing happens when not on the deepest frame
* some kind of logic error in the "zoom size" calculation from the KFB filenames (which I changed recently to avoid a crash, maybe I introduced a bug by accident).  EDIT this was the cause, fix will be in 2.12.3 later today.

The root cause is still unknown, pending further investigation.
« Last Edit: September 25, 2017, 06:05:43 PM by claude, Reason: found the bug » Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #20 on: September 25, 2017, 06:41:11 PM »

I noticed that the auto solve glitches dialog adds at most 10 references to each frame.  So to solve all glitches you have to run it over and over, manually.  I will try to add a setting where you can change how many references can be added per frame, so you can increase it if necessary.  I also noticed that the reference count limit for the main image is 199 or so, which isn't enough for some very large images.  I'll try to lift this limit too.
Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #21 on: September 25, 2017, 09:44:48 PM »

I just tested to render the same location (Store Zoom-out images) with auto solve glitch checked. The bug never appears.
When I render without auto solve glitch, The bug appears only when I solve glitch with "examine zoom sequence".

I have a deep zoom project to 10^2126 with all frames rendered without solve glitch (many glitches), and I don't want to solve by hand.

In my tests "auto solve glitch" enabled, and "reuse reference" disabled, results in a zoom out sequence without glitches much more quickly over all than trying to "examine zoom sequence auto solve glitches" on a glitchy zoom out sequence rendered with "reuse reference" enabled (I stil didn't manage to get a glitch free sequence yet, after adding 100s of references).  I don't know why exactly, I suspect some precision loss or misalignment between pixels and their true parameter plane locations.  This is hard to debug, so for now I recommend not using the "reuse reference" method.  This doesn't help you much, sorry sad


* glitchy.jpg (244 KB, 650x435 - viewed 51 times.)
« Last Edit: September 25, 2017, 09:50:54 PM by claude, Reason: added image » Logged
Dinkydau
Fractal Senior
******
Posts: 1616



WWW
« Reply #22 on: September 28, 2017, 10:46:00 PM »

There's something very weird going on with "reuse reference" that I reported before. Try having it enabled and working seemingly fine at some location that doesn't have to be very deep, then change the coordinates drastically and let it render again. It will look like you only moved a tiny bit. Could it be that upon changing the coordinates, the location of the reused reference is automatically used as the center?
Logged

Pauldelbrot
Fractal Senior
******
Posts: 2592



pderbyshire2
« Reply #23 on: September 28, 2017, 10:56:03 PM »

So, false alarm w/r/t my glitch-detection method? It's a KF bug with reuse reference?

(OT) PING: Dinkydau -- do you ever check your facebook messages?
Logged

Dinkydau
Fractal Senior
******
Posts: 1616



WWW
« Reply #24 on: September 29, 2017, 12:12:24 AM »

No, I never used facebook. Originally I signed up only to follow my student association's facebook page. I will answer your message.
Logged

claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #25 on: September 29, 2017, 04:14:12 AM »

So, false alarm w/r/t my glitch-detection method?

Unfortunately, I think the problem is real.  The glitches at the center of the 4 large structures are not detected, there should be more detail there instead of a flat "hole".  I tried with series approximation disabled (render time ~9mins at 512x512, with approximation was ~90s) and the problem remained. sad sad sad


Location taken from https://olbaid-st.deviantart.com/art/Deep-Mandelbrot-Set-023-10-1086-695492737 , I tried to recreate the palette but I didn't quite get it right, anyway attached for convenience, also the image showing the problem.

update the problem occured with: glitch_threshold = 0.0000001 (this threshold is multiplied by squared magnitude for the glitch test).  Using Pauldelbrot's original 0.001 threshold (again multiplied by squared magnitude) the image renders correctly.  Sorry for the scare...

update 2 added another image with comparison of 4 threshold levels - even when the holes don't appear, the outer layers are much grainier with smaller thresholds, the 1e-3 (0.001) threshold looks much better.  Here's a little table of render times:
Code:
threshold refs time notes
0.0000001   9  1m30 big hole
0.000001   15  1m56 small hole
0.00001    21  2m28 grainy at edges
0.0001    127 11m02 still not perfect
0.001     310 29m31 very good quality

* Olbaid-ST-023.kfr (2.8 KB - downloaded 18 times.)

* Olbaid-ST-023-threshold-comparison.jpg (241.16 KB, 512x512 - viewed 71 times.)
« Last Edit: September 29, 2017, 06:55:03 AM by claude » Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #26 on: September 29, 2017, 07:18:33 AM »

* have a lower threshold for glitch detection.

I think this is the best way, 1e-3 = 0.001 should be good for the squared magnitude test, as Pauldelbrot suggested (IIRC he originally said 1e-3 for non-squared magnitude which is 1e-6 for squared magnitude but later corrected himself).  Maybe I make this settable in the GUI (done, will be in the next release - just a checkbox that when enabled, uses the square root of the formula's glitch threshold instead. Default is disabled, because it slows down rendering a lot).

Here's a comparison with the Evolution of Trees location:

(gif colour limit loses some quality, but the difference is still clear)
high took 2m38.5 with 14 refs; low took 7m15.7 with 46 refs

Quote
* not add the main or any reference in the center of the image, only in centers of glitches.

How to add the main reference in a glitch automatically, without having rendered the image already?

Anyway I tried adding references with the 0.0000001 threshold, both with add reference and with set main reference, there was still some bad appearance in the 4 structures (no longer a hole, but the details weren't quite correct).

Quote
* move the result after a newton-raphson zooming by a fraction of a pixel - so that the "contact" with the minibrot is broken.

I may try this at some point, but I doubt it will work...


* glitch-low-tolerance.png (8.21 KB, 180x591 - viewed 33 times.)
« Last Edit: September 29, 2017, 10:31:22 AM by claude, Reason: evolution of trees comparison » Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #27 on: September 29, 2017, 03:37:26 PM »

Thanks claude.
I think your solution is the best, to have it optional to lower the threashold to a value that guarantees that all glitches will be found!

Now with the extremely effective Newton-Raphson, it is very easy to reach e1000 depths, which seems to be where this situation occurs.
I don't remember encountering this on shallower depths.

And I am very glad to find that Pauldelbrot's glitch detection method is still rock solid, which is an essential part of this kind of rendering 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
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #28 on: October 03, 2017, 02:39:58 AM »

In my tests "auto solve glitch" enabled, and "reuse reference" disabled, results in a zoom out sequence without glitches much more quickly over all than trying to "examine zoom sequence auto solve glitches" on a glitchy zoom out sequence rendered with "reuse reference" enabled (I stil didn't manage to get a glitch free sequence yet, after adding 100s of references)

I discovered that it is not "reuse reference" that is to blame - just disabling "auto solve glitches" when rendering the zoom out sequence is enough to cause problems.  Something is broken with "examine zoom sequence auto solve glitches" itself.  Example attached, trying to "auto solve glitches" of a zoom out sequence (Fractal universe's location) rendered without "auto solve glitches" and without "reuse reference".  I'll try to find out what is wrong, and fix it for 2.12.4 (but if I don't manage it by the end of this week, I'll release 2.12.4 without a fix - there are plenty of other bug fixes that could be useful to have).

Quote from: Dinkydau
There's something very weird going on with "reuse reference" that I reported before. Try having it enabled and working seemingly fine at some location that doesn't have to be very deep, then change the coordinates drastically and let it render again. It will look like you only moved a tiny bit. Could it be that upon changing the coordinates, the location of the reused reference is automatically used as the center?

Yes I can reproduce this behaviour.  Added to known bugs list, so I don't forget about it.


* examine-autosolve-glitch-problem-without-reuse-ref.jpg (245.15 KB, 650x435 - viewed 50 times.)
Logged
Pauldelbrot
Fractal Senior
******
Posts: 2592



pderbyshire2
« Reply #29 on: October 03, 2017, 02:52:15 AM »

Is there even any use for the ability to disable "auto solve glitches" anymore? I'm wondering if non-auto-solve-glitches patterns of usage here are basically obsolete. If it's both buggy and obsolete, maybe the auto solve glitches option should go (forced to always-on) and the alternative (buggy) solve-glitches methods should be removed?
Logged

Pages: 1 [2] 3   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Auto Log Fractal coloring Help & Support fractalwizz 13 2383 Last post January 05, 2009, 11:56:37 PM
by HPDZ
Auto-log in FractInt Help & Support HPDZ 2 648 Last post August 21, 2009, 07:00:37 AM
by JackOfTraDeZ
Fractal Haze Could Solve Weak-Sun Mystery for Early Earth Fractal News across the World Nahee_Enterprises 0 890 Last post June 13, 2010, 03:38:59 PM
by Nahee_Enterprises
auto embed video modification Fractal Forums News cKleinhuis 0 301 Last post June 02, 2015, 09:16:58 PM
by cKleinhuis
Can you solve it? The incredible sponge puzzle Fractal News across the World claude 9 509 Last post April 17, 2017, 03:38:52 PM
by KRAFTWERK

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.231 seconds with 29 queries. (Pretty URLs adds 0.019s, 2q)