Using KF to compare renderings with SFT hacks

[3dickulus]

I would like to use KF to compare renderings with my SFT hacks to verify that I haven't made a mess of it, but...

I have some location with 2000+ digits, when I put these into KFs "Location"  requester the values are truncated to about 700+ digits and end up rendering the wrong location making a comparison at E2280 impossible.

When rendering the same location at about E50 with re&im truncated to the same length they look comparable.

Is this a limitation of the requester input widget? or am I the only one seeing this? kf-v2.5.3-64 on linux via wine.

RE:KF
-1.628525034382336188383826254854504541034866123658414160176944648059774261397865286688453414701543869586633032490835896
78966399541038911247108589834009305485135565610432065322034212454490261441840889724143509680838846674444199679053462961
22369829125808715959589508004033683543856979653688355703357362596797912790215729307519005701670693821446556437233617104
78988865179746415925444577996083120439879996353114415182615797948749865395234776209818146361578177184267620074208435764
66945869241303789441762327453111585403712108891625202499983591308412642062610561749281602956143514640379662188892624823
25314900811659507013764935080677766364077648061558048528248826421672925677934772942435112381237394313059764692573179982
63378769

RE:SFTC
-1.628525034382336188383826254854504541034866123658414160176944648059774261397865286688453414701543869586633032490835896
78966399541038911247108589834009305485135565610432065322034212454490261441840889724143509680838846674444199679053462961
22369829125808715959589508004033683543856979653688355703357362596797912790215729307519005701670693821446556437233617104
78988865179746415925444577996083120439879996353114415182615797948749865395234776209818146361578177184267620074208435764
66945869241303789441762327453111585403712108891625202499983591308412642062610561749281602956143514640379662188892624823
25314900811659507013764935080677766364077648061558048528248826421672925677934772942435112381237394313059764692573179982
63378769319816958015265774485675143369849269237733599474901955039753217655915825610865097716734842993621016545959138838
01323969389180163700871844758080786393937576034131904742929385523272933801335342850192984601738950379089556673216106792
27754301569789651633727819129250336167769271075928393119318923691654376785179080771552211515665905264906708962138726151
99414900144901946339747904518296188690121228361249133639477119632327513376110996457254269575538009626576476259137926259
94561062814399643393500722792913247325712605642371424205767752678073693495345663304124047557563364594659569510341511164
04848826730525105721586890037428787237038197776243211306811374870319466449517108214150449500776387260434364774337004520
49516516718581783192450056190846325465230619957817834590811547643729267855245950261457382135369395398869612795897432865
06729650150152287759299775870001287921387983274040588712409966022980082849502819430769388867342776440458365630390694942
01953870495063721543445809479277362458262713083729258720260307404027491495620550880838297507725696875313291575667252286
85359687435386778428102982188657669948751271273310360050793692188634974395369422951554971132643949261329123721560329816
91412591441528447707805126375239250736797878601094790342063024097540568983096488865377948898851491531795018041947502837
59903281141127251875739584248323872821969165486022504258101976367944187260084192016601951246606086454171702371240826323
62842559814453125E+00

edit:using kf 2.5.6 managed E1700 but have to paste coords into "Location" requester before new render

[quaz0r]

any chance on adding linux support to this program?

[3dickulus]

kf-v2.5.3-64 on linux via wine.

[quaz0r]

yeah i just tried it in wine it seems to work fine.  before trying the windows binary i downloaded the source just to take a peek i bet it would not be an overly ridiculous amount of work to change the windows stuff to gtk stuff or something?

[Kalles Fraktaler]

@3dickulus
There may be a limitation in the transfer of text from the edit boxes.
You can also store a simple location and then edit the kfr file instead, which is simply a text file.

Another thing is that KF doesn't parse exponents from these location values. It just ignore anything that is not numbers and decimal dot is expected after the first value digit.

[3dickulus]

using wine on linux...

1. run KF
2. open "Location" requester
3. enter a very long RE: value
4. close requester (hit enter key)

open the location requester again and the value is truncated to 28 characters when zoom=1

it seems to be (zoom exponent) + 38 after zooming in some amount

when loading from a settings file the numbers are also truncated to  (zoom exponent) + 38, to test this I edited a deep zoom kfr file to contain re/im coords with 250 digits and a zoom of E55, this truncated to 92 ? in the requester.

[Kalles Fraktaler]

Do you with 'requestor' mean dialog?
Yes the digits are indeed truncated. Because you don't need the possible 150.000 digits if you are zooming on for example e55. It saves a huge amount of calculation time to truncate like this.
92 may also seem unnecessary much for e55, but is needed when zooming along <-2,0i> because they way I have implemented full precision with a fixed decimal point and no exponents.

[3dickulus]

yes, mean "Dialog"

from a math stand point, yes, 150,000 digits are not needed until you get  to the level of zoom that requires them

this shows up because I am testing SFTC against KF and was checking render speed and glitch detection "along the route", so I have deep location around E2200 but want to check at E600, E1200, E1800 etc. as long as I check from deepest to shallowest and reload the deep location before moving on, why doing this? after adjusting some routine and recompiling I test a few problem spots or interesting features to see if I break anything.

the truncating does not present any real problem as I can save a zoom sequence and go back to examine frames  but when entering locations created outside of KF this little factoid is handy to know.

 

[ratcat65]

The palette is fetched form the first frame (KFB). So if you re-save the first frame with a new palette that palette will be used.
But I guess you won't be able to see how the palette looks like using the first out-zoomed frame, so here is what you can do:
* Use the examine zoom sequence and select a frame where you can see the result of the palette.
* save the palette as a palette file
* go to the first frame, open the palette, and then save. You may need to click in the image somewhere to add a reference to make it be saved.

Sorry for this complicated sequence of operations. The color dialog should maybe be inserted in the KFMM program as well I guess. I only use the waves these days...

I have tried this several times but I can't get it to apply a different gradient. 

[Kalles Fraktaler]

I have tried this several times but I can't get it to apply a different gradient. 

I am doing a render, when it is complete I will try it again.

[3dickulus]

Here are some results of my tests, KF still has a nicer render and interface and is faster sometimes, but...
if there is something that I've stumbled upon that might make it better I would like to share...

Test 1 E1804 - E1870

          Comp-1        Comp-2        Comp-3        Comp-4        Comp-5        Comp-6
------------------------------------------------------------------------------------------------------------------------------
KF      05:02.014    00:52.587     06:31.486     04:43.667     02:15.123     06:07.371
SFTC  00:36.271    00:35.003     00:35.615     00:49.739     00:56.081     00:41.309


Test 2 At the Polished Emerald location

zoom @E355          SFTC falls down @E405
---------------------------------------------------------------------------------
KF 00:00.863      KF    00:26.193
SFTC 00:11.752      SFTC 00:50.658

Test 3 At Kalles Julia Morph location

zoom@e500        zoom@e604
---------------------------------------------------------------------------------
KF     00:29.960    KF     06:58.014
SFTC 00:18.878    SFTC 06:06.897


Here is the source as a QtCreator project, compiles on Linux and Windows.

You will find all of the test files and comparison images in the zip file, all tests are @ 640x360

This is still very beta so a few menu items are not hooked up, no animating, no palette dialog and the interface will undoubtedly change

And a BIG BIG thanks to knighty for helping with the windows debugging and static arprec lib  

EDIT: corrected times, tested with the same iteration limit.

[Kalles Fraktaler]

That looks like really good render times, comparable with Mandel Machine!

Are you using SIMD?
Have you also implemented Pauldelbrot's glitch detection and automatic glitch solving?
 

[3dickulus]

my math skills are rudimentary, I'm a hacker at heart and just can't leave it alone
I'm pretty sure that I have not implemented Pauldebrot's glitch detection correctly, at best not the way intended.
The reference point is selected as per the original Java SFT code with an extra "hunt and peck" sort of method devised by me that doesn't catch them all by any stretch of the imagination.

SIMD? I'm just using standard gcc++ with no special asm coding or options other than what is presented by QtCreator when generating the project, seriously, nothing special here.

Using double and long double with arprec for the big stuff.

[simon.snake]

Here is the source as a QtCreator project, compiles on Linux and Windows.

Would love to compile this to run on the Symbian S^3 Operating system (the one on my ancient Nokia N8 phone) but I haven't got the faintest idea how to accomplish this.

Any ideas?

If it is not simple I wonder if someone who knows could spare some time or give some great pointers on how to achieve this.

Many thanks.

[Kalles Fraktaler]

Pauldelbrot's glitch detection method makes it possible to identify incorrect pixels and add additional references and recalculate the pixels that were previously incorrect.
So, if the calculation of the references takes a significant amount of the total time, additional references will make a big difference.
And if you are using a maximum iteration number that is several times higher than the highest pixel in a location, the time to render the image will be even much slower for each additional reference.
And also, this glitch detection method needs to be checked for every iteration, so some of the standard Mandelbrot optimizations are not possible.

But it is indeed possible to make a program faster than KF
1. SIMD!
2. Faster binary based ap (which I think is what you have?)
3. More terms in SA
But if your program doesn't take the glitches into account, you should compare it with Mandel machine instead because it is not doing the same things as KF does.

I was doing Symbian some years ago. But.... Nokia and Symbian are so outdated these days with iPhone and android...