On 20 Nov 2004, Edwin wrote: (...)
o) Backwards Compatibility. It's extremely important that the huge numbers of extant .par files continue to produce the same images in the future. This means that changes to the Fractint code base have to be made very carefully, which makes it harder to make dramatic changes like changing the rendering model to create 24-bit images. (...) Methinks that your writing in Python probably explains a lot of difficulties that are hard to exaggerate in English, although I'm pretty sure you can link Python into C as easily as you can link FORTRAN into C (not that this is easy, when the programmers must know what they're doing).
As far as changing the rendering model for 24-bit images, I don't see much potential there. I've used one image as a mask on operations to another view of the same fractal to get 24bit images. One of my productions (http://ecn.ab.ca/~brewhaha/img/cards/heart.htm) even involves two masking procedures. So, rather than _changing_ the rendering model, I see options for complicating the one that exists to jenerate two or three different views of the same fractal and specifying a way for them to affect each other in a final 24bit product. The interface to such masking just about begs for numeric input in graphics designed for the web versus graphics designed for printing (the latter needs maximal contrast, while the former shouldn't make things hard to read). The beauty of having FracTint or GnoFract do it is speed, because you can calculate both outside=atan and outside=iter (for example) on the same pixel without re-doing the sequence of iterations.