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