======================================================= DOS Fractint error. Horizontal streaks in fractal in View Window. This is a zoom out to the parent fractal of Jim Muth's FOTD 07-05-09 displayed in a View Window. As the View Window size is increased by changing the Size Reduction Factor from 8 to 6 to 4 the number of horizontal streaks decreases. The fractal calculates correctly when the View Window is turned off. Parm file is below. I use the View Window a lot, but I don't see this too often. I had thought that passes=1 kept these streaks from appearing... Does anyone have any ideas what causes these horizontal streaks when using the View Window and how to avoid them? - Hal Lane ######################### # hallane@earthlink.net # ######################### BEGIN PARAMETER FILE========================================= ImagInterlude_Err { ; Hal Lane 07-05-09 3.3 P400 128x96 ; DOS Fractint error. Horizontal streaks ; in fractal in View Window. Zoom out to ; parent fractal of Jim Muth's FOTD 070509 reset=2004 type=formula formulafile=_m.frm formulaname=mandautocritinz function=recip passes=1 center-mag=3.63798e-012/-1.81899e-012/6.832e-005 params=-5/-1.1/-1/-5.5/0/-40/0/0 float=y maxiter=1600 inside=fmod proximity=1 periodicity=10 viewwindows=8/0.75/yes/0/0 sound=off colors=000WY8WZ4<2>HCE<2>GEJGFKEEo<3>8Ni7Ph5Rg<2>1Xc<3>\ 6gf7jg8lg<2>Bti<8>BRoBOpBLq<3>B8s<5>UHnYJm`Kl<3>lQiQV5<\ 3>dQNhPRlOWpN_sMc<3>lSbjTbiUa<2>dYabZa`aZ<3>dVieTlfSngQ\ qhOtgLy<7>lUflVdmWb<3>o_UrcR<7>aNW_LXYJX<2>SDZQB_MGKO9_\ <3>U7ZV7Z000QSq<3>DEmAAl76k43j<2>25N25G38F<3>7JC8LB9OAA\ RABTA<3>FdUGgZGjcHmhIpm<2>JzzUWV<2>z8f<3>bMYXPWRSU<2>Aa\ O<3>JhVLjXOkYQm_wzaUpbWrdzzzXqb<6>VgNUeKUdI<3>TZ9<4>TUC\ TTDTSD<2>TPFTOFVQD<4>__7`a6ac5<3>ej0<3>mT1oP1qL1<2>w81<\ 3>u67t69t6A<8>e9ccAgaAj<2>XBtWBwWDr<8>WUG000 } frm:MandAutoCritInZ {; Jim Muth a=real(p1), b=imag(p1), d=real(p2), f=imag(p2), g=1/f, h=1/d, j=1/(f-b), z=(((-a*b*g*h)^j)+(p4)), k=real(p3)+1, l=imag(p3)+100, c=fn1(pixel): z=k*((a*(z^b))+(d*(z^f)))+c, |z| < l } END PARAMETER FILE========================================= No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.8/797 - Release Date: 5/10/07 5:10 PM
On Fri, 2007-05-11 at 14:37 -0400, Hal Lane wrote:
As the View Window size is increased by changing the Size Reduction Factor from 8 to 6 to 4 the number of horizontal streaks decreases.
The fractal calculates correctly when the View Window is turned off. Parm file is below.
Increase periodicity to 15.
I had thought that passes=1 kept these streaks from appearing...
No, the periodicity checking is failing. Periodicity is checking to see if the iteration is converging. By increasing the periodicity, the X and Y values of the iterations must be closer together for the check to decide that periodicity has been detected. We do this because if the iteration is periodic (moves around in a circle), we can be relatively assured that the iteration will not escape. Hence the pixel is in the lake. A good description of this is in the "Periodicity Logic" section of the Fractint documentation. Jonathan
Jonathan Osuch wrote:
A good description of this is in the "Periodicity Logic" section of the Fractint documentation. I'm familiar with the periodicity method, but I had forgotten what the *failure* of the periodicity algorithm *looked like*.
What a periodicity failure looks like and what to do about it would be nifty to put into the docs sometime... If I understand this correctly, Fractint first calculated a pixel that was in the 'lake.' Because of this the periodicity algorithm with Jim Muth's setting of periodicity=10 was switched on. The algorithm goofed and incorrectly claimed that the next pixel was in the 'lake.' The algorithm then kept on making the same error all across the horizontal line of pixels in part because it still 'thought' it was in the 'lake' when it was not. At some point the periodicity checking got it right at the same time that a pixel was not in the 'lake.' The periodicity checking was then turned off and the horizontal line of lake color stopped being produced. Is this correct? Both periodicity=0 and periodicity=15 fix the artifact. While searching on "periodicity=" in the docs I ran across: "The inside=atan option should only be used with periodicity=0." and: "Type lambdafn function=exp needs periodicity turned off to be accurate -- there may be other cases." and: "...in some cases a better quality image will be obtained if you turn off periodicity checking with "periodicity=no"; for instance, if you use a high number of iterations and a smooth colormap." I wonder if Fractint enforces the first two restrictions? Thanks Jonathan. Thanks Lee. - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # ######################### No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.8/797 - Release Date: 5/10/07 5:10 PM
Hal,
What a periodicity failure looks like and what to do about it would be nifty to put into the docs sometime...
I'll add it. Thanks for the suggestion.
If I understand this correctly, Fractint first calculated a pixel that was in the 'lake.' Because of this the periodicity algorithm with Jim Muth's setting of periodicity=10 was switched on. The algorithm goofed and incorrectly claimed that the next pixel was in the 'lake.'
The algorithm then kept on making the same error all across the horizontal line of pixels in part because it still 'thought' it was in the 'lake' when it was not. At some point the periodicity checking got it right at the same time that a pixel was not in the 'lake.' The periodicity checking was then turned off and the horizontal line of lake color stopped being produced.
Is this correct?
Yes, that is correct. Also, the periodicity checking gets reset at the beginning of each horizontal line.
Both periodicity=0 and periodicity=15 fix the artifact.
Turning periodicity off is the better solution, as long as you don't need the periodicity checking because you have a lot of pixels in the lake along with a high iteration count.
While searching on "periodicity=" in the docs I ran across: "The inside=atan option should only be used with periodicity=0." and: "Type lambdafn function=exp needs periodicity turned off to be accurate -- there may be other cases."
I wonder if Fractint enforces the first two restrictions?
No to both. Although it would be possible to force periodicity off in these two cases, it would be ugly. If you momentarily change to inside=atan, then move on to another inside= option, how would the periodicity get reset? I did just look at this for inside=atan with the default mandelbrot and I think it needs to be added. There is a vast difference in the appearance of the image. And, using periodicity=15 (increasing periodicity) isn't an acceptable solution in this case. I'll put a fix in my next patch, which should be out in the next week or two. Jonathan
I did just look at this for inside=atan with the default mandelbrot and I think it needs to be added. There is a vast difference in the appearance of the image [depending on the periodicity setting]. ...I'll put a fix in my next patch...
I just calculated the default Mandelbrot with periodicity both 'off' and 'set to the default', one. I was amazed at the profound difference between the two images. The buds around the main bay in the default periodicity=1 fractal contain a single 'fan' shape, instead of the correct 'chrysanthemum' shape that mirrors the pattern in the main bay. A really surprisingly large difference. ...And the 'chrysanthemum' in the main bay is also distorted. A particularly nasty aspect of this particular artifact is that the incorrect pattern in the bays does not look like an artifact... I just tried lambdafn function=exp with the periodicity both turned off and set to the default of one. I was not able to see any obvious difference between the two default images at 1024 x 768 or after one maximum zoom into the center of a four-branched pinwheel. I did not use the debug= method of fractal image comparison.
What a periodicity failure looks like and what to do about it would be nifty to put into the docs sometime...
I'll add it. Thanks for the suggestion.
Thanks for looking further into periodicity and taking action. - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces+hallane=earthlink.net@mailman.xmission.com [mailto:fractdev-bounces+hallane=earthlink.net@mailman.xmission.com]On Behalf Of Jonathan Osuch Sent: Saturday, May 12, 2007 6:48 AM To: Fractint developer's list Subject: Re: [Fractdev] <Jonathan><Lee>DOS Fractint rendering error FIXED
Hal,
What a periodicity failure looks like and what to do about it would be nifty to put into the docs sometime...
I'll add it. Thanks for the suggestion.
If I understand this correctly, Fractint first calculated a pixel that was in the 'lake.' Because of this the periodicity algorithm with Jim Muth's setting of periodicity=10 was switched on. The algorithm goofed and incorrectly claimed that the next pixel was in the 'lake.'
The algorithm then kept on making the same error all across the horizontal line of pixels in part because it still 'thought' it was in the 'lake' when it was not. At some point the periodicity checking got it right at the same time that a pixel was not in the 'lake.' The periodicity checking was then turned off and the horizontal line of lake color stopped being produced.
Is this correct?
Yes, that is correct. Also, the periodicity checking gets reset at the beginning of each horizontal line.
Both periodicity=0 and periodicity=15 fix the artifact.
Turning periodicity off is the better solution, as long as you don't need the periodicity checking because you have a lot of pixels in the lake along with a high iteration count.
While searching on "periodicity=" in the docs I ran across: "The inside=atan option should only be used with periodicity=0." and: "Type lambdafn function=exp needs periodicity turned off to be accurate -- there may be other cases."
I wonder if Fractint enforces the first two restrictions?
No to both. Although it would be possible to force periodicity off in these two cases, it would be ugly. If you momentarily change to inside=atan, then move on to another inside= option, how would the periodicity get reset?
I did just look at this for inside=atan with the default mandelbrot and I think it needs to be added. There is a vast difference in the appearance of the image. And, using periodicity=15 (increasing periodicity) isn't an acceptable solution in this case. I'll put a fix in my next patch, which should be out in the next week or two.
Jonathan
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.8/797 - Release Date: 5/10/07 5:10 PM
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.8/797 - Release Date: 5/10/07 5:10 PM
Hal, You can get rid of the streaks by setting periodicity=0 or periodicity=no. Lee
participants (3)
-
Hal Lane -
Jonathan Osuch -
Lee H. Skinner