From kde-kimageshop Thu Sep 24 22:00:16 2009 From: Sven Langkamp Date: Thu, 24 Sep 2009 22:00:16 +0000 To: kde-kimageshop Subject: Re: Whither Krita? Message-Id: <478b087a0909241500t7b490de3j8f67eb49d4982fc3 () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=125382967026283 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1007375854==" --===============1007375854== Content-Type: multipart/alternative; boundary=00504502c7a2e2c5e1047459f48a --00504502c7a2e2c5e1047459f48a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 24, 2009 at 10:44 PM, Moritz Moeller wrote: > On 09/20/2009 08:48 PM, Boudewijn Rempt wrote: > > On Saturday 19 September 2009, Moritz Moeller wrote: > > > >> There is another few posts of mine, in the archives (from 2007, I > >> think), where I already tried advertising these approaches. Might help > >> digging the resp. thread out, to understand better where I'm coming > from. > >> :) > > > > The big problem with this is that it would be a wonderful project, but > going > > this way simply means starting completely from scratch. Nothing in the > current > > krita codebase will be at all useful (well, maybe some color > selectors...). > > I think "from scratch" is exaggerating greatly. I made two propsals. One > is for a node based core. > The other was for procedural bushes. > Neither requires the other to be implemented. Procedural brushes bring > many advances, even w/o a node-based core. > I think the "from scratch" was targeted at you reyes proposal. > As for the latter. This would indeed mean replacing the core with a node > system. I don't know how well abstracted interaction of the core is, for > any part of Krita making use of it. > But if it was abstraced sufficiently, replacing the core and providing > backwards compatibility to keep a big chunk of the exisiting code that > is non-core, should be possible. > Because a layer baed system can easily be expressed in a node-based system. > The reverse is btw not true. Photosop tries hard these days, having now > smart-objects and cascaded layer groups. But this is still far from the > flexibility of a node based system. > It's always the question how much you want expose the node system to the user. Some users might be overwhelmed by it. > > And I know that I lack the skills to setup such a project and get it > anywhere > > meaningful :-( > > Which one? Node-based core or procedural brushes. I can help out with > how to implement these. I am really sorry that I don't have more time, I > would love to write a reference implememtation of procedural brushes at > least. > > I can also assure you that neither is any harder to implement than > anything Krita does currently. :) > A node based core is cretainly a lot of work. Really a lot. Procedural > brushes aren't > Editing draw strokes might be nice if you do it like MyPaint only for the last stroke. It gets more complicated to use if you want to modify single path points, just try to modify a calligraphy stroke in Karbon. Saving the path would get a possible maintainance problem as future paintops have to work in the same way to keep the image looking the same. If you send someone a picture he needs all the paintops you used to create your image, so you would have to included the whole image as fallback. --00504502c7a2e2c5e1047459f48a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 24, 2009 at 10:44 PM, Moritz Moeller= <realritz= @virtualritz.com> wrote:
On 09/20/2009 08:48 PM, Boudewijn Rempt wrote:
> On Saturday 19 September 2009, Moritz Moeller wrote:
>
>> There is another few posts of mine, in the archives (from 2007, I<= br> >> think), where I already tried advertising these approaches. Might = help
>> digging the resp. thread out, to understand better where I'm c= oming from.
>> =A0 :)
>
> The big problem with this is that it would be a wonderful project, but= going
> this way simply means starting completely from scratch. Nothing in the= current
> krita codebase will be at all useful (well, maybe some color selectors= ...).

I think "from scratch" is exaggerating greatly. I made two = propsals. One
is for a node based core.
The other was for procedural bushes.
Neither requires the other to be implemented. Procedural brushes bring
many advances, even w/o a node-based core.

I think= the "from scratch" was targeted at you reyes proposal.
=A0
As for the latter. This would indeed mean replacing the core with a node system. I don't know how well abstracted interaction of the core is, fo= r
any part of Krita making use of it.
But if it was abstraced sufficiently, replacing the core and providing
backwards compatibility to keep a big chunk of the exisiting code that
is non-core, should be possible.
Because a layer baed system can easily be expressed in a node-based system.=
The reverse is btw not true. Photosop tries hard these days, having now
smart-objects and cascaded layer groups. But this is still far from the
flexibility of a node based system.

It's always the question how much you want expose the node sy= stem to the user. Some users might be overwhelmed by it.
=A0
> And I know that I lack the skills to setup such a project and get it a= nywhere
> meaningful :-(

Which one? Node-based core or procedural brushes. I can help out with=
how to implement these. I am really sorry that I don't have more time, = I
would love to write a reference implememtation of procedural brushes at
least.

I can also assure you that neither is any harder to implement than
anything Krita does currently. :)
A node based core is cretainly a lot of work. Really a lot. Procedural
brushes aren't

Editing draw strokes might be = nice if you do it like MyPaint only for the last stroke. It gets more compl= icated to use if you want to modify single path points, just try to modify = a calligraphy stroke in Karbon.

Saving the path would get a possible maintainance problem as future pai= ntops have to work in the same way to keep the image looking the same. If y= ou send someone a picture he needs all the paintops you used to create your= image, so you would have to included the whole image as fallback.
--00504502c7a2e2c5e1047459f48a-- --===============1007375854== 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 --===============1007375854==--