From kde-kimageshop Wed Jun 20 19:06:51 2007 From: Boudewijn Rempt Date: Wed, 20 Jun 2007 19:06:51 +0000 To: kde-kimageshop Subject: Re: Filters "dialog" in 2.0 Message-Id: <200706202106.51561.boud () valdyas ! org> X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=118236651706926 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1636425208==" --===============1636425208== Content-Type: multipart/signed; boundary="nextPart1861244.RnMUqsns7S"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1861244.RnMUqsns7S Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 manipulatin= g=20 them. Currently we have effect masks (a per-layer set of masks associated=20 with a filter) and adjustment layers (a filter in between a stack of layers= ).=20 One problem here is that we have some filters that have a random effect: we= =20 haven't figured out yet how to stop the filter being random after being=20 inserted as an effect mask or an adjustment layer. Still, I also want to keep the ability to actually hard-change the pixels i= n a=20 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= =20 effect masks are and will be right in the layers palette, drag & droppable= =20 and manipulatable. One good thing about the docker palette idea is that it can be updated to s= how=20 the config of the current adj. layer or effect mask -- one problem is that= =20 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',=20 cool name :-) > as I like to call it, possibly at the at the top. This would=20 > 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= =20 that affect the pixels. Of course, it could be as simple as always add an effect mask to a layer an= d=20 then optionally choose to merge the effect mask with the layer -- which wou= ld=20 be functionally equivalent to applying a filter now. That would obviate the= =20 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= =20 caching of pretty much everything (adj. layers keep a rendered cache of the= =20 stack of layers beneath it, layers that have effect masks keep a rendered=20 cache of the result of applying all the masks to the layer's pixel data), b= ut=20 that that's heavy on memory. On the other hand, not doing that makes Krita= =20 really slow. We've got a couple of performance bottlenecks right now, only some of which= I=20 already have figured out how to solve. One problem is dirty marking: we onl= y=20 want to recomposite (incl. re-applying dynamic filters) the areas that have= =20 changed. We do this using regions, i.e., collections of non-overlapping=20 rects. But those degrade to scanlines really quickly -- see the thread with= =20 the title QRegion. Another problem is that is we don't yet use the hooks to only recomposite=20 visible area of the image -- I've added the code to our projection class, b= ut=20 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= =20 tile backend is up for a redesign. As soon as Bart's got some time again,=20 he's going to work on that. I'm sure he'd be grateful for any pointers you= =20 can give him though :-). =2D-=20 Boudewijn Rempt=20 http://www.valdyas.org/fading/index.cgi --nextPart1861244.RnMUqsns7S 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) iD8DBQBGeXrLdaCcgCmN5d8RAnmKAKDB13x1qcIUumoqd86j9wTVKs02EQCePNZW GR54OlhtCSmO61rIX6ozVMU= =QqL4 -----END PGP SIGNATURE----- --nextPart1861244.RnMUqsns7S-- --===============1636425208== 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 --===============1636425208==--