Filters "dialog" in 2.0

[Boudewijn Rempt]

On Wednesday 20 June 2007, Moritz Moeller wrote:

> I'd like the opportunity to place a plea for abandoning filters
> altogether and going for filter layers instead (basically allowing to
> put any filter on an adjustment layer and change it dynamically
> afterwards).

We have that :-). At least, as soon as I've finished the ui for manipulating 
them. Currently we have effect masks (a per-layer set of masks associated 
with a filter) and adjustment layers (a filter in between a stack of layers). 
One problem here is that we have some filters that have a random effect: we 
haven't figured out yet how to stop the filter being random after being 
inserted as an effect mask or an adjustment layer.

Still, I also want to keep the ability to actually hard-change the pixels in a 
certain layer -- it's a way of working that's very common.

> In terms of UI: one could have a palette which displays the options of
> the filter or be able to 'roll out' an adjustment layer in the layers
> palette directly like in Adobe AfterEffects.

I don't think I've seen AfterEffects -- however, both adjustment layers and 
effect masks are and will be right in the layers palette, drag & droppable 
and manipulatable.

One good thing about the docker palette idea is that it can be updated to show 
the config of the current adj. layer or effect mask -- one problem is that 
some filter config widgets are really big and don't fit into a docker.


> I think what he means is to roll out another palette in the right 'stow
> bar', 

cool name :-)

> as I like to call it, possibly at the at the top. This would 
> display the filter's options. When the user okays or cancels the filter,
> this palette collapses again. This might be confusing, since filters are
> currently not dynamic in Krita (hence my pleas above). But palettess on
> the right only do display dynamic adjustable document properties as it
> stands.
> However, if filters all were to become adjustment layers in the future,
> one could do this as a 'preparation'/'conditioning' of users to that
> UI... ;)

Yes, well -- we're going there, but I still want to be able to keep filters 
that affect the pixels.

Of course, it could be as simple as always add an effect mask to a layer and 
then optionally choose to merge the effect mask with the layer -- which would 
be functionally equivalent to applying a filter now. That would obviate the 
need for previews, apply, apply as mask or cancel buttons.

> I once, in another life, used to be the product manager of Alias Eclipse
> (the same Alias that makes the highend 3D software Maya, well now it's
> Autodesk, not Alias, they bought them)...
>
> Eclipse was an imaging app that allowed one to easily compose 4GB multi
> layer image files on machines with 128 MB of RAM at the time. I can
> elaborate on how it did that (including filters that weren't burned into
> the image), if you're interested.

How did it do that? I'm very interested. I mean, Krita does a lot of heavy 
caching of pretty much everything (adj. layers keep a rendered cache of the 
stack of layers beneath it, layers that have effect masks keep a rendered 
cache of the result of applying all the masks to the layer's pixel data), but 
that that's heavy on memory. On the other hand, not doing that makes Krita 
really slow.

We've got a couple of performance bottlenecks right now, only some of which I 
already have figured out how to solve. One problem is dirty marking: we only 
want to recomposite (incl. re-applying dynamic filters) the areas that have 
changed. We do this using regions, i.e., collections of non-overlapping 
rects. But those degrade to scanlines really quickly -- see the thread with 
the title QRegion.

Another problem is that is we don't yet use the hooks to only recomposite 
visible area of the image -- I've added the code to our projection class, but 
the canvas classes don't call it yet. But that should be basically solved.

The third is that we're not yet using pyramids for scaling and so on -- our 
tile backend is up for a redesign. As soon as Bart's got some time again, 
he's going to work on that. I'm sure he'd be grateful for any pointers you 
can give him though :-).

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070620/0c84a48a/attachment.pgp