CUDA Y.A.M.Z

[knighty]

(...) with that you can just load the project, compile it and make any adjustments you want to the GUI or source code.

Unfortunately, that's not that obvious for most people. 

I am currently fiddling with glitch detection, peanuts, large antlers and kidneys are easy but tiny antlers and single pixels are a bit more involved, v63 (currently on web site) is pretty good but needs improvement. Sometimes find a single pixel and re-render only find it's still there, I think it's because the x,y coords of a pixel are too coarse to nail the reference that may be at a sub-pixel level when working with lower screen resolutions, maybe need to try a couple of locations within a pixel to get the right ref. hack hack hack...

Or use the "find best reference point" feature again?

[3dickulus]

am using the rendered data by flagging pixels with a value that would never be rendered and scanning the buffer for that value, this means I can accumulate results, so for single pixels I think a 3rd routine specifically for that will be required, currently using straight line method for finding large blobs, a spiral method for finding smaller shapes, and I am thinking a more brute force method to nail down those rogue pixels, or cheating and blending single pixels with the surrounding 8.

[3dickulus]

@knighty

your version of the glitch detection/correction test http://www.fractalforums.com/announcements-and-news/superfractalthing-arbitrary-precision-mandelbrot-set-rendering-in-java/msg64527/#msg64527
seems to be the winner

Code:

#define EPSILON 1.0E-9
#define BIGNUM = 1.0/EPSILON;

           if((max(fabs(c-dx),fabs(ci-dxi))/max(fabs(dx),fabs(dxi)) < EPSILON) || 
	      (max(fabs(c+dx),fabs(ci+dxi))/max(fabs(dx),fabs(dxi)) > BIGNUM))

v0.65 coming soon...

EDIT:

the above works well but failed on some so I've modified it a bit, not sure if it was a typo in the email you sent me but this seems to work a little better...

Code:

#define EPSILON 1.0E-15
#define BIGNUM = 1.0/EPSILON;

           if(( min (fabs(c-dx),fabs(ci-dxi))/ max (fabs(dx),fabs(dxi)) < EPSILON) || 
	     ( max (fabs(c+dx),fabs(ci+dxi))/ min (fabs(dx),fabs(dxi)) > BIGNUM))

my value of 1.0E-9 was ok for the way I had it before (v64) but not this way

still testing...

[knighty]

I did some tests and it seems that:

Code:

if(modulus<1.E-10)

Gives the same results.

It also seems like SFTC is neglecting small islands of marked pixels.

[3dickulus]

I'll have to check that, so to be clear, check modulus var against EPSILON instead of ...

Code:

if((max(fabs(c-dx),fabs(ci-dxi))/max(fabs(dx),fabs(dxi)) < EPSILON) || 
	      (max(fabs(c+dx),fabs(ci+dxi))/max(fabs(dx),fabs(dxi)) > BIGNUM))

that would speed things up a bit, maybe making room for tighter test length for a given area.

cheers 

[3dickulus]

I did some tests and it seems that:

Code:

if(modulus<1.E-10)

Gives the same results.

It also seems like SFTC is neglecting small islands of marked pixels.

testing like that is how I found Pickover's stalks

I have set EPSILON at 1.0E-15 with the current test and it either catches more or makes fewer by iterating a bit more, v0.65 posted on my website has a better results than v0.64,
I do think there must be a way, after approximating some iterations and before iterating the final amount, to predict for trending toward EPSILON or BIGNUM,
I will be trying the above this evening and I'll post any results.

The islands missed might be due to testing for areas larger than 20 pixels and then immediately dropping down to 1 pixel and trying to find the highest iteration count for a new reference, maybe decrementing the testLength by n pixels each pass until testLength reaches 1 pixel. I also found that checking for 1 pixel and making that a reference may or may not fix that pixel.

PS frequency, amplitude, ramping, offset RGB palette dialog is nearly done 

[3dickulus]

@knighty it does work but not as well as your other longer test, I haven't tested extensively but on the files in the glitches folder it leaves more unresolved and not flagged.
I also note that many of the files in the glitches folder just need a higher iteration_limit and most spots get resolved, it's not perfect but working quite well  

here's a preview of the palette widget I resurrected from my antique fractal prog, the hidden tab is the same but for offset control, the visible tab shows the frequency, amplitude and ramping (rotation angle) slider controls for RGB spreads, the mouse is used to draw lines or portions of lines to alter parts of the sin wave.

[knighty]

Wow! That palette editor looks good.

@knighty it does work but not as well as your other longer test, I haven't tested extensively but on the files in the glitches folder it leaves more unresolved and not flagged.

I think that's just a matter of epsilon.

Reason why I suggested the simple test: c is constant inside the loop. As it's name suggest it is the 'c' value of the current pixel. So the (long) test consist on checking when d is close to 0 (so we go past BIGNUM) or close to c. But whenever d is near 0, it's next iterate will necessarily be near c. So, in principle, it's not necessary to do both tests... just test when d is close to 0.

IIRC, in Pauldelbrot's test formula:
|zn+dn|/|zn|;
zn is the reference and dn is the delta.

This is a little bit different from your test. Some of the glitches, the most difficlut to spot because they give believable results, happen very soon in the iteration process.
Also, Some glitches are due to the series approximation.

I also note that many of the files in the glitches folder just need a higher iteration_limit and most spots get resolved, it's not perfect but working quite well 

Yes. Is it possible to detect automatically such cases?

[3dickulus]

The palette editor is from my original fractal prog, FracForm, written on my Commodore Amiga using SAS-C compiler, the last incarnation was 2001, I really like it because you can get amazing palettes with a few clicks and twiddles, originally 256 colors so I'm trying to adapt it to 32 bit color.

 

Yes. Is it possible to detect automatically such cases?

this is where my math skills prove I'm a high school drop-out

test for insufficient iteration_limit ? I'm not sure, the only test I can think of is if exceeding then bump it up, but that could go on for ever...

I think the best I've heard is from claude..

What I do in mightymandel[1] is to compute the reference in parallel with the pixel iterations, interleaved in blocks - so I compute the next N reference values, then step all the pixels N iterations, and repeat.  This way I don't need to guess how many iterations of the reference might be needed in advance, and I don't have to store the whole reference orbit in memory at once.

[1] https://gitorious.org/maximus/mightymandel (specifically https://gitorious.org/maximus/mightymandel/source/HEAD:src/fpxx_step.c#L106 )

seems a most efficient method.

this pic is a test using a combination, basically testing all variable results inside the loop to be within the range EPSILON to BIGNUM, so checking modulus and using the long test, I know it seems redundant but I think that using just one test will still miss things as each test will have a slightly different dynamic under different conditions.

[3dickulus]

The palette editor is in V0.66 not loading and saving yet but seems to work.

My storage scheme for palette data is this: use an image where the width is the number of colors in the palette and concatenate additional palettes as lines of the image, so, in theory, you can use any line in any image as a palette, maybe even transition between each line/palette over n frames...

...just a thought 

[3dickulus]

hmm.. seems to be some differences between the way win and lin handle window modality and GL refresh, sometimes the screen is not updated properly, try hitting Refresh again if it's blank or no change after loading a settings file or palette adjustments... hack hack hack...

[knighty]

Looks good! downloading right now...
BTW, There is a problem when trying to zoom past 1.E308 or so. That was very difficult to find where things are going wrong. It looks like extra exponent is not handled correctly in the engine part. I could fix the zoom (and pan) problem by modifying the test here:

Code:

void Details::FillInCubic( mp_real pX, mp_real pY, int aIteration_limit, double aActual_width, int aSize_extra_exponent, double aScreen_offset_x, double aScreen_offset_y )
(...)

                    // The initial size was scaled up.
                    // Now we adjust the ABC coefficients to compensate for the scale.
                    // This will affect the accuracy test, and may allow us to continue
                    do
                    {
                        extra_exponent--;
                        A *= 0.10000000149011612D;
                        (...)
                        csq *= 9.999999747378752E-5D;

                        width *= 0.10000000149011612D;
                    } while (extra_exponent>0 && (csq >=accuracy*accuracy*asq) && csq!=0.0D);

The test was extra_exponent>=0 which introduces an extra 10 scale factor. I don't think it solves everything  . For example what happens if A,B and C are not scaled. Maybe, it is necessary to verify more in depth.

Feature request(s)   
- Make it update rendering automatically when double-clicking, loading, changing resolution... etc.
- import .kfr files. (SFTC's scale factor is just 4 times the inverse of KF's scale).
 
Some (manually) converted .kfr locations attached (and last Dinkydau's location that SFTC failed to render).

[3dickulus]

Added Auto Refresh to the options menu

I have pretty much left the internals of the engine alone, a little tinkering while converting over to ArPrec from the java version but since using long double it has been reasonably well behaved.

at the end of glwidget.cpp is where the extra_exponent is calculated before starting the engine, it was originally 1.0E-280 and after a little research, double has 52 mantissa bits and absolute max exponent of 324 and smallest accurately representable number = MaxExponent - mantissaBits = 272 so I think that value should be 1.0E-272 but I had been testing at 308 and it didn't seem to make much difference until zooming past E-2200 , I will make the adjustment you suggest re: >= and adjust extraExp test back to E-280 so it's not so close to the lower limit of double.

For example what happens if A,B and C are not scaled.

they don't need to be scaled when mSize > double MIN ? perhaps past 1.0E-272 small errors become catastrophic due to accumulation so starting the scaling there  would be a good thing ?

tnx for the zip and I'll look at kfr settings conversion.

[3dickulus]

Sircle @ 4.0E-650
you had it set at 500,000 so got black screen ? seems to render fine with my current incarnation, the other locations rendered ok too :O

this is what it looked like with some twiddling by the new palette editor, render time EDIT: 212:42.704 @ 1024x768 (finally!)

 edit: I think it's that bit in the middle 12,868,703 iterations!?!?

          it's getting there   but seems a bit noisey

[3dickulus]

Palette load and save work, it works so well I have to share, v0.67 is on my website, now housed in 3 files, source, win exe and win exe plus DLLs so if you already have the DLLs or Qt5.3 installed just grab the exe_only file and copy SFTC.exe to the folder with the DLLs.

Also loads .kfr files edit:clarification ... loads kfr settings from the main menu under File->Load Settings

the palette dialog will load the first line of any image and use it as an indexed color lookup array and save the current palette as a single line image in the format of your choice. here is an image and the palette that goes with it. each pixel is a key value, they get spread over the color map at the size you choose. edit:clarification up to 16777216