--===============1410723083==
Content-Type: multipart/signed;
  boundary="nextPart2109753.q41yEiZafB";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2109753.q41yEiZafB
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
this, and that is that needs to keep the paint strokes separate. The one=20
thing most artists complain about of imaging apps is that they cannot "push=
=20
gunk around". We're now working on making it possible to deposit a simulati=
on=20
of paint (or other gunk) on the canvas and then push it around with tools=20
like brushes, pencils and palette knives. I am not aware of any way to=20
simulate this kind of mixing and pushing while keeping the brush strokes=20
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=
=20
don't think I ever got a straight answer from Gegl's pipping about it) is=20
what you do with filters that affect an area of pixels on zoomed images. Sa=
y,=20
the simple oilpaint simulation filter that my kids love so much. It's not=20
only random, but it is an area effect filter. So, if you're working at 25%=
=20
zoom, you need to apply the filter at 100% zoom and then scale down again f=
or=20
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)=20

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=
=20
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,=
=20
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 g=
et=20
when searching for it are references to IBM's bloated IDE :-).
=2D-=20
Boudewijn Rempt=20
http://www.valdyas.org/fading/index.cgi

--nextPart2109753.q41yEiZafB
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGeYPgdaCcgCmN5d8RAvUxAJ9CLPZ8V5jiuINd1/NwtZ3f0vfbeACfQS3c
fwdliDLZwprN1lqOh9u5yFM=
=rrot
-----END PGP SIGNATURE-----

--nextPart2109753.q41yEiZafB--

--===============1410723083==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop

--===============1410723083==--