Paul, why do you do just "color = sin(c * n + d)", instead of a full "color = a + b * sin (c * n + d)"? Hal Lane asked about retrieving iteration counts of an image by reconstructing it's original hi-color palette, based on those six palette parameters.. Rich suggested encoding iterations as a grayscale PNG image.. left aside that both of these solutions do have a problem with possible rgb triplets duplicities (as Paul already pointed out), you also loose the real iteration counts anyway, as everything is just wrapped at 2^16.. and still it's not the true true-color.. i know, i know, computing sines on the fly would be insane.. but you don't need to if.. if instead of all iterations per pixel you do all pixels per iteration - and all those that bail out get the same color.. if none does, you don't even need to know the color for such iteration count.. to be honest, this doesn't solve neither duplicit triplets, nor wrapping (happens at 2^31..) but you get it true true-color, you get an improved boundary-tracing-like image evolution and you get possibly infinite iterations.. at a cost of just a few MB of memory.. and those real iteration counts? why not to simply save them in a separate "raw" binary file? (gzipped..?) P.S.: Rich, please, stick somewhere in the roadmap an SVG and an HPGL support for L-systems and that infinite looping for escapetime fractals -- tell me which of these are blocked by your current development.. Thanks. /charlie/