Fractal universe
|
|
« on: May 12, 2016, 12:43:33 AM » |
|
Hi Kalles
There is a bug in the version 2.9.7 of kalles fraktaler 2. When I click on "auto solve glitch" with "examine zoom sequence", the problem below appear.
|
|
|
Logged
|
|
|
|
quaz0r
Fractal Molossus
Posts: 652
|
|
« Reply #1 on: May 12, 2016, 08:06:45 PM » |
|
most/all authors of perturbation programs i've seen are using default settings which favor speed over accuracy, probably even more so for zooms. if you want more accuracy there is probably an option somewhere where you can raise the max number of reference points and such?
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #2 on: May 12, 2016, 09:01:14 PM » |
|
Interesting. Can you send me the location?
|
|
|
Logged
|
|
|
|
Fractal universe
|
|
« Reply #3 on: May 12, 2016, 10:44:14 PM » |
|
Re: -1.296355138173036216808304477845282266265735748447889106496038985761209917380841177445968518215701758678084105701798781194955286791090159889479830250582998616337343672293770610499414537932319513273091525519480957820496859278286357694764845398638622284835930478246909426978498903001292186349332559002364119692765842997347411680020529930794430297889475200868675134070916915029352018955671209679653588455096044586235738194335823043789630623088453676657949865089362217637125034542974484819892882518624751323660120500136532115644867205611992160754276675349948316142781488215964382264146492785725093186522485081128928485363264599339734251203063880701539610046638303626795735718966970641220962923079472132879218084171429125502639157779993043432103141243971131090219953825914905004024872001745764432019897994637060100741704114438981666498439414773127273768682855615943049460249321102817802315841571856105883956688597465218149939352580623597585689908462847383648235816382580470517645800446361062024466323256389226230312616351187419538060225167736803525145232562199571699713437958091003679794587041876469868465856426563926212975296854780647056242705957785494023937014971169623443261919352966951619778850300586466326970568706005442490399114414710530104463493125608296913819151789916280880724413432577930767002163323557996698828262572794499999194869018065415227752694458414200815408162608128472937332894712532633236438374064168748491036172167649190381488090168987338631867626142176553092393627587023711821699750838956897945647744877403406483850925618315252953328987436142781151229876098476397533207189895153754771856587049648790114547938829260964489740063313214749090993166989912043877739160463422052860270972469115318915701047171917880990618003083436720660633950048613362270852364674467190551511460960744443762947808490866715105893507673957973164746095058432375554387135706903601439292278884911936421548663220799245064998695604164093487261179349347853800540569072644950925270588311758385070983686862244455927350856123325710859816597565337333091569397234250743592576434389631290690505531799777246836999955179257209426476184953422200993585637112614339598607545 Im: -0.441851605735196601212848580174986948840096866702890580517816641664137309219631137124274552377733978128686419957669157494088039035922351119632811221778713954178086193458861028284209543020285018565769515482463245803379644163301622266580558324633885400684383926664648595707250845941186242632516809899396314190876372172913204206324576438201859918119458401143921495705079306772286572229419308265992148297977456492889986116205742645363993821848697882610709906258793336239004842943906986210736820978592084207290666236555957482963656063549010444105123098070134336471987534785202927629973161950511592581427203797488045441440026238035076135625264861339753279100714891372407515853098284627171802695919672630737106960344603522635273210944830171135346252462537703505997818763885988466869217773916646359441140614304590841814645837510230426286057813658976772992338117014640045672814945221795097188356817324852849480363813371689059659232967175321254910109114494920069754633824103731891628134989201361537759392931257569337517543481361841545238865829088485855850404668357967323401050343944511551794864978777250158803946591708326816355481561539615842405016841201060211482818918114785749499657615064702167274001250041088644742208013944449418954651669543291476924409842045542521333491935816940422301647922356137533118613929599056439398381818098344974479177393005542332755082083163150701450215288991169921779016395219072435561522108487241990391382526569922293685620041733671097121849429464487621794520020167605266610614577515828657827352106545315040578420525657755525972854022796637807349147592268281748367517361119005099898668920219185722517400901384616477647235736032139186840880432015693914842914632869607777328404595380956495243408171754158478726042799312293183947848336579629235798589776678289925280075378662568941327347464781202650604139064414786204594121158855777979536943325628171806748815008807348214362171459702970449699336203605053062288484913989563224164570214316235959408550401925546639489047738690869625062858315750966130296354830068847624374499751573173110055245096965702203820751345879478548223084264302424284854828105269816428496557088832634046948605 Zoom: 1.49575125084E2126 Iterations: 40,000,000 (minibrot not enough defined), the video will have 100,000,000 iterations.
All keyframes are calculated without auto solve glitches. I prefer render keyframes before, and auto solve glitches after. picture above: Zoom = 8.38E1028
However, the bug is the same for any location with glitch zone.
|
|
|
Logged
|
|
|
|
Fractal universe
|
|
« Reply #4 on: May 12, 2016, 11:53:58 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).
|
|
|
Logged
|
|
|
|
|
Kalles Fraktaler
|
|
« Reply #6 on: May 13, 2016, 02:59:35 PM » |
|
All keyframes are calculated without auto solve glitches. I prefer render keyframes before, and auto solve glitches after.
The auto correct glitches in the examine function is only adding a limited number of additional references, 5 or 10 I think? I can see that the areas are filled with previous view, i.e. not updated, so they are at least identified as glitches. One issue that stardust and some others have encountered is that glitches are not identified because of Series Approximation skipping the point where the glitch occurs. I rendered the location at 8.38E1028 in 640x360 and it needed 10 references... I guess you rendered in much higher resolution, so you would need more references than the perhaps 10 that the examine function adds. Also, these types of references, the spirals from passing the elephant valley, are requiring many additional references in KF, which probably could be improved a lot if only the center of these spirals could be found in advance.
|
|
|
Logged
|
|
|
|
apeirographer
Forums Freshman
Posts: 18
|
|
« Reply #7 on: May 13, 2016, 04:06:53 PM » |
|
Can I, semi-on-topic, ask whether there's a way to set the settings in such a way that glitches are highly improbable for even lengthy zooms? Even if at the expense of the rendering speed? Like maybe tying the number of references to the depth, and having it overcompensate by some multiple?
The example you gave, a 640x360 picture needing 10 references... that's 1 reference per 23,040 pixels. Would the rendering speed not stay way ahead of most of your competition even if for the given depth and image size you used 50 or 100 references? And with settings like that or maybe even higher--but still nowhere near calculating even a 10th of the image fully in arbitrary precision--would the likelihood of glitches get low enough to no longer worry about?
Or am I oversimplifying the issues?
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #8 on: May 13, 2016, 06:05:59 PM » |
|
Can I, semi-on-topic, ask whether there's a way to set the settings in such a way that glitches are highly improbable for even lengthy zooms? Even if at the expense of the rendering speed? Like maybe tying the number of references to the depth, and having it overcompensate by some multiple?
The example you gave, a 640x360 picture needing 10 references... that's 1 reference per 23,040 pixels. Would the rendering speed not stay way ahead of most of your competition even if for the given depth and image size you used 50 or 100 references? And with settings like that or maybe even higher--but still nowhere near calculating even a 10th of the image fully in arbitrary precision--would the likelihood of glitches get low enough to no longer worry about?
Or am I oversimplifying the issues?
As long as high bailout is used, I haven't encountered one location where pauldelbrot's glitch finding method doesn't work. The issues we rarely find are due to series approximation, which could be checked against some pixels inside the view and not only on the edges, but that would be slower. So, the glitch finding method is reliable enough I think
|
|
|
Logged
|
|
|
|
Fractal universe
|
|
« Reply #9 on: May 13, 2016, 06:13:41 PM » |
|
Actually, I compute my keyframes with only 1 reference and the "reuse reference" button locked. at this stage, the glitch areas are normal. I auto solve glitches after (without "reuse reference"). I am noted empirically that areas with the previous view are the max iterations value from 1 to 9 references, but after the last reference, areas are sometime preserved the value, or sometimes a glitched values. Therefore the bug is at the last reference. When it stays a visible glitch areas, I begin a second passage of auto solve glitches. So the conservation of the iterations value inside areas is necessary.
With the 2.6.2 version, there is another problem. Auto solve glitches is working normally. But sometimes, one reference (for example the 4th) solve no pixel, the program add the next reference at the same pixel, solve no pixel, and stuck on the same location until the last reference. With a reference added manually, the problem is temporarily solved until another reference that solve no pixel.
|
|
« Last Edit: May 13, 2016, 06:22:19 PM by Fractal universe »
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #10 on: May 13, 2016, 08:53:41 PM » |
|
Actually, I compute my keyframes with only 1 reference and the "reuse reference" button locked. at this stage, the glitch areas are normal. I auto solve glitches after (without "reuse reference"). I am noted empirically that areas with the previous view are the max iterations value from 1 to 9 references, but after the last reference, areas are sometime preserved the value, or sometimes a glitched values. Therefore the bug is at the last reference. When it stays a visible glitch areas, I begin a second passage of auto solve glitches. So the conservation of the iterations value inside areas is necessary.
With the 2.6.2 version, there is another problem. Auto solve glitches is working normally. But sometimes, one reference (for example the 4th) solve no pixel, the program add the next reference at the same pixel, solve no pixel, and stuck on the same location until the last reference. With a reference added manually, the problem is temporarily solved until another reference that solve no pixel.
I think I set the last reference without identifying glitches, because I thought the glitches would be so small they wouldn't be noticed on the last reference... Maybe I should change that, and remove the limited number of additional references? Yes, since 2.6.2 I added a list of added references, so that the program doesn't try to add it on the same pixel again
|
|
|
Logged
|
|
|
|
Fractal universe
|
|
« Reply #11 on: May 13, 2016, 09:39:04 PM » |
|
You can leave the number of references (10 is a good number), but with the identifying glitches for the last if it's necessary to make a 2nd (and 3rd) passage. And continue to reuse center if no glitch is found.
Edit : I tested another auto solve glitches with 2.9.7 version. Sometimes, the glitched iteration values appear in one part of glitch areas before the last reference.
|
|
« Last Edit: May 13, 2016, 11:59:52 PM by Fractal universe »
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #12 on: May 16, 2016, 12:10:21 PM » |
|
I tried the automatic glitch solver in the latest version, 2.10, and it is able to add more references in the second round...
|
|
|
Logged
|
|
|
|
Pauldelbrot
|
|
« Reply #13 on: May 29, 2016, 08:07:10 AM » |
|
As long as high bailout is used, I haven't encountered one location where pauldelbrot's glitch finding method doesn't work. The issues we rarely find are due to series approximation, which could be checked against some pixels inside the view and not only on the edges, but that would be slower. So, the glitch finding method is reliable enough I think
So, still working reliably after a lot of battle testing? That's good to know. P.S. How does KF do as much with series approximation as it does? It often seems to get 60-70% of the iterations, vs. nanoscope's 20. Does it use more terms? (How many?) Or is it because it's checking against the image edges rather than just checking for the error estimate to get to a certain threshold and quitting there? (That might allow being less conservative.)
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #14 on: May 30, 2016, 02:56:05 PM » |
|
So, still working reliably after a lot of battle testing? That's good to know.
P.S. How does KF do as much with series approximation as it does? It often seems to get 60-70% of the iterations, vs. nanoscope's 20. Does it use more terms? (How many?) Or is it because it's checking against the image edges rather than just checking for the error estimate to get to a certain threshold and quitting there? (That might allow being less conservative.)
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)
|
|
« Last Edit: May 30, 2016, 07:37:57 PM by Kalles Fraktaler »
|
Logged
|
|
|
|
|