Question about generator layers... (on the topic of fractal flames)

[Matthew Woehlke]

First, I assume generator layers save the data with the .kra and don't 
have to regenerate each time?

Second, and more interesting... is it currently possible to have a 
long-running generator that dynamically updates at intervals, i.e. after 
you click 'ok' on fiddling with the parameters, you'll get *something*, 
but the generator will continue to run in the background? If not, would 
that be feasible with the current architecture?

I've been looking more at Apophysis and realized that it's really just 
an editor for IFS fractal flames, which have a number of implementations 
and are more-or-less well defined. (I also discovered a *different* type 
of fractal flame, or at least something that looks similar; namely the 
de Jong equations ala http://fyre.navi.cx/, which I think I'd like to 
try to implement first, as the math and configuration are trivial 
compared to IFS, but the process of mapping the raw fractal data to 
pixels seems to be similar.)

The point is, fractal flames are rendered entities that can take a 
*long* time to generate at high quality, and it would be I think optimal 
if they could be generated in the background, so that one can continue 
working with a low-quality version in the layer as it slowly refines 
itself. (To generate "final" versions, one would simply leave Krita 
running for a long time, to let the generator do its thing.) Obviously 
this would need to be done at very low priority, or even be tied to a 
'render' button and suspended when the user starts doing things.

A "maximum quality" is probably required in case someone *wants* an 
image at a certain level of graininess, but in most cases I don't see a 
problem with nearly-unbounded refinement. (The main caveat that comes to 
mind is that the accumulators - unless we allow unbounded memory growth, 
which doesn't seem worth the complexity - will have a limited 
resolution, so there is actually a maximum upper limit equal to the 
resolution of the accumulation buffer, at which point either 
overexposure or loss of precision occurs. However the limit is likely 
2^64 iterations.)

...Which actually brings up another problem; it would actually be 
preferable for a generator to "save state", i.e. to *not* save the 
generated pixels but to save an arbitrary blob from which channel data 
can be generated quickly. In the case of flames, the raw accumulation 
buffer would be saved along with the number of steps (and of course 
generator parameters); translating the accumulation buffer to channel 
data would be O(n) with n being the size of the image. (Basically 
chanData[i,j] = expose((double)accBuf[i,j] / (double)accCount). You'd 
better believe we want HDR here!)

Incidentally, Fyre has the right idea; store the raw accumulation data 
and post-process it. If Krita can do this, it will be a HUGE improvement 
over GIMP, because - just like in Fyre - you'll be able to change the 
exposure, gamma, and coloring in real time, without re-rendering (not 
something to laugh at when the render can take hours or days to reach a 
high quality level!).

Summary:
- Can Krita save generator layers along with an arbitrary data blob 
defined by the generator? The generator will be required to quickly 
translate that blob into channel data on load.
- Can Krita allow generator layers to run in the background (or at user 
request) to refine their data?

-- 
Matthew
First time I've gotten a programming job that required a drug test. I 
was worried they were going to say 'you don't have enough LSD in your 
system to do Unix programming'. -- Paul Tomblin  (from cluefire.net)