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

[Boudewijn Rempt]

On Monday 05 May 2008, Matthew Woehlke wrote:
> First, I assume generator layers save the data with the .kra and don't
> have to regenerate each time?

Yes.

> 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?

It doesn't work that way, but there is already some code in place to associate 
a set of filters with a paint device that are started regularly.

> 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.

It's doable, but a serious complication (like, every time a layer is updated, 
you'd need to update the whole rendering stack) but I'd prefer to postpone 
that to after the release. After all, it's just an optimization.

> 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!).

Sure, that's doable in a generator plugin, but only in the sense that you'd 
have to save both types of data. Raw data and finally rendered pixels. You'd 
store the raw data in a parameter in the generator configuration, probably 
using a paint device with a KisGenericColorSpace (so you get memory 
management for free).

> 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.

In a sense, yes -- it might need a little work to make it smooth in practice, 
and it will always be necessary to also save the rendered pixels.

> - Can Krita allow generator layers to run in the background (or at user
> request) to refine their data?

Yes, but not as easily and it's something I'd rather postpone until we've got 
generators that do something.


-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi