[Fractint] Re: Fractint Mystery
################################################ Forwarding this bug reported by jackoftradez to the development group. - Hal Lane ######################### # hallane@earthlink.net # ######################### ################################################
Date: Tue, 10 Apr 2007 03:14:32 +0000 From: jackoftradez@comcast.net Subject: [Fractint] Re: Fractint Mystery To: fractint@mailman.xmission.com Message-ID:
Anyone who has seen my deep zoom viddies has noticed the occasional jerk frames. I do not know what causes this, but it seems that fractint reads the PAR file wrong and scrambles the numbers for some reason. Thus with off-parameters or coordinates the image(s) are a bit distorted or off center.
Now, attempting a zoom animation of Muth FOTD 3_15_07 I have encountered this again, only the error occurs in the magnification number - the first time I have seen this! I need someone to verify that I am not hallucinating. Here are PARS for 3 images in the sequence:
'''''''''''''''''''''''''''''''''''''''''''START PAR''''''''''''''''''''
782.0000 { ; reset=2004 type=formula formulafile=allinone.frm formulaname=mandelbrotbc2 passes=1 center-mag=-0.63982851388294900/+1.17265143805666000/1.35148269130032e+12 params=1.5/0/85/0 float=y maxiter=5000 inside=0 periodicity=10 }
783.0000 { ; reset=2004 type=formula formulafile=allinone.frm formulaname=mandelbrotbc2 passes=1 center-mag=-0.63982851388294900/+1.17265143805666000/1.37763961568162e+12 params=1.5/0/85/0 float=y maxiter=5000 inside=0 periodicity=10 }
784.0000 { ; reset=2004 type=formula formulafile=allinone.frm formulaname=mandelbrotbc2 passes=1 center-mag=-0.63982851388294900/+1.17265143805666000/1.40426842987625e+12 params=1.5/0/85/0 float=y maxiter=5000 inside=0 periodicity=10 }
frm:MandelbrotBC2 { ; by several Fractint users e=p1, a=imag(p2)+100, p=real(p2)+PI q=2*PI*floor(p/(2*PI)), r=real(p2)-q Z=C=Pixel: Z=log(Z) IF(imag(Z) > r) Z=Z+flip(2*PI) ENDIF Z=exp(e*(Z+flip(q)))+C |Z| < a }
''''''''''''''''''''''''''''''''END PAR''''''''''''''''''''''''''''''''''''''
You clearly see the mag factors are 1.35e+12, 1.37e+12, and 1.40e+12 respectively. The first and last render correctly, but the middle one ends up with a mag factor of 6.88e11 ! Why is this and where does the number come from? It is totally reproduceable too!
You dont have to render the entire image (they take awhile). Just a couple lines then hit TAB key to see the numbers.
A clue might be that this only occurs in the last third of the sequence - beyond e12. There are so many messed up frames an otherwize awesome zoom is not now good for posting!
Whoever solves the mystery gets a free DVD!
Cheers
JoTz
################################################ -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.0.0/754 - Release Date: 4/9/07 10:59 PM
In article <MDBBJLBFBICIIEIHFBMEMELCDAAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
Forwarding this bug reported by jackoftradez to the development group.
Thanks Hal. I did see this and put it in my bugs folder to look at. I think its just a bug in the deep zoom parameter parsing. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
On Wed, 2007-04-11 at 10:23 -0600, Richard wrote:
Forwarding this bug reported by jackoftradez to the development group.
Thanks Hal. I did see this and put it in my bugs folder to look at. I think its just a bug in the deep zoom parameter parsing.
I don't think it's that simple. He is using a formula, therefore, the ap math isn't used. If new PARs are created from his PARs, the Magnification gets truncated, but that's a separate issue. Didn't try creating GIFs. Also, I tried his PARs and didn't see the problem he describes with either DOS Fractint or Xfractint. Jonathan
Also, I tried his PARs and didn't see the problem he describes with either DOS Fractint or Xfractint. <<
I tried his pars with DOS Fractint, and DID see the problem. The middle (783.0000) par's magnification does get changed - you can see it on the tab screen. I thought it may be related to math tolerance, but adding math tolerance to the par didn't help. Lee Skinner
Lee,
Also, I tried his PARs and didn't see the problem he describes with either DOS Fractint or Xfractint. <<
I tried his pars with DOS Fractint, and DID see the problem. The middle (783.0000) par's magnification does get changed - you can see it on the tab screen. I thought it may be related to math tolerance, but adding math tolerance to the par didn't help.
Please take a look at the value on the "z" then F6 screen. The value on the tab screen gets truncated to 7 or 8 digits. Also, if you could, try it with Fractint for Windows. This is based on a new source than what you currently have for Fractint. Jonathan
Lee,
Also, I tried his PARs and didn't see the problem he describes with either DOS Fractint or Xfractint. <<
I tried his pars with DOS Fractint, and DID see the problem. The middle (783.0000) par's magnification does get changed - you can see it on the tab screen. I thought it may be related to math tolerance, but adding math tolerance to the par didn't help.
It's related to screen resolution. At 1024x768, the middle one is bad. At 1600x1200, all are bad. At 2048x2048, the first two are bad. Jonathan
Lee,
I tried his pars with DOS Fractint, and DID see the problem. The middle (783.0000) par's magnification does get changed - you can see it on the tab screen. I thought it may be related to math tolerance, but adding math tolerance to the par didn't help.
See my response on the Fractint List. When I first tried this, it didn't work for me either. The mathtolerance parameter has to be added to the original PARs, since once they are read into Fractint, they are messed up. I think what is happening is that Fractint is converting the coordinates to ap math because of the nearness to the fp math limit. Then, swapping back to fp math introduces an error. I'll have to look at this closely. Jonathan
Tim,
I think what is happening is that Fractint is converting the coordinates to ap math because of the nearness to the fp math limit. Then, swapping back to fp math introduces an error. I'll have to look at this closely.
Do you recall what ratio_bad() and the calls to it are doing in fracsubr.c? It seems to be at the root of the problem. Using debugflag=3400 also fixes the problem. Jonathan
Jonathan asked:
Do you recall what ratio_bad() and the calls to it are doing in fracsubr.c? It seems to be at the root of the problem. Using debugflag=3400 also fixes the problem.
I do recall generally and could investigate it, but let me say this: there is absolutely no reliable way to automatically detect when the limit of precision for a fractal is reached with a particular type of math, especially with all the zoom box flexibility that we have (skewed, rotated, etc.) but also because it depends on the algorithm that is being iterated. I think you will find that if the ratio_bad logic is fixed for one fractal it will be broken for another. Or it will work, and the zoom box is broken, then it will break. Fractal artists who live at the edge of precision toggles and want their PAR files reproducable need to consider forcing the type of math. It's been a while, but I assume that we have sufficient controls to do that. The above comments should not be taken to mean that I oppose trying to improved automatic detection of precision failure, just that I know it's a very tough problem. Tim
Tim,
Do you recall what ratio_bad() and the calls to it are doing in fracsubr.c? It seems to be at the root of the problem. Using debugflag=3400 also fixes the problem.
I do recall generally and could investigate it, but let me say this: there is absolutely no reliable way to automatically detect when the limit of precision for a fractal is reached with a particular type of math, especially with all the zoom box flexibility that we have (skewed, rotated, etc.) but also because it depends on the algorithm that is being iterated.
Granted. However, we aren't looking at a case where a change in the type of math is even possible (fp to ap, if it were possible). It shouldn't be necessary to use mathtolerance=0.05/1 (or debugflag=3400) to make Fractint generate the correct image.
I think you will find that if the ratio_bad logic is fixed for one fractal it will be broken for another. Or it will work, and the zoom box is broken, then it will break.
Fractal artists who live at the edge of precision toggles and want their PAR files reproducable need to consider forcing the type of math. It's been a while, but I assume that we have sufficient controls to do that.
Yes, we have sufficient controls, I just don't see why it should be necessary in this case.
The above comments should not be taken to mean that I oppose trying to improved automatic detection of precision failure, just that I know it's a very tough problem.
I suspect the problem we are seeing is caused by line 471 in fracsubr.c, where we goto expand_retry because one of the calls to ratio_bad() returned a 1 (this doesn't happen if we use mathtolerance=0.05/1 or debugflag=3400). We then adjust_to_limits(2.0), which will mess up the magnification (and corners, I think). Jonathan
Tim,
I suspect the problem we are seeing is caused by line 471 in fracsubr.c, where we goto expand_retry because one of the calls to ratio_bad() returned a 1 (this doesn't happen if we use mathtolerance=0.05/1 or debugflag=3400). We then adjust_to_limits(2.0), which will mess up the magnification (and corners, I think).
I've got a fix for it. Will commit the change momentarily. Jonathan
Tim,
I suspect the problem we are seeing is caused by line 471 in fracsubr.c, where we goto expand_retry because one of the calls to ratio_bad() returned a 1 (this doesn't happen if we use mathtolerance=0.05/1 or debugflag=3400). We then adjust_to_limits(2.0), which will mess up the magnification (and corners, I think).
I've got a fix for it. Will commit the change momentarily.
Hmm, I'm not sure I like how my fix behaves. Before, when zooming in, you would get so deep and then Fractint would back you out and not let you get any deeper (unless using mathtolerance). Now, you can zoom in until you get the big chunky blocks. Jonathan
In article <4621255A.21404.1E8C686@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
I do recall generally and could investigate it, but let me say this: there is absolutely no reliable way to automatically detect when the limit of precision for a fractal is reached with a particular type of math, especially with all the zoom box flexibility that we have (skewed, rotated, etc.) but also because it depends on the algorithm that is being iterated.
Sounds like something that needs to be pushed down into the fractal specific function pointers. If NULL, fall back to the algorithm we are doing now, otherwise let the fractal type decide when it needs to switch math. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
participants (5)
-
Hal Lane -
Jonathan Osuch -
Lee H. Skinner -
Richard -
Tim Wegner