Filters : Preview and Adjustement Layer

[Boudewijn Rempt]

On Mon, 28 Jan 2008, Cyrille Berger wrote:

> Hello,
> 
> There is a few remaining issues concerning filters and preview and adjustement 
> layers. Some filters don't get enough information when run in a preview layer 
> or in an adjustement layer.

I also think we have to face the possibility that some filters will never be
fast enough to function as an adjustment layer.

Another thing, now we're on this topic: we will need to save the seed for some 
filters that do random permutations in their filter configs, like raindrops.

A problem with passing the image and/or the current layer as part of the filter
config parameters is that filters should be capable of working on any paint
device, whether that paint device is in a layer or not. Maybe we could pass the
image and current layer to the filter config widget? Then the config widget can
fill the filter config parameters with things like image size or reference layer
(for bumpmap). 

There is another problem with adjustment layers and with filter masks set on
a group layer: the size projection they are active on is dependent on the entire
layer stack under the adjustment layer or of the layer group. That's going to 
complicate things, and we'll probably have to introduce some way of signalling
that the bounds of a layer changed -- and that's something we've been struggling
with for a long time already. I've already tried caching the bounds using the 
setDirty calls, but that didn't work out.

> * Problems
> 
>  - filters that need the exact bound (I am thinking about round corner, lens 
> correction or ), the image size isn't good enough, at least for "lens 
> correction", because it needs to know the center of the photo, and on a 
> composition of photo nothing proves that it is the center of the KisImage.

Shouldn't the center of the composition be part of the filter parameters? Or am
I think of the wrong kind of center? Round corners (and shadows) isn't a filter 
really, but a layer action like scaling, rotating or cropping.


>  - filters that need to compute a statistics on an image (I am mainly thinking 
> about "fast color transfer" and "auto-adjustement"), there are two issues 
> with those filters, firstly they need the full image and secondly they need 
> to re-compute the full statistics for each change

Would it be possible to recompute the statistics on a scaled down (say, 25%) version
of the image? Caching the statistics seems to imply we need another tile system
or something like that, to store intermediate results.

>  - filters that need the full image (I am thinking about the wavelet noise 
> reducer or pyramidal sharpening (from krita-plugins) ), I am guessing that 
> those filters will gives good enough result when applied on smallest part of 
> an image

I don't follow that: do you mean that these filters need the whole image, but
can work on a subsection, too?

> 
> * Ideas of solutions
>  - introduce some sort of dependency between update of the projection, for 
> instance "lens correction filter" will force the adjustement layer to wait 
> for the data below to be available

We will have to do something like this (gegl has it, too), but that is
going to be a complicated operation. ThreadWeaver can help here, since
it does allow job dependencies to be set, but it means that I have to
split up the jobs in two dimensions, i.e., instead of just tiling up
the image. I will also have to create jobs for the parts of the layer
stack between adjustment layers that need to see the whole projection
underneath themselves.

>  - to address the first issue, I think that having the exact bound of the 
> original image is a good enough approximation,

We could pass that by default in the filter config parameters for filter masks.

>  and an other solution is to 
> further refine the exact bound each time new data is available.

That's pretty complicated for adjustment layers and filter masks on
group layers. Right now, adjustment layers are as big as the imagem, but not bigger.
What should happen when part of a layer is outside the image bounds with these
filters, btw? Should the hidden part be taken into account?

>  - for statistics based filter, I am thinking that having a KisFilterStatistic 
> object that we could give to process could be the solution, basically, 
> instead of computing the statistics in KisFilter::process, we would do it in 
> KisFilterStatistic, and when updating a small area of the paint device, we 
> could just call a method from KisFilterStatistic with the pixels before and 
> the pixels after (for instance KisFilterStatistic::append and 
> KisFilterStatistic::remove). That doesn't solve the problem of the first 
> initialization that still need to have access to the full KisPaintDevice  (or 
> to use KisFilterStatistic::append) The use of such filter is probably going 
> to trigger a lot of update in the projection, but I guess it can be done in 
> the background (we probably would have to make the area that was painted have 
> a higher priority)

There already is code to make the projection prioritize the visible area of an image,
it's just not used yet. Caching the statistics is definitely a good idea.

> PS: I have started a page about the state of filters : 
> http://wiki.koffice.org/index.php?title=Krita/Filters_State

Great!


Boudewijn Rempt