Brush spacing / rotate / scale

david powell achiestdragon at
Fri Nov 16 17:25:05 CET 2007

firstly to mm , i know my explanation may have been wrong but it 
highlighted the amount of proccesing needed 

On Friday 16 November 2007 15:29:28 Valerie VK wrote:
> Moritz, I'll admit that I have no idea what you're talking about,
> but I assure you that this is due to my ignorance as a non-
> programmer. That said, I also suspect that at least some of the
> developers here are unfamiliar with the territory you're
> mentioning. I can see that this is something Big, it just seems
> too novel for this one thread to handle. :-)
> My experience is that when you try to explain something through
> addressing individual points raised during a conversation,
> often you can spend hours and still not get the point accross.
> But if you step aside and prepare a clear presentation instead,
> with graphs and point-by-point explanations, then suddenly
> everything becomes clear.
maybe so but it can take days to do the graphs and charts required to 
make the explanation in that way 

and i doubt that the developers have the time to create them

> Very likely, something like this will require a huge reworking of
> Krita's internal architecture, and may also require intensive
> rethinking of Krita's interface (if for example, the notions of
> raster and vector truly get merged, how does that leave the tools?).
hmm theres distinct diferences in the 2 and advantages of each 
unfortunately merging the 2 you encounter the disadvantages of eather

in vector you can say draw a circle , thats 50% of the image space 
and regardles of zoom on part of it the edge is always a true curve
now in raster once you zoom to the pixel level you see the stepping 
as it jumps from one row to the next 

now  vector is more of what you need in cad , and raster is better for 
pictures and imaging
conversion from  vector to raster is easy , but its almost imposible to do the 
conversion the other way and gain any advantage of it being vector from it 

from a drawing and tool point of view theres no real diference

to use an analogy  you can create a ball machined down to nanometer acuracy 
but if then create a lego  model of it ( like a conversion from vector to 
raster) then it may look like a ball from a distance 
now if you converted it back it would still look like the lego version 
even if the surface was accurate to nanometer acuracy  

the diferance for tools is only in the way the image is stored 
in raster its the visual representation of that object in a bit map
in vector its a discription of how to generate the shape/s 

but the tool to draw a circle in one is the same as the other

now about the best i can see as an option is the abilaty to import vector 
images into krita and convert them to raster  , any attempt to use raster 
methods would not allow it to save in vector anyway

now it may be possible but its not true vector to export in vector but only if 
the vector supports an object in the image as being a bitmaped raster object 
then you still have none of the advantages other than you can possibaly 
indipendantly move the object around of it being vector  

> Long ago, Gimp had this great concept called GEGL. Implementation
> though went eeeeeh, slow. With such an extensive architecture
> rework, this procedure you're talking about will probably first
> need an external prototype that can later be migrated to Krita.
> So we'll probably need:
> - a paper explaining exactly what this does and how it works (like
> what you've explained already, along with charts and stuff), and
> how it benefits the end user
> - a few graphs to explain the concept in more detail, including
> necessary coding components that can be assigned to different
> developers.
> - a major architecture rediscussion of Krita, including major UI
> and tools rework for the added functionalities
> - a migration plan into Krita, so it won't just sit there.
> Migration will probably be progressive, with both tools being
> developed side by side.
> - then the prototype independent of Krita can be created
> - once it matures, it can be progressively implemented into Krita.
> How does that sound? :)
> Very likely, it can't be implemented before Krita 2.0, so maybe
> you can use this time to prepare the first two items as detailed
> explanations. Maybe once you get this organized, it won't sound
> so "strange." :P
> Once 2.0 is out of the door, developers can be rounded up to
> seriously start discussing the various components, and see if
> it is possible to implement this for Krita 3.0 or for a later
> release. Then a separate project can be initiated for the
> prototype, all the while actively recruiting more developers for
> the task.
> Good?


> ___________________________________________________________________________
>_________ Be a better pen pal.
> Text or chat with friends inside Yahoo! Mail. See how. 
> _______________________________________________
> kimageshop mailing list
> kimageshop at

More information about the kimageshop mailing list