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