Hi,

first of all, the application is called GNU Image Manipulation Program, or short GIMP, but not "The Gimp". Please try to keep that in mind.

On Sun, 2009-03-08 at 18:56 +0530, sumith pandilwar wrote:

I am ineterested to apply for Gsoc 2009 - the gimp org.In the ideas of Gsoc 2008 there was a idea of implementing brushes that could be scaled up in a lossless way using svg files as brushes.I have the code of gimp 2.64 .So i need help to know what to start with. I will be very much thankful to receive some advice.

If you want to work on GIMP, you should check out current trunk from the Subversion repository at svn.gnome.org. The brush transformation code in trunk is quite different from GIMP 2.6 already. It should be very easy to add support for SVG brushes. Perhaps even too easy for a GSoC project. But we would first need to look at this in more detail. Can you give a more detailed description of what you have in mind for your project?

Sven

On Wed, Mar 11, 2009 at 7:52 PM, sumith pandilwar wrote:

by adding support for svg files i would like to add the feature to import svg file and modify its properties like colour, fade out etc and use it like a brush.This would be like totally creating a new brush of our own

Maybe it could be a 'brush tool rewrite in GEGL' project? I mean, in GEGL you already can load SVG and do things like the ones you listed, and we need to port tools anyway...

Alexandre

sumith pandilwar wrote:

hi,
thanks for the reply.Will you please help me with understanding the code of The GNU image manipulation program ,the modules etc so that i could understand better and present the project in a better manner

Hi

I would recommend that you join #gimp on the irc.gnome.org network since that is a better forum to help you get started with the GIMP code.

BR, Martin

Hi,

On Wed, 2009-03-11 at 22:22 +0530, sumith pandilwar wrote:

by adding support for svg files i would like to add the feature to import svg file and modify its properties like colour, fade out etc and use it like a brush.This would be like totally creating a new brush of our own

OK, let's have a look at using SVG for brushes in GIMP. With the current state of brush transformations in trunk, we are nicely prepared for vector brushes. Brush transformations currently are affine transformations and as such they can easily be applied on an SVG. So all that is needed is to create a new brush type GimpBrushVector similar to GimpBrushGenerated. This vector brush would load its data from an SVG file. If we accept linking the core against librsvg we can easily import any SVG file and render it using rsvg_handle_render_cairo(). Being able to render the brush to a Cairo surface is an extra plus as that will allow the paint tools to render a nice brush preview on the canvas as soon as we finally port tool drawing to Cairo.

It's not clear though how exactly an SVG file that represents a brush should be interpreted. What I described above basically means we just treat it as a scalable image. Basically all SVG images could be used as brushes then and would behave like pixmap brushes except that they would look better when transformed. Probably not exactly what we want. We also need the notion of grayscale vector brushes that define a brush mask that is colored by the foreground color. We also need meta information such as the brush name and the default brush spacing. It's not entirely clear to me how such an SVG brush should look like. Do we expect GIMP-specific XML elements in the SVG ?

In order to come to a conclusion whether GIMP should have support for SVG brushes and if that would be a good project for GSoC we need a clearer vision of what an SVG brush is. Perhaps someone else here wants to share his ideas?

Sven

Hello,

On Fri, Mar 13, 2009 at 10:09 AM, Sven Neumann wrote:

Hi,

On Wed, 2009-03-11 at 22:22 +0530, sumith pandilwar wrote:

by adding support for svg files i would like to add the feature to import svg file and modify its properties like colour, fade out etc and use it like a brush.This would be like totally creating a new brush of our own

OK, let's have a look at using SVG for brushes in GIMP. With the current state of brush transformations in trunk, we are nicely prepared for vector brushes. Brush transformations currently are affine transformations and as such they can easily be applied on an SVG. So all that is needed is to create a new brush type GimpBrushVector similar to GimpBrushGenerated. This vector brush would load its data from an SVG file. If we accept linking the core against librsvg we can easily import any SVG file and render it using rsvg_handle_render_cairo(). Being able to render the brush to a Cairo surface is an extra plus as that will allow the paint tools to render a nice brush preview on the canvas as soon as we finally port tool drawing to Cairo.

It's not clear though how exactly an SVG file that represents a brush should be interpreted. What I described above basically means we just treat it as a scalable image. Basically all SVG images could be used as brushes then and would behave like pixmap brushes except that they would look better when transformed. Probably not exactly what we want. We also need the notion of grayscale vector brushes that define a brush mask that is colored by the foreground color. We also need meta information such as the brush name and the default brush spacing. It's not entirely clear to me how such an SVG brush should look like. Do we expect GIMP-specific XML elements in the SVG ?

I think we would have to. At least, in my vision, where we want GIH/GBR to be eventually deprecated in preference of SVG. This would require 2 things:
a) support multiple brushes in a SVG brush file, ala GIH (presumably a group for each brush)
b) support including ranks etc. information in the SVG brush file. IMO a GIMP-specific XML element is appropriate here, for that and brush rendering type information as you said. Probably require a specific naming scheme, to simplify implementation of ranks.

For bitmap images in SVG brush files (eg. for patterning), we will probably want to use embedded images. Eventually for parametrizable brushes, we'll want to support external bitmap references (in which case we'll need to consider how to ensure that the user gets the right resources and that reference links are resolved correctly (probably relative to the .gimp-2.X/ toplevel directory)). Does inkscape do this kind of embedding? How is it accessed?

Eventually, I would expect that we could have things like brushes with FGcolor on one side and BGcolor on the other by binding SVG object attributes to gimp context attributes. An initial SVG brush implementation IMO should be careful not to get in the way of this kind of binding (mainly by respecting the possibility that the 'pixels' of a brush may change, just like gradients with FG/BG embedded do.)

Lastly (and more distantly): Deluxe paint had a 'Animbrush' feature which was extremely nice for animating moving objects (simple or complex). http://www.youtube.com/watch?v=5fF1OYaobPA demonstrates how it works. IMO this is a very helpful feature and we should accommodate the possibility of an eventual implementation. GIH's 'sequential' selection method comprises part of this. The other might be a method to hook frame-flipping (so GAP could implement it's own notion of frame flipping).

Anyway, IMO a basic SVG brush implementation would be about as simple as you've said.

David

Hi,

On Fri, 2009-03-13 at 15:50 +1030, David Gowers wrote:

I think we would have to. At least, in my vision, where we want GIH/GBR to be eventually deprecated in preference of SVG. This would require 2 things:
a) support multiple brushes in a SVG brush file, ala GIH (presumably a group for each brush)

How useful are brush pipes (or image hoses) really? As far as I can see their primary use is for simulating brush transformations. We can already do that better on the fly.

b) support including ranks etc. information in the SVG brush file. IMO a GIMP-specific XML element is appropriate here, for that and brush rendering type information as you said. Probably require a specific naming scheme, to simplify implementation of ranks.

For bitmap images in SVG brush files (eg. for patterning), we will probably want to use embedded images. Eventually for parametrizable brushes, we'll want to support external bitmap references (in which case we'll need to consider how to ensure that the user gets the right resources and that reference links are resolved correctly (probably relative to the .gimp-2.X/ toplevel directory)).

Why don't we just use PNG files for bitmap brushes?

Sven

On Fri, Mar 13, 2009 at 1:22 PM, Sven Neumann wrote:

How useful are brush pipes (or image hoses) really? As far as I can see their primary use is for simulating brush transformations. We can already do that better on the fly.

Use of image hose for brush transformation is abuse that hopefully is no longer needed. They are useful ho ever for complex animated brushes and as such should remain to be supported. I myself have made for example a hose brush that creates weaving lines. Another use is grass and fur brushes that need random and varying shaped stamps. All very valid and common usecases.

Supporting SVG hoses would allow for much better quality bushes for such applications.

I have been thinking about SVG as direct brush format and I think that using specifically named meta data fields for the SVG should be enough. I think its important to allow the use of stock inkscape to create such brushes.

For multiple stamps in one file layers should be used just like for image hoses now in gimp.

Hello,

On Fri, Mar 13, 2009 at 9:52 PM, Sven Neumann wrote:

Hi,

On Fri, 2009-03-13 at 15:50 +1030, David Gowers wrote:

I think we would have to. At least, in my vision, where we want GIH/GBR to be eventually deprecated in preference of SVG. This would require 2 things:
 a) support multiple brushes in a SVG brush file, ala GIH (presumably a group for each brush)

How useful are brush pipes (or image hoses) really? As far as I can see their primary use is for simulating brush transformations. We can already do that better on the fly.

As Alexia said, animation; and irregular brushing, arbitrary/complex effects (eg making pressure correspond to darkening + gradient mapping (which is different from darkening a gradient mapped brush)); clever usage can make them quite effective for building textures, and the list goes on.
Of course, we could also do that if the brush dynamics allowed us to select between multiple brushes according to input values. But that strikes me as demanding too much from the user.

For bitmap images in SVG brush files (eg. for patterning), we will probably want to use embedded images. Eventually for parametrizable brushes, we'll want to support external bitmap references (in which case we'll need to consider how to ensure that the user gets the right resources and that reference links are resolved correctly (probably relative to the .gimp-2.X/ toplevel directory)).

Why don't we just use PNG files for bitmap brushes?

That's fine by me. However it doesn't relate to what I mentioned above - SVG brushes that use bitmaps as resources (patterns etc) - 'mainly-vector' brushes.

David

Hi,

On Fri, 2009-03-13 at 13:34 +0200, Alexia Death wrote:

Use of image hose for brush transformation is abuse that hopefully is no longer needed. They are useful ho ever for complex animated brushes and as such should remain to be supported. I myself have made for example a hose brush that creates weaving lines. Another use is grass and fur brushes that need random and varying shaped stamps. All very valid and common usecases.

Do we need the full complexity of the current image hoses for this? Looks like a simple linear series of brushes could be sufficient.

I have been thinking about SVG as direct brush format and I think that using specifically named meta data fields for the SVG should be enough. I think its important to allow the use of stock inkscape to create such brushes.

We can't depend on Inkscape to add the GIMP-specific data. So it looks like the main job of this project would be to add a user interface to GIMP that allows to import SVG files and saves them with additional data as GIMP vector brushes in the GIMP brush folder.

It will also be tricky to read this data back when loading the SVG brush. As far as I can see, librsvg doesn't provide any hooks for application-specific data in the SVG file. We might have to parse the file twice, but I guess that's OK. We would just mmap the brush file and pass it through a GimpXmlParser for the metadata and to rsvg_handle_new_from_data() to get the SVG rendered.

For multiple stamps in one file layers should be used just like for image hoses now in gimp.

SVG doesn't have a concept of layers. It does support animation, but animation in SVG is rather complex and not well suited for our needs.

Sven

Hello,

On Fri, Mar 13, 2009 at 10:32 PM, Sven Neumann wrote:

Hi,

Do we need the full complexity of the current image hoses for this? Looks like a simple linear series of brushes could be sufficient.

No and no respectively, IMO.
Don't need full image-hose functionality for this; however IMO at least 2d sets of brushes are required for good flexibility (and then, lets say that we can map 'pressure' to 'brush dimension 1' and 'random' to 'brush direction 2' and this is a typical kind of user experience. IMO this is both a comfortable and flexible setup), and supporting 3d sets would reasonably cover the possibilities of 'unexpected utilizations'.

I have been thinking about SVG as direct brush format and I think that using specifically named meta data fields for the SVG should be enough. I think its important to allow the use of stock inkscape to create such brushes.

We can't depend on Inkscape to add the GIMP-specific data. So it looks like the main job of this project would be to add a user interface to GIMP that allows to import SVG files and saves them with additional data as GIMP vector brushes in the GIMP brush folder.

It will also be tricky to read this data back when loading the SVG brush. As far as I can see, librsvg doesn't provide any hooks for application-specific data in the SVG file. We might have to parse the file twice, but I guess that's OK. We would just mmap the brush file and pass it through a GimpXmlParser for the metadata and to rsvg_handle_new_from_data() to get the SVG rendered.

For multiple stamps in one file layers should be used just like for image hoses now in gimp.

SVG doesn't have a concept of layers. It does support animation, but animation in SVG is rather complex and not well suited for our needs.

Groups is fine for this IMO -- it's the same way that Inkscape stores all it's icons in one file; same principle (and, inkscape layers render down to SVG groups :)
We would just need to ensure meaningful IDs for the group (eg brush_00_01 for the brush at coordinate 0,1 in brush dimensions)

David

On Fri, Mar 13, 2009 at 7:58 AM, David Gowers wrote:

Hello,

On Fri, Mar 13, 2009 at 9:52 PM, Sven Neumann wrote:

How useful are brush pipes (or image hoses) really? As far as I can see their primary use is for simulating brush transformations. We can already do that better on the fly.

As Alexia said, animation; and irregular brushing, arbitrary/complex effects (eg making pressure correspond to darkening + gradient mapping (which is different from darkening a gradient mapped brush)); clever usage can make them quite effective for building textures, and the list goes on.

One of my primary use for Gimp these days is in making fantasy cartography. I use progressive bitmap brushes (hose/tube/whatever) an incredible amount, whether spraying down random trees, random mountains, random grass textures, random buildings, creating complex stipple patterns, and so on.

To be honest, this is one of the biggest questions from ps users that I hear..."can I randomly paint from a set of pixmap brushes?" and the standard response posted is no...try Gimp :)

-Rob A>

On Friday 13 March 2009 14:02:04 Sven Neumann wrote:

Hi,

On Fri, 2009-03-13 at 13:34 +0200, Alexia Death wrote:

Use of image hose for brush transformation is abuse that hopefully is no longer needed. They are useful ho ever for complex animated brushes and as such should remain to be supported. I myself have made for example a hose brush that creates weaving lines. Another use is grass and fur brushes that need random and varying shaped stamps. All very valid and common usecases.

Do we need the full complexity of the current image hoses for this? Looks like a simple linear series of brushes could be sufficient.

I agree with David here. Id say allowing max 3 dimensions is enough. Bushes should indicate default driving dynamics for these dimensions but the user should be able to remap them to any dynamic they desire. I will make it part of dynamics spec Im going to write for Peter so he can think of UI.

The image hoses code is long due overhaul because the dynamics system now in core and this concept change should be part of it.

-- Alexia

Hi,
00ai99@gmail.com (2009-03-13 at 2306.16 +1030):

Do we need the full complexity of the current image hoses for this? Looks like a simple linear series of brushes could be sufficient.

No and no respectively, IMO.
Don't need full image-hose functionality for this; however IMO at least 2d sets of brushes are required for good flexibility (and then, lets say that we can map 'pressure' to 'brush dimension 1' and 'random' to 'brush direction 2' and this is a typical kind of user experience. IMO this is both a comfortable and flexible setup), and supporting 3d sets would reasonably cover the possibilities of 'unexpected utilizations'.

The current system is an array that gets chopped into dimensions. I tried to test four things at the same time, multiple layers of N*M brushes gives three, layers grouped in two sets gives the 4th. Tilt eats two by itself.

The issues with GIH being rare is that you have to "load, edit, save" for every slight change, and that the interface to create those 4 groups is not so good. So it becomes cumbersome, even when you have the source file (without, it just becomes insane), and the real use decreases. If you do not have to create or tweak them, then they are great.

So notice where is the problem, creation/edit, not the pipes per se.

GSR