Hi, this is a new formula, not an update, as it is not compatible. If it does what I expect, I still need some testing, itïs a major step forward, because now two way border values are available, which means, there also is an out-border. When this point is reached, the previous iteration is in use again. I did this in order to have a better separation and to a certain degree avoid distorted structures. Theoretically it should be possible to define the size of the inside image with pixel accuracy, as all border values are fractional. Therefor I skipped the lake effect, it was not compatible with most images anyway. The tricky real(p5) input is now easier to handle and the initial routine is more effective. That BUG still was there in the beginning, but when I changed all border inputs to be fractional (secondary inputs), it seemed to be gone. "Gallery" is a zoom into one "neuralgic" spot and renders ok. In the previous frm I had to use "round" functions to get rid of the "artefacts" which fractint adds to the inputs. I think in some rare events these caused a different value of a variable and the consequent errors. Jonathan, does this sound reasonable? Anyway I keep my fingers crossed and will do some more testing. Fractal Greetings, Al.
On Friday 23 May 2003 03:22 pm, Albrecht Niekamp wrote:
The tricky real(p5) input is now easier to handle and the initial routine is more effective. That BUG still was there in the beginning, but when I changed all border inputs to be fractional (secondary inputs), it seemed to be gone. "Gallery" is a zoom into one "neuralgic" spot and renders ok. In the previous frm I had to use "round" functions to get rid of the "artefacts" which fractint adds to the inputs. I think in some rare events these caused a different value of a variable and the consequent errors. Jonathan, does this sound reasonable? Anyway I keep my fingers crossed and will do some more testing.
Obviously, it shouldn't be necessary to use the "round" function. First, try using the startup option debugflag=322, to turn off the optimizations in the parser. I'll have a look at the code in the next day or two. Jonathan
----- Original Message ----- From: "Jonathan Osuch" <osuchj@avalon.net> To: "Fractint and General Fractals Discussion" <fractint@mailman.xmission.com> Sent: Saturday, May 24, 2003 8:19 PM Subject: Re: [Fractint] Multifractal_1 On Friday 23 May 2003 03:22 pm, Albrecht Niekamp wrote:
The tricky real(p5) input is now easier to handle and the initial routine is more effective. That BUG still was there in the beginning, but when I changed all border inputs to be fractional (secondary inputs), it seemed to be gone. "Gallery" is a zoom into one "neuralgic" spot and renders ok. In the previous frm I had to use "round" functions to get rid of the "artefacts" which fractint adds to the inputs. I think in some rare events these caused a different value of a variable and the consequent errors. Jonathan, does this sound reasonable? Anyway I keep my fingers crossed and will do some more testing.
Obviously, it shouldn't be necessary to use the "round" function. First, try using the startup option debugflag=322, to turn off the optimizations in the parser. I'll have a look at the code in the next day or two. Thanks for this info. Debugflag=322 helps generate the buggy images, but some others dont generate at all, until this command is deactivated. Here is a test: test { ; does not generate if ; debugflag=322 ; Version 2002 Patchlevel 5 reset=2002 type=formula formulafile=mult239.frm formulaname=multifractal ismand=y function=exp/exp/exp passes=t center-mag=-1.84684/-2.22045e-016/1.788803/1/90/-1.23373533611470521e-01\ 4 params=-0.2724234748374889/0.09260841700491348/384.00004/256.1121/2048.0\ 0016/768.000017/768.01536/512.01025/14289.27/0 float=y maxiter=2048 inside=maxiter outside=tdis logmap=3 periodicity=0 rseed=-2436 colors=200000<2>554776998BBACCB<18>iihjjillk<3>ssr<25>BBA998776<2>221000\ 011<24>0bn0cp0er<3>0ky<25>09B089067<2>021000210<24>oiPqjQslR<3>zsW<25>CB\ 6A95874653442220000400<23>o00q00s00<3>z00<30>200 }
On Sunday 25 May 2003 01:26 am, Albrecht Niekamp wrote:
Obviously, it shouldn't be necessary to use the "round" function. First, try using the startup option debugflag=322, to turn off the optimizations in the parser. I'll have a look at the code in the next day or two.
Thanks for this info. Debugflag=322 helps generate the buggy images, but some others dont generate at all, until this command is deactivated.
That would indicate that you are creating fractals from artifacts produced by the optimization part of the parser. And, if I manage to track down the problem, your formula will be broken. Jonathan
Jonathan:
That would indicate that you are creating fractals from artifacts produced by the optimization part of the parser. And, if I manage to track down the problem, your formula will be broken. <<
Most fractals look the same whether 322 is on or off (at least until a buggy pixel is reached). Al's Janusbird3 (1600x1200, passes=1) acts exactly the opposite: it runs into a bad pixel if 322 is set, but not when 322 is off. So they may not look much different if you do find the bug. But if they did, another command (e.g., OLDOPT=YES) could be added for backward compatibility I guess.
participants (3)
-
Albrecht.Niekamp＠t-online.de -
Jonathan Osuch -
Lee H. Skinner