Pauldelbrot
|
|
« 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
|
|
« Reply #16 on: September 22, 2017, 05:11:38 PM » |
|
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. 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
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« 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-695492737Seems 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.
http://www.youtube.com/v/2tojn_ax_-8&rel=1&fs=1&hd=1
|
|
|
Logged
|
|
|
|
Fractal universe
|
|
« 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
|
|
« 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
|
|
« 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
|
|
« 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
|
|
« Last Edit: September 25, 2017, 09:50:54 PM by claude, Reason: added image »
|
Logged
|
|
|
|
Dinkydau
|
|
« 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
|
|
« 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
|
|
« 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
|
|
« 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.
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: 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
|
|
« Last Edit: September 29, 2017, 06:55:03 AM by claude »
|
Logged
|
|
|
|
claude
Fractal Bachius
Posts: 563
|
|
« 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 * 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). * 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...
|
|
« Last Edit: September 29, 2017, 10:31:22 AM by claude, Reason: evolution of trees comparison »
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« 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
|
|
|
Logged
|
|
|
|
claude
Fractal Bachius
Posts: 563
|
|
« 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). 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.
|
|
|
Logged
|
|
|
|
Pauldelbrot
|
|
« 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
|
|
|
|
|