Filters : Preview and Adjustement Layer

[Cyrille Berger]

On Monday 28 January 2008, Boudewijn Rempt wrote:
> I also think we have to face the possibility that some filters will never
> be fast enough to function as an adjustment layer.
Sure but we have to do our best :)

> 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.
It's quiet easy, the reason I haven't do it yet, is that I am not sure wether 
rand and srand are thread safe. But looking at Qt's doc, qrand and qsrand 
are. So we might just use that.

> 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).
For bumpmap, the problem would then be serialization/unserialization of the 
config.

> 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?
There is two things, the lens correction filter need the center of the data

> Round corners (and shadows) 
> isn't a filter really, but a layer action like scaling, rotating or
> cropping.
Yeah I still dream of having rotation/scaling as adjustement layer ;)

> >  - 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.
Why is that ? Can't we use the old data ?

> >  - 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?
Yes. Whole image means better results, my guess is that a subsection will 
gives a good enough result.

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

Sounds fun, isn't it ?

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

At least for the lens filter, yes.

-- 
Cyrille Berger