Welcome to Fractal Forums

Some time ago I played with Buddhabrot fractals. If you don't know what is Buddhabrot fractal, look at http://en.wikipedia.org/wiki/Buddhabrot

To render Buddhabrot in very high quality I had to use very accurate grid of resolution: 50000 x 50000 samples and calculate fractal in very high number of iterations - 50000 !!!. It takes about 35 hours to render this using Intel Core 2 Quad Q8200  :worm:

(http://www.fractalforums.com/gallery/0/640_25_07_09_6_51_31.jpg)

Try to watch in high quality (double click on video)
http://www.youtube.com/watch?v=QsWEbx2wOBM

And some detailed view:
(http://www.fractalforums.com/gallery/0/640_25_07_09_6_53_52.jpg)

The last image reminds of NASA Hubble images of nebulae in deep space.

Maybe the clearest way to communicate with extraterrestrial life would be trying to re-shape some gas into a gigantic buddhabrot...

(Note I said "clearest", not "easiest")  :dink: Nice pics!

lol.
Why not use a Buddhagram? xD
Or, to create a 3D-variant: Somewhere I found a WIP-Buddhabulb on one of the pages, of one of the forum members... (Was it David Makin, maybe?)
I'd love to see that explored further :)

I think I remember somesuch...but it wasn't me :)

Hey everyone. I just joined this blog and was very excited to see some Buddhabrot fans. I am FractalWoman (Lori Gardi in reality). I am given credit on Wikipedia for coining the term Buddhabrot, in the Discovery section. I am a computer scientist and Fractal Cosmologist. I have developed a fairly extensive cosmology based on the Mandelbrot Set (and Buddhabrot Set) that can be found here:

http://www.butterflyeffect.ca/Close/Pages/Buddhabrot.html

I hope you have a chance to check it out. I may start a thread on Fractal Cosmology sometime in the future. Could be fun.

Greetings, and Welcome to this particular Forum !!!    :)

There are a few fans of the Buddhabrot here, though it seems the Mandelbulb/box area is the most current trend at the moment.  But who knows how long that will last.  Something totally new may come along to replace it.    :dink:
 

@fractalwomen, i knew it you where the founder of the buddhabrot, great to have you abroad, and i hope you have discovered the philosophy section!

Cool, Thanks.

This is already way more fun than the science forum I was on earlier this year. They were pretty harsh to say the least. I will definitely check out the philosophy section. Looking forward to many interesting discussions...

I was wondering if anyone else uses the following method for speeding up buddhabrot calculations. I was able to speed mine up by an order of magnitude. What I do is I take advantage of the limited number of bits available to the CPU for processing. For each iteration, you check to see of either the real component or the imaginary component is exactly the same as the last iteration. some pseudo code below.

double real;
double imag;


while ! done

iterate();

if (oldReal == real || oldImag == imag)
   Point is on inside. Stop.
else
   oldReal = real;
   oldImag = imag;

repeat


Yes, I know that comparing floats directly is not a good idea, but in this case it is.

Anyways, since buddhabrots are histograms of the "outside" points, then detecting the inside points quickly is really useful.

FractalWoman

Hi.  Very nice renderings. 

You might be interested in seeing my entry into the Fractal Forums contest :):  http://www.fractalforums.com/index.php?action=gallery;sa=view;id=2048 (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=2048)

Regards,

Will Milberry

Brent's algorithm for periodicity detection works wonders for speeding up Mandelbrots of every stripe. I never leave home without it. :)

Yes, the periodicity method works great but it a bit more CPU intensive than just a quick float compare. It does the trick though.

The advantage, besides perhaps earlier detection, is that you can find out the period. The next pixel is very likely to have the same period so a further speedup can be had by testing for that particular period.

That periodicity detection method only excludes the period 1 points, right? Admittedly, that's an enormous chunk. Pauldelbrot, you mentioned "Brent's algorithm"? I've never heard the term, any pointers on where I could find that info?

Also, very nice Buddhabrot pics! I like the detail. I find the Metropolis-Hastings algorithm is useful for speeding up things like the Buddhabrot, you don't have to calculate a full grid, but kind of cranky if you try to multithread :P That's one of my current projects.

Here is a star field image generated from the M-Set.

See below for details on how I generated them:

http://www.butterflyeffect.ca/Close/Pages/SpaceTimeFluctuations.html

Wikipedia.

Basically it works like this. You have some sequence defined by a recurrence, a function to get the next element from the previous. You also have a starting point. Brent's algorithm works like this: first you calculate the function to get element two and compare to the starting point. Then you save element two and calculate element three, compare it to two. If still no cycle, calculate element four and compare to two. Save element four now and for points five through eight compare to that. Then save eight.

That is, you maintain a saved point from earlier in the sequence, compare every new element to the saved point, and every time the orbit length reaches a power of two you update the saved point to the current one.

Cycles of any length can be detected and there's no need to perform extra tandem iterations or anything like that; just store and compare values. So the overhead is fairly low, about the same as checking for a known finite attractor (the difference from that is logarithmic in the number of iterations).

Oh, awesome, thanks--that algorithm looks very nicely effective! :D

BTW, to quickly find out if an integer N is a power of two, you can test

((N - 1) & N) == 0

On most processors, the comparison to zero is optimized away completely, so this takes just two simple computational instructions and a branch.


(The above expression clears the rightmost 1 bit. The result is zero if and only if there was at most one 1 bit, i.e. for powers of two and N == 0.)

I guess, it's this...
http://mathworld.wolfram.com/BrentsMethod.html

Great explanation of Brent's algorithm. I'm going to try that for sure. What I do is I save the whole sequence and periodically check for cycles. This is useful if you want to measure the length of the cycle and/or find the starting point of the cycle. The length of the cycle seems to correlate to the number of "spiral arms" in the galaxy-like shapes generated by the orbits. For example:

http://www.butterflyeffect.ca/Close/Pages/SpaceTimeFluctuations.html

The dynamic or orbit this web page has 5 spiral arms so the cycle count is five. This is really interesting because the cycle only happens because of the limited resolution of the floating point processor in the computer. If we had an infinite number of bits or digits of precision, then the cycle would never happen. NOTE: the cycle we are talking about here is different than the orbital periods within the primary bulbs of the M-Set. For instance, a period 3 orbit might have a cycle count of 10 or 100 depending on how close to the "event horizon" you are.

Hope this makes sense...

For example, in this image, I selected a point from the main bulb. This should represent a period one orbit. However, you can clearly see that it has two spiral arms. This is what I call a loop-2 singularity because it ends up in a cycle of length two. However, it is clearly spiraling onto one point and thus has a period one orbit.

In what order do they appear?

The red dot is the first point. The opposing point at the other end is the second point. The point next to the red point is third etc... so it spirals into the center point but, with infinite digits of precision, would never get there. Essentially, it is spiraling into a complex irrational number. I'm working on a paper now that proves the irrationality of these numbers.

So, it's visually a double spiral, but if you connect the points in order of their appearace, they actually are on a single spiral. :)

But not all of them are irrational !

Apologies, I just realised that you probably meant proving that all the truly complex attractors (i.e. non-zero real and non-zero imaginary) are irrational ? Which I guess may be true though I'd be surprised if it was, my reasoning being that the attractors vary smoothly from one point to another (given infinitessimal steps) and I suspect most/all values within a given 2D range are covered hence the likelihood that some values are rational complex.

Actually, I believe that all the points on the INSIDE of the Mandelbrot Set are "falling" into one or more complex irrational numbers. The reason I believe this is because I created my own infinite precision floating point library and have followed these points to more than 500 decimal places and have found no end to the number of digits that eventually stabilize. Each point from the INSIDE of the M-Set seems to go this way. In the period 3 bulbs, the points are "falling" toward three irrational points or singularities. In the period 5 bulbs, the points are spiraling around five singularities as seen in this picture. Given infinite digits of precision, these points would fall forever toward these singular points. The closer the starting point is to the "event horizon" the longer it takes to fall into these irrational singularities. At least that's what I find.

You need to ignore the actual value and consider the value that it's tending towards, I mean if you take the point (0.25,0) and you use infinite precision then your orbit value will never actually reach (0.5,0) even though that is the attractor.
Also apart from the "obvious" points such as (0,0) or (0.25,0) etc. then you'll (probably) never be able to find a rational one by experimentation, you'll only find them analytically because experimentally the number of irrational attractive values is orders of infinity more than the number of rationals.

If you consider the main cardioid then all the point attractors are given by:

  z^2 + c = z

Re-arranging:

  z^2 - z + c = 0

Which yields:

  z = (-1 +/- sqrt(1 - 4*c))/2

And I think I'm correct in saying that all the attractors in the main cardioid have a magnitude <=0.5 (magnitude exactly 0.5 being the boundary points) though I don't have a proof of this to hand.

So for the attractors in the main cardioid we have:

  z = (-1 +/- sqrt(1 - 4*c))/2

and cabs(z)<=0.5

I think it's fairly obvious that there will be many rational values for z that satisy the above - though far fewer cases where both z *and* c are rational.

Yes, you're right. The set of irrational numbers is "dense" compared to rational numbers and so experimentally, I will probably always pick an point that tends toward an irrational number rather than a rational one. Thanks for clarifying that for me.

Whoa whoa whoa! Hold on a minute. The number of transcendental numbers between 0 and 1 is orders of infinity larger than the number of algebraic numbers, but because of our descriptive limitations, if you "pick" a number in that interval at "random" it's almost guaranteed algebraic. What I'm saying is that the choices you have to make in experimentation (e. g. only using rational initial points) will skew the probabilities infinitely in one direction.

Also, David: Perhaps I'm mistaken, but by that last formula, z is rational in exactly the case that sqrt(1 - 4c) is rational, which is only the case when c is rational. Of course, there are many choices of c for which z isn't rational, but I think I'm correct in claiming that whenever z is rational, c is too.

In the first case you are correct that experimentally the values of c used will always effectively be rational, but the relative infinities are such that the number of rational attractors for those rational values of c will be comparatively very limited.
In the second case you are also correct, but again there are of course more cases where c is rational and z is not than there are of z (both) being rational.

Following up on Dave's ideas, the equation for attractor points inside the main cardioid is:

z² + C = z,

or, rearranging,

c = z - z².

So, one could create a complex rational z value with magnitude less than 0.5 and find the corresponding c point inside the cardioid.  Since z is rational (by construction), c will be, as well.  For example, using z = (1 + i) / (2 + 3i), I found c = (-1 + 3i) / (-5 + 12i), or about 0.2426-0.01775i.

By this method, there are infinite rational (c, z) pairs.  It seems to me that since the iteration only involves squaring and adding, using a rational c value should guarantee rational z values, but now I'm thinking like an engineer, not a mathematician, as my complex analysis professor once told me.  :)

Scratch that.  If that were true, then all power series expansions of functions with rational arguments would be rationally-valued, but that's obviously not the case.  Nonetheless, there do seem to be infinite pairs of rational c & final z values.

I wanted to address this comment, because I guess it wasn't clear that I am in fact watching where the point is tending to go. What I do is I start with an initial (rational) point, then I iterate zillions of times until the digits begin to stabilize. The stabilized digits are the final digits that I am analyzing, not the in between digits during the iteration process. As you can see from the orbit that I showed earlier (with two spiral arms), the points are spiraling into a particular point near the center of this dynamic, and this is the point I am trying to resolve. With infinite digits of precision, this point would never resolve. My current experiment uses 500 digits of precision and when all 500 digits finally stabilize, what I find is that the "digits" are statistically identical to the digits of PI (or any other irrational number of this kind).

NOTE: in a period three bulb, there would be three orbits, and each of these orbits would tend toward a single point (whether irrational or not) which can only be resolved absolutely given infinite number of iterations.

I hope this clarifies what I am doing.

FW

OK, I guess I was just trying to point out 2 things, first that even using infinite precision you'll never reach the true value/s of the attractor except in special cases - like c=(-2, 0) - even if the attractor is rational, and secondly that using less than infinite precision means that the final value stabilising (or not) doesn't tell you whether the true value is rational or not because to know that from the stabilised value itself inherently requires infinite precision.
This issue is essentially what makes it so difficult to accurately do "smooth iteration" or distance estimation for inside points since it's very difficult to tell apart for example a point attractor that's actually oscillating between two values but very slowly tending towards a single point and a period 2 attractor that's oscillating and tending to the 2 periodic values.

I should add that if you have a statistically random distribution to 10,000 decimal places then this could simply mean that the number is rational as x/10000 :)

Edit: Forgive the schoolboy error, I meant x/(10^10000) :)

Actually, convergent smoothed iterations is fairly easy. If the attractor is superattracting, use the divergent smoothed iterations algorithm conjugated by an inversion about a point of the attractor (and looking only at every nth iterate where n is the attractor's period). If it's not superattracting, the method described in this post of mine (http://www.fractalforums.com/images-showcase-(rate-my-fractal)/dragon-i/) works wonders.

Well, I know the various algorithms are fairly easy, it's just the number of iterations required that's the problem, especially if writing generically for a general Mandelbrot rather than for a general Julia (where you can pre-compute the attractor value/s) - for instance if you want to get within say 1e-7 units of the Set boundary :)

There's always a lot of iterations required to render points near the set boundary correctly. (Periodicity detection helps.)

i posted some (cheap) optimisation tricks i use, here : http://www.fractalforums.com/programming/buddhabrot-in-fortran-%29/15/
You can also find a link to the full source code at the same place.

Yes, this is what I mean. Both real and imaginary components must be non-zero. So far, all the points I have tested at seem to "fall" in the same manner where the final result (up to 500 decimal places) look a lot like an irrational number where the digits are fully randomized with no repeats. It's a difficult thing to prove though because it's impossible to test all cases.

(I'm back!  ;D)

I'm fairly certain that many rational numbers would eventually lead to rational attractors. For instance, I think that c=-0.3125=-5/16 has a rational attractor. The set of rational numbers with rational attractors is equal in cardinality to the set of perfect square rationals, which are in turn equal in cardinality to the set of all rationals. The set of rationals with irrational attractors would have the same cardinality.

A large colored 8000x8000 render made with the lastest version:
http://telin.ugent.be/~jdebock/BuddhaBrotMT/BuddhaBrotMT-8000x8000-001.png

Took about 21 hours to render.

Very nice :)

Very good render. Image quality is really impressive! 21 hours is not so long to render something like this.

That is the main feature of my renderer, speed.

Here is a high resolution Anti-Buddhabrot:
http://telin.ugent.be/~jdebock/BuddhaBrotMT/BuddhaBrotMT-8000x8000-002.png

you only used two colours on the anti bbrot?

It's a color palette with mixes of red, yellow, white and black.

a complex number has two components. You only show one component here.

My guess is, he meant -5/16+i*0

'Fraid not:


This using FF 3.6.3.

Apparently the PNG encoder you used is not compatible with the PNG decoder in FF 3.6.3.

Unfortunately for you, over one quarter of users are probably using FF 3.6.3 (and most of the rest IE 8.something whose compatibility with your PNG encoder I wouldn't vouch for either, given that FF is usually closer to adhering to standards than anything out of Redmond).

Just tried with Firefox 3.6.3 and it has no problems reading the PNG. Xnview and Acdsee classic also have no problems.
I use libpng to write out the png.

Paddlebrot: No porblems looking at it here, either...
I tried both FF 3.6.3 and the test-version for the new youtube video format. Not that that should make much of a difference :)

I don't know why two people are now accusing me of lying. But I do know that anyone with Firefox can click the link and see what I saw, so the truth will out, and all that.

Since the poster of the image is one of the ones accusing me of lying, I'll take that as indicating that they have no wish or intention to fix the image, so I guess it'll stay broken. And I'm not going to try viewing it in IE -- I hate IE. So I guess that's that.

NOBODY is accusing you of lying.   :police:

They are merely stating the truth - the image appears just fine in FF 3.6.3

Here:

(http://www.sockrateaze.com/stuff/screeny.jpg)

That's a 50% resolution screenshot as proof it works.

If the owner of the image is offended that I posted his work this way, just let me know and I'll remove it Instantly!

I was not trying to cause a problem, rather trying to resolve a misunderstanding.

I'm sorry, Pauldelbrot, but the problem must be on your end...

O.o
I wonder, how I accused you of lying? Just stating, that it works on my end doesn't mean, I think you lie.

Hooo ... drama \o/
 :w00t:

Hi Paul, I'm also not accusing you of lying - for some reason it's obviously not working for you - but it also works here in Firefox 3.6.3 under Windows XP.

Nobody is accusing anyone of lying. I just stated that I could view the image without problem in the stated programs.
The images can be posted, printed, anywhere you want in any format you want. Just give credits.

I'm also working on 16-bit png output but I'm still looking for good programs to view them.
Does anyone have any suggestions?

@Pauldelbrot: Can you test if you can open it with a picture viewing program? Maybe for some reason the browser won't open it completely.
I use the standard libpng-1.2.40 library to write out the png's, normally that shouldn't be the problem.

This is frankly unbelievable. One of you even photoshopped an image to make it look like they'd successfully loaded it in Firefox? All to avoid admitting that some incompatibility exists between Firefox and a PNG encoder they used?

And of course someone suggests that a "problem" exists at "my end", even though that's impossible -- I haven't made any peculiar changes to Firefox that could cause it to not decode PNGs properly, and the machine has plenty of memory and disk space. It's also clean of viruses and other such things.

Please, give it a rest. The PNG "contains errors". Firefox says so. So, just admit it and re-encode the darn thing already. The longer you spend defending the honor of your broken PNG encoder instead of fixing things, the longer the broken PNG sits there wasting space on the server and causing those who try to view it in FF to be unimpressed.

 :rotfl: :rotfl: :rotfl:

Now you're just being silly...

Two pieces of additional info:

1. The PNG will view in the Windows previewer, so the PNG isn't completely trashed, just not compatible with Firefox's decoder.

2. Here is my own "photographic evidence" that I am not lying. Of course, anyone who views this thread cannot be sure which image was photoshopped and which was not ... until they try visiting that URL with FF 3.6.3 themselves, and then they'll know. :)

(http://www.fileden.com/files/2008/5/16/1914214/png-broken-ff-363.JPG)

Nobody here has ever accused you of lying, and nobody has ever lied to you about this!

My screenshot was not photoshopped - I don't even Own photoshop!!

Nobody ever doubted that there was a problem with you viewing the image - but nobody else has the error problem you describe.

I fail to see why you are taking this personally.

The image shows up Perfectly here, and for others.

Perhaps it's an issue with your ISP?  22 MB images are kind of rare online - maybe there is a limit in place somehow?

Or maybe it's an issue with johandebock's site and your server?

Since permission was given, I'll upload it to my own site and you can try to view it there.

Here:  http://www.sockrateaze.com/stuff/BuddhaBrotMT-8000x8000-002-by-johandebock.png (http://www.sockrateaze.com/stuff/BuddhaBrotMT-8000x8000-002-by-johandebock.png)

Give that link a try.  We really are trying to help you out here (and I honestly thought you were joking with the comment about "photoshopping" a screenshot).

Either way - there is some sort of problem, and it would be interesting to try to solve it without accusations of lying and faking images!


EDIT - Is it possible you just have a bad install of Firefox?  Re-installing the program may help!

I suspect the PC may have run out of virtual memory in the PNG decoder.

First of all, one of the two screenshots must be doctored, unless Firefox 3.6.3's PNG decoder does not respond deterministically to a particular PNG file. Moreover, for your theory to be correct (it consistently fails on my machine but actually works for everyone else) it would have to consult not even an RNG but some stable feature of the machine it's running on, like its MAC address, to decide whether that particular image should be decoded or treated as "having errors".

Tell me, now, why Mozilla would design Firefox to check the MAC address (or whatever other equally-irrelevant stable feature of the machine it's running on) to decide whether to decode a PNG normally or to falsely state that the PNG file contains errors? This seems to amount to a conspiracy theory with no apparent motive and a particularly implausible villain, whereas someone being embarrassed by their encoder not being compatible with a browser with significant market share, wanting to pretend it isn't so, and a couple other people jumping misguidedly to their defense is far more plausible.

As for the notion that it's running out of virtual memory, or anything similar:

1. I viewed another 8000x8000 png with FF recently without issue, on the same hardware and with the same copy of FF.

2. The hardware in question has 3GB RAM.

3. 22 megs is a joke compared to 3GB.

4. The error is not "out of memory", it is "the file contains errors". It clearly indicates that the FILE ITSELF is wrong, not something else in the decoder's environment, such as the available memory.

5. There is very little data downloaded before it gives up and says the file contains errors. To judge by the screenshot, it reads the PNG header, determines the width and height and the scale-factor to use initially when displaying it, then sees something in the PNG header that it doesn't like, closes the stream, and reports an error. This points to a header that is, according to the decoder in FF, malformed -- probably because it uses some newer PNG feature that FF's decoder doesn't support. This fits the incompatibility theory much better than it fits any theory that makes the problem somehow local to my machine. Out of memory, in particular, would manifest with it spending a while chugging downloading data and then horking it all up at some point with an error message saying "out of memory" or even an outright crash.

Once again, I invite skeptical readers to click the link in FF 3.6.3 themselves and see what happens. I also invite them to examine the rightmost taskbar button in the screenshot purporting to show FF 3.6.3 successfully decoding the png at issue. It does seem to be true that the user who posted that screenshot does not, specifically, use Adobe Photoshop ... :)

it works in Chrome  :tease:

This is silly.  Computers always have been and always will be full of quirks and bugs and incompatibilities even when things are supposed to follow "standards."  Sometimes it's a software flaw, sometimes it can be local condition that exists on one machine such as a bad cached file, file locked by a process, etc., etc.

If you can't view an image in your web browser, right-click->save and view it in your favorite viewer or troubleshoot by updating software/clearing caches/testing with alternative browsers/etc.  It's silly to stick to a position that the problem must be external in nature.

Having worked in the I.T. world for many years I have seen tons of problems that shouldn't be and I know that spending too much time focused on what one wants a problem to be rather than what it possibly really is only brings frustration and not information exchange.

If a browser isn't displaying an image that it should I would recommend disabling all plug-ins/add-ons, rebooting, and clearing the cache as well as trying another browser as a control.

EDIT:  
Firefox may not be able to distinguish between errors reading a file from a site, and errors reading data for display from it's local cache or memory.  Errors of this nature can quite generic with the true cause existing a possible variety of points along the download/decode/display chain.

EDIT2:  Another thought - right-click, save the file, then try to file > open from Firefox and see if it can open the file.  Also check that the downloaded file can be opened by another image viewer.  This may give clues to the location and nature of the problem.

So you admit to doctoring your screenshot now??  Mine is not doctored in the way you say (just reduced in size, no image editing) so that leaves only yours as "one of the two" which "must" be doctored!


Yup - I stated the shot was reduced in resolution by 50% - How else can one do that without Arcsoft Photo Studio 5??  It's IMPOSSIBLE to shrink an oversized image with any other software.

{Right Back Atcha, Sweetie}  (Yes - that was Sarcasm above!)

I did not post a 1600 pixel wide image out of courtesy to the forum, not to mess with you.  Shrinking the image was done with my image editor - and I was joking earlier about your incorrect use of the Noun photoshop as a Verb.  Lighten up.

I suggest you stop making accusations or else you may have some levied at you!!   :police:  

The problem *IS* at your end.  If you don't believe it - get out of the house for a change of view.  Go to the local library, and try to view it on their machine  (if they don't have firefox, ask them to install it).

Or ask one of your friends to try it.  Or stop by any other place that offers public web access (colleges, internet cafe's, etc).

You can't prove anything from just a single machine.  That's why we are trying to help you, but if you insist on being confrontational - you will find people less willing to help you.

Did you even try a fresh install of firefox on your machine as I suggested?

Or viewing it on the other site to which I uploaded it?

Or are you just being confrontational for the fun of it??  

That is probably the case.

If not just try to download the image and try to view it with for example xnview:
http://www.xnview.com/
And show us the result.

I just have to step in here. I'm using Firefox 3.6.3, in Ubuntu, and it views the image without problems. Here's another screenshot, scaled down 50% in GIMP. I deliberately put the mouse between the "About" window and the image because that would have been difficult to edit in in GIMP or similar.
(http://sostotigog.files.wordpress.com/2010/05/skjermbilete-7.png)

I don't have any problems with Firefox, either...   Using FF 3.6.3 on a Win7 x64 machine and I can also see the image fine, so it is definitely not an issue with my install of Firefox.  I would also suggest a re-installation - that would be the quickest way to tell whether it's a problem with Firefox, or if it's because of some other issue?

I most certainly do not. I just point out that either one of them is photoshopped or there's some weird conspiracy at Mozilla to make PNGs with certain headers not view in Firefox on computers with certain MAC addresses (or something equally outlandish).


No. Nothing about me is "incorrect".


It's the same exact software, same exact version, viewing the same exact file. The results of that should be deterministic. You are claiming that they are not -- that is, that Firefox's behavior when viewing a PNG does not solely depend on the PNG bit-sequence, the Firefox binary, and whether sufficient memory is available to hold the image in RAM. I find this claim dubious, for why would Mozilla program it to behave in such a manner? Consider also that if your theory were correct it could not be an accidental, innocent bug either, because an accidental bug would result in random or unpredictable behavior of some sort, not a systematic dependency on something like the machine's MAC address. For the latter to occur a programmer at Mozilla would have to have specifically included code in the PNG decoder that looks at the machine's MAC address, and I cannot think of any legitimate reason they would have to do so.


Pardon me, but in my opinion what's confrontational is implying someone is a liar and then later calling him "incorrect" and "confrontational" when he reports, in good faith, corruption in a file hosted on a site.

Yay, Firefox is a fractal :D

I can't help it but I smell hacked spamburgers...

i will have to close down this thread, because it is way off its original theme, and
i dont really know where to break this thread down into its 2 parts ...

i havent read it completely, i just see that it is an ever longer thread, that is not following its main theme

Good idea, I will start a new thread with my high resolution BuddhaBrot renders.