Filters "dialog" in 2.0

[Boudewijn Rempt]

On Wednesday 20 June 2007, Moritz Moeller wrote:

> Only because most 2D still imaging apps suck balls the size of planets.
> That particularly include Photoshop. None of the 2D compositing apps we
> use when creating visual effects is that destructive.
> And the other thing is that many people never experienced the very
> pleasure of working an a totally non-destructive imaging app...


Hm, hm... I certainly never have. But there is one thing bordering me about 
this, and that is that needs to keep the paint strokes separate. The one 
thing most artists complain about of imaging apps is that they cannot "push 
gunk around". We're now working on making it possible to deposit a simulation 
of paint (or other gunk) on the canvas and then push it around with tools 
like brushes, pencils and palette knives. I am not aware of any way to 
simulate this kind of mixing and pushing while keeping the brush strokes 
distinct.

> Simply by only ever rendering what was on screen. If you think about it
> -- at the time high res 19" Sony screens used on the SGI workstations
> this app ran on had max 1280x960. Mostly it was 1024x748. Now subtract
> the screen space taken by the palettes.
> So all you ever have to render (and keep in memory), in the worst case
> is this data (maybe 800x600x24bits.

Yes -- that should help. One problem here I've often wondered about (and I 
don't think I ever got a straight answer from Gegl's pipping about it) is 
what you do with filters that affect an area of pixels on zoomed images. Say, 
the simple oilpaint simulation filter that my kids love so much. It's not 
only random, but it is an area effect filter. So, if you're working at 25% 
zoom, you need to apply the filter at 100% zoom and then scale down again for 
display. Which would hurt render speed a lot.

> If you cache data out to disk in a tiled fashion (think of TIFF using
> tiles instead of bloody scanlines) and you keep a tile cache in RAM that
> you populate with data around the area you're working...
>
> Furthemore, one can create mip-map levels (what you call pyramids, I
> think) 

yes, I think that that's the same thing.

> All brush strokes were cubic bezier splines. This also meant one could
> change a stroke hours after it had been placed and it could be rendered
> at any resolution. I'd rip code from Inscape. Their path reconstruction
> while freehand drawing is one of the best I've seen and that include
> commercial packages.

That would be something for Cyrille to look at; I know he's been working on 
that kind of code for our freehand tool this very week.

> And also, instead of a disk tile cache that eclipse used, I'd use
> something that uses RAM and only swaps least accessed tiles out to disk.

We're also experimenting with having a three-phase cache: tiles in memory, 
compressed tiles in memory and compressed tiles swapped out to disk.

> Lastly, there's another app which works this way but had a similarly
> horrible interface as Eclipse: Satori Paint on Windows.

I'll look at that. Eclipse has a big problem right now with google: all I get 
when searching for it are references to IBM's bloated IDE :-).
-- 
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/1a8496e7/attachment.pgp