Logo by haltenny - 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: Support us via Flattr FLATTR Link
 
*
Welcome, Guest. Please login or register. January 17, 2018, 10:19:03 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 ... 7 8 [9] 10   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: compiling Kalles Fraktaler with mingw  (Read 5670 times)
Description: success report
0 Members and 1 Guest are viewing this topic.
Olbaid-st
Forums Newbie
*
Posts: 2


« Reply #120 on: October 10, 2017, 02:55:58 PM »

7000... The reference was not enough at all. (I calculated with 100) Thank you for detailed explanation and verification. I am glad that it will be possible to challenge a complicated pattern in future!
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #121 on: October 12, 2017, 04:14:51 PM »

Thanks for the update Claude.

The option of low glitch detection is very good!

Some things I noted:
Unfortunately the disabling of pixel guessing is increasing the render time...
The Newton-Raphson fails on deep simple locations, as I try to find the minibrot in the center of the attached location.

Thanks a lot!

* newton fails.kfr (15.56 KB - downloaded 22 times.)
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 #122 on: October 12, 2017, 04:48:00 PM »

Quote
Unfortunately the disabling of pixel guessing is increasing the render time...

True, especially for sparse locations - but it was causing incorrect output (bright speckles visible at low zoom levels, that change on each render, probably a race condition...) that I didn't find a way to fix while keeping guessing enabled.

Maybe I make guessing a user-settable option in the next release, if I haven't fixed it properly (not until next month at the earliest, busy with other things in the meantime...).

EDIT possibly I will rework the incremental calculations and guessing entirely, perhaps using something like Diamond-Square algorithm, example:
Code:
0 4 2 4 0
4 3 4 3 4
2 4 1 4 2
4 3 4 3 4
0 4 2 4 0
numbers are "pass number", a pixel at pass (n+1) can be "guessed" if all 4 of its "parents" (either + or x shape, depending on parity of n) at pass n or lower have identical integer iteration count ?  not sure exactly what the conditions are for guessing to be safe, I anticipate problems around the antenna and symmetrical structures (eg 4x symmetry on the way to a minibrot might incorrectly "guess" the center - perhaps make the center of the veiw always be in pass 0)...
the crucial part (and perhaps a reason for the speckles, if this is not satisfied by kf?) is that pass n must be 100% finished by all threads, before any thread can start pass (n+1)
(end EDIT)

Quote
The Newton-Raphson fails on deep simple locations, as I try to find the minibrot in the center of the attached location.

Much worse than that, loading this location gives a very bad render (see attached).  Zooming in or out gives something sensible.  No clue what is wrong at this stage. Thanks for the report, it is similar to the "no-newton.kfr" you posted before that is already in the known-bugs list. EDIT enabling "no approximation" (ie, disabling series approximation) makes both halves of the image wrong.  again zooming in or out makes it sensible again.  stranger and stranger... (end EDIT)


* newton fails.png (23.66 KB, 650x435 - viewed 28 times.)
« Last Edit: October 12, 2017, 10:27:27 PM by claude, Reason: series approximation makes the other half bad too » Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #123 on: October 12, 2017, 11:21:26 PM »

Not directly related to KF, but:

I have been doing some tests with my mandelbrot-perturbator and Olbaid-ST's "Deep Zoom 023" location (see previous page in this thread).  It seems the perturbator is ok with (squared magnitude) glitch threshold 1e-5, increasing it gives an identical image at 1024x1024, as can be seen here.  (The last digit is the 1e-# for the glitch detection threshold, the 1e-6 has glitches at the center of the 4 big features).

Code:
$ md5sum -b *1024*.ppm # number of references needed, real/user/sys time taken (on 4-core machine underclocked to 2.3GHz to avoid thermal shutdown, approx 2mins single-core overhead before all cores are used)
5d15ffb080f48caa4e68f086db5352c9 *023-1024-3.ppm # 15346, 48m33, 164m53, 19s
5d15ffb080f48caa4e68f086db5352c9 *023-1024-4.ppm # 2928,  43m35, 148m38, 22s
5d15ffb080f48caa4e68f086db5352c9 *023-1024-5.ppm # 896,   42m44, 146m05, 19s
ba0f1f7bbc2e975963329eddafb9e26e *023-1024-6.ppm # 212,   42m07, 145m03, 29s

Note: perturbator uses the "rebasing to periodic reference near detected glitch" technique to avoid restarting iterations from scratch when adding a new reference in a glitch, this is why adding so many references is so cheap.  And the technique adds the reference in the semantic center of the glitch, ie, the minibrot that caused it.  Maybe it could be rendered correctly with much fewer well-chosen references, but I don't have that technology yet so this will do for now.


* 023-1024-3.jpg (244.89 KB, 1024x1024 - viewed 28 times.)
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #124 on: October 15, 2017, 03:35:54 PM »

Not directly related to KF, but:

I have been doing some tests with my mandelbrot-perturbator and Olbaid-ST's "Deep Zoom 023" location (see previous page in this thread).  It seems the perturbator is ok with (squared magnitude) glitch threshold 1e-5, increasing it gives an identical image at 1024x1024, as can be seen here.  (The last digit is the 1e-# for the glitch detection threshold, the 1e-6 has glitches at the center of the 4 big features).

Code:
$ md5sum -b *1024*.ppm # number of references needed, real/user/sys time taken (on 4-core machine underclocked to 2.3GHz to avoid thermal shutdown, approx 2mins single-core overhead before all cores are used)
5d15ffb080f48caa4e68f086db5352c9 *023-1024-3.ppm # 15346, 48m33, 164m53, 19s
5d15ffb080f48caa4e68f086db5352c9 *023-1024-4.ppm # 2928,  43m35, 148m38, 22s
5d15ffb080f48caa4e68f086db5352c9 *023-1024-5.ppm # 896,   42m44, 146m05, 19s
ba0f1f7bbc2e975963329eddafb9e26e *023-1024-6.ppm # 212,   42m07, 145m03, 29s

Note: perturbator uses the "rebasing to periodic reference near detected glitch" technique to avoid restarting iterations from scratch when adding a new reference in a glitch, this is why adding so many references is so cheap.  And the technique adds the reference in the semantic center of the glitch, ie, the minibrot that caused it.  Maybe it could be rendered correctly with much fewer well-chosen references, but I don't have that technology yet so this will do for now.
So you mean that 15346 reference took just some 15% longer than 212 references?
That is really cool, I hope you can add it in KF as well smiley
That would be cool if you could do that in KF as well, reusing the start for the addition of references!
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 #125 on: October 15, 2017, 05:23:22 PM »

So you mean that 15346 reference took just some 15% longer than 212 references?

Yes.  An example might help:  say you are using reference c0 and there is a glitch at iteration 12345, then the new reference c1 at the semantic center of the glitch (where z = 0, a minibrot nucleus) has period 12345 and has z = 0 at iteration 0, 12345, 24690, ...  As we are at iteration 12345, we can just adjust the delta c values by (c1 - c0), and leave the delta z values the same- they are near 0  (we found a glitch, remember) and surrounding the new reference c1 which has its z 12345 at 0.  By periodicity, we don't need to restart the iterations of the reference, its z is 0 after 12345 iterations anyway. So split the glitched pixels out into a separate batch with the new reference, the old reference is still used for the non-glitched pixels.  So the glitch correction happens at the same time as rendering, no separate passes afterwards.

To do this effectively you get a tree structure, where references spawn child references at glitches, etc.   Only the initial primary reference has series approximation applied.  mandelbrot-perturbator keeps a queue of references, with 1 worker thread per cpu core.  each worker grabs the next group of glitched pixels from the queue, and pushes any new glitches back into the queue.  And it uses the derivative to help refine the new references, as well as for de colouring.  Another thing is not computing the whole reference up front, I alternate in chunks, say 1000 reference iterations then 1000 delta iterations and so on, this avoids computing references for more iterations than necessary (and would also help with possible GPU porting - though the tree structure makes that harder).  The chunk size is user adjustable, maybe I can think about trying to add something to tune it automatically (if series approximation skips relatively few iterations compared to the first glitch iteration, you want the chunk size to be bigger, if there are glitches at many closely spaced iterations you want the chunk size to be smaller)

Quote
That is really cool, I hope you can add it in KF as well smiley
Well, it's a completely different approach to rendering, and that makes it very tricky to port into KF. Something for 2.13 perhaps, plenty of things to add to 2.12.x in the meantime.  Otherwise

Also it uses a lot of memory - 112 bytes per pixel for double, 208 bytes per pixel for long double and floatexp, though long double could be reduced to 136 bytes if the data is packed more densely, and floatexp to 160 bytes with packing (assuming 32bits is enough for the exponent, which it almost certainly is...).  this is not including the iteration output data, which is at least 11 bytes per pixel as it is in kf now, 15 bytes if you want de colouring too
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #126 on: October 20, 2017, 09:40:33 AM »

Hi Claude

Seems that perturbation does not work in "Mandelbar Celtic" formula since a couple of versions, see attachment.
Last version it worked was 4th of May...

* mandelbar celtic glitch.kfr (1.79 KB - downloaded 15 times.)
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 #127 on: October 20, 2017, 10:42:27 AM »

Seems that perturbation does not work in "Mandelbar Celtic" formula since a couple of versions, see attachment.

Fixed, will be in next release (probably start of November).  Was a pair of typos introduced when rewriting formulas into XML definition file.  Other formulas may be affected in similar ways, please audit if you have time...
Changeset for the fix: https://code.mathr.co.uk/kalles-fraktaler-2/commitdiff/652f88d8f379615b9466de157422b45a4c02454d
Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #128 on: November 02, 2017, 05:31:29 PM »

https://mathr.co.uk/kf/kf.html 2.12.5 released

highlights include command line rendering and settings save/load, along with many bugfixes - full changelog on the website.  see the last page of the manual for details on the command line rendering

thanks to Fractal universe, Kalles Fraktaler, Foxxie, quaz0r and gerrit for bug reports and suggestions that helped with this release.
Logged
CFJH
Alien
***
Posts: 31


« Reply #129 on: November 12, 2017, 09:58:26 PM »

Hallo,

first thanks to claude and kalle for the great work.

But currently I've some minor problems with kf2.

First prob is the digit resolution of the variable 'zoom' in the .kfr and .jpg-files. Currently it is stored with only three digits in the mantissa, older versions use much more digits.

version 2.11.1
Code:
Re: -0.65157218235452725030768117482098390670760715019132826658222
Im: -0.47694074025720722086380813129121112613534292138926326653662
Zoom: 4.95176015714E27
Iterations: 4122

version 2.12.5
Code:
Re: -0.2281554936539618192145720140991.....
Im: 1.1151425080399373597457646363150140.....
Zoom: 1.70e3016
Iterations: 1000000

My problem is, that I've not enough disk space to render the zoom at once. first I rendered 1e2000 to 0, then 1e3000 to 1e2000 (pressing key esc at 1e2000 to stop). The images at 1e2000 are slightly different by zoom factor 0.02. Not much, but enough to see it. I think, it comes from the lower resolution of the zoom variable.

Suggestion1: when rendering the zoom out images, to enter a zoom-factor, where the rendering should stop (instead rendering to zoom-factor 0).
Suggestion1b: for my special case, I don't need the .kfb-files, but these are causing my disk space probs. A question to store them would be great (like the png and jpg-files) (making one dialog with thee checkboxes to select, what should be saved).

Prob2: On special locations kf renders endless references and comes to no end (attachment kf_references01.png).
Prob3: Lines in the rendering (kf_lines.png, tested with kf 2.12.4)

Suggestion2: The crosshair cursor is on some colors badly to see, maybe to use one with more contrast.




* kf_references01.png (174.48 KB, 672x456 - viewed 11 times.)

* kf_lines.png (66.68 KB, 672x456 - viewed 12 times.)
« Last Edit: November 12, 2017, 10:06:26 PM by CFJH » Logged

claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #130 on: November 13, 2017, 06:13:20 PM »

Thanks for your bug reports and feature requests!

First prob is the digit resolution of the variable 'zoom' in the .kfr and .jpg-files. Currently it is stored with only three digits in the mantissa, older versions use much more digits.

Good point, I will try to fix this for the next release.  Added to BUGS list.  EDIT fixed, will be in next release

Quote
Suggestion1: when rendering the zoom out images, to enter a zoom-factor, where the rendering should stop (instead rendering to zoom-factor 0).
Suggestion1b: for my special case, I don't need the .kfb-files, but these are causing my disk space probs. A question to store them would be great (like the png and jpg-files) (making one dialog with thee checkboxes to select, what should be saved).

Added to TODO list. EDIT I made another dialog pop up asking whether to save KFB maps. Unfortunately this (not saving KFB) currently breaks "resume zoom sequence", trying to fix it now... EDIT2 resume sequence now works if you go through some hoops: 1. examine zoom sequence without saving KFB, but saving PNG or JPEG or both; 2. press ESC to abort when you want to stop; 3. "file->save map" to "recovery.kfb" in the output directory; 4. if the last images rendered are the same as your just saved recovery.kfb, delete them; 5. make a backup of recovery.kfb, it will be deleted by the next step; 6. resume zoom sequence should now continue from the recovery.kfb

Quote
Prob2: On special locations kf renders endless references and comes to no end (attachment kf_references01.png).
Prob3: Lines in the rendering (kf_lines.png, tested with kf 2.12.4)

Can you provide the location information (.kfr) so I can debug these?  Added both to BUGS list but without the ability to reproduce chance of a fix is small. EDIT 2.12.5 should have fixed most problems with endless references EDIT2 I see simular lines when rendering a zoom out sequence, but they are corrected by the time the image is saved to disk

Quote
Suggestion2: The crosshair cursor is on some colors badly to see, maybe to use one with more contrast.

Added to TODO list. EDIT the crosshair is a built in cursor it seems, there is a custom cursor for rotation that seems to be higher contrast, so maybe I can adapt that code.  But on my system (WINE on Debian) it is black with a white border, can't get much more high contrast than that! see attached


* high-contrast-crosshair-by-default-on-wine-on-debian.png (152.2 KB, 650x435 - viewed 11 times.)
« Last Edit: November 14, 2017, 04:11:41 AM by claude, Reason: added crosshair image » Logged
CFJH
Alien
***
Posts: 31


« Reply #131 on: November 18, 2017, 02:28:37 PM »

Thanks for your bug reports and feature requests!

Good point, I will try to fix this for the next release.  Added to BUGS list.  EDIT fixed, will be in next release
Thx!
Quote
Added to TODO list. EDIT I made another dialog pop up asking whether to save KFB maps. Unfortunately this (not saving KFB) currently breaks "resume zoom sequence", trying to fix it now... EDIT2 resume sequence now works if you go through some hoops: 1. examine zoom sequence without saving KFB, but saving PNG or JPEG or both; 2. press ESC to abort when you want to stop; 3. "file->save map" to "recovery.kfb" in the output directory; 4. if the last images rendered are the same as your just saved recovery.kfb, delete them; 5. make a backup of recovery.kfb, it will be deleted by the next step; 6. resume zoom sequence should now continue from the recovery.kfb
The Option, don't save the .kfb-files is not prio 1 for me. When it makes problems, don't change anything there.
More important to me is the option to enter a stop-zoomfactor where the zoom out sequence stops. (My computer is nearly 10 years old and I've render the zoom in parts...)
Quote
Can you provide the location information (.kfr) so I can debug these?  Added both to BUGS list but without the ability to reproduce chance of a fix is small. EDIT 2.12.5 should have fixed most problems with endless references EDIT2 I see simular lines when rendering a zoom out sequence, but they are corrected by the time the image is saved to disk
Currently I can't give a location. The problem is, that I could reproduce the problem many times, but when I save to location to an .kfr-file and reloads it, the render finishes after a few references. Maybe the problem occurs in conjunction with the images rendered before (?)
Quote
Added to TODO list. EDIT the crosshair is a built in cursor it seems, there is a custom cursor for rotation that seems to be higher contrast, so maybe I can adapt that code.  But on my system (WINE on Debian) it is black with a white border, can't get much more high contrast than that! see attached

Jürgen
Logged

claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #132 on: November 22, 2017, 11:56:27 PM »

Thx!The Option, don't save the .kfb-files is not prio 1 for me. When it makes problems, don't change anything there.

I think it will be useful to other people too, so I keep it.  I just need to fix "resume zoom sequence" so that it will still work without the KFB maps, maybe I save a special last.kfb for the sequence just so that it is possible to resume...

Quote
More important to me is the option to enter a stop-zoomfactor where the zoom out sequence stops.

I added a feature to control how many images are saved, or whether to use the previous behavior (stop at zoom 0).  This is different to setting a zoom factor, but may have the same end result.  You might need a calculator to convert between number of frames and zoom factor, taking into account the per-frame zoom size.  I think the formula should be:

INPUT
start at zoom (A)e(a)
end at zoom (B)e(b)
zoom size (Z)

ALGORITHM
let x = a + log10 A
let y= b + log10 B
let z = log10 Z
let n = (x - y) / z

OUTPUT
integer part of n

EXAMPLE
start 3.2e2000
end 1.4e1000
zoom size 2.0
x = 2000 + log10 3.2 = 2000.5051499783199
y = 1000 + log10 1.4 = 1000.1461280356782
z = log10 2 = 0.30102999566398114
n = (x - y) / z = 3323.1207399653053
So in this example you would set the stop frame count to 3323


I made a new "store zoom sequence" dialog, see attached - thanks for the suggestion!


* store-zoom-sequence.png (0.86 KB, 174x176 - viewed 55 times.)
Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #133 on: November 23, 2017, 08:07:57 AM »

Quote
The Newton-Raphson fails on deep simple locations, as I try to find the minibrot in the center of the attached location.

Much worse than that, loading this location gives a very bad render (see attached).  Zooming in or out gives something sensible.

I fixed both these bugs by switching from GMP mpf_t to MPFR.  It may be slightly slower, but it works correctly so I guess that's the price to pay.  I suspect a bug in GMP's mpf_sub Something was messing up the GMP data structures, maybe bug in GMP or Boost or KF, in some circumstances it seems values were not properly normalized, causing catastrophic precision loss in later operations...
« Last Edit: November 24, 2017, 03:00:33 PM by claude, Reason: probably not a bug in mpf_sub, as the input was already bad » Logged
CFJH
Alien
***
Posts: 31


« Reply #134 on: November 23, 2017, 10:30:39 PM »

Hello

Thx for the stuff. The 'Stop after n images' is ok to me.  smiley
Is there a plan, when it will be released ?

But now I've discovered another ugly bug.
I'm running kf 2.12.5 on Suse Linux leap 42.2 with wine. When I'm creating a zoom out sequence and minimize the kf-window during the process, only black images are saved (as jpeg). On kf 2.12.4 the same image is repeated. When I show the kf-window, the images are saved ok.
See attachment.

Jürgen
www.wetterstation-porta.info


* kf_mimimized_error.jpg (58.2 KB, 552x420 - viewed 4 times.)
Logged

Pages: 1 ... 7 8 [9] 10   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Kalles Fraktaler 2.7.4 available Kalles Fraktaler Kalles Fraktaler 10 806 Last post November 30, 2014, 01:40:48 PM
by ratcat65
Kalles Fraktaler 2.7.6 available Kalles Fraktaler Kalles Fraktaler 14 2400 Last post December 15, 2014, 03:15:31 AM
by quaz0r
Kalles Fraktaler 2.7.7 available Kalles Fraktaler Kalles Fraktaler 7 1015 Last post January 23, 2015, 12:39:28 PM
by Chillheimer
compiling Kalles Fraktaler 2.7.3 on Linux with mingw Kalles Fraktaler « 1 2 » claude 24 1534 Last post December 31, 2014, 12:42:33 PM
by Kalles Fraktaler
compiling Kalles Fraktaler with GCC Kalles Fraktaler 3dickulus 0 464 Last post January 03, 2015, 09:13:24 PM
by 3dickulus

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