Robin Rowe wrote:
> Just so everyone knows, the GIMP has a different management style 
> than CinePaint and doesn't identify its team -- except for Yosh, 
> the GIMP release manager. Sven is perceived as the project manager 
> of GIMP.

I would like to clarify this - the GIMP is now 8 years old, 8 or
9 years old, and the original authors are long gone. What has
happened since then is something of a co-operative effort,
whereby a group of the current developers just kind of decide

This is haphasard at times, but it would be incorrect to say that
we don't identify our team. But the team changes very regularly.
That is not to say that certain characters who have been around
for a while do not have more credence than others. It might be
worthwhile to keep an up-to-date list of current developers,
along with their domains of interest/responsibility, but the
GIMP's authors are publicly acknowledged in the AUTHORS file.

I'm not sure how Sven feels about the title "Program manager" -
if it helps you to label him as such, then so be it. He is one of
the main developers around at the moment, and works more or less
full time on the GIMP, so he has more say in contentious issues
than blow-ins like me, but everyone is heard (often leading to
bikeshed arguments, but there we go), and decisions get made more
or less by concensus (which is a partly a factor in certain
things taking longer than they might).

> You are right that our gbr brushes are different from GIMP's. Although I
> appreciate you considering it, they can't be made fully compatible with GIMP
> because of bit depth. The best you could do would be to crush down to 8-bit
> when opening our 16-bit brushes.

As a proposal for a modification which would bring back
compatibility, we could expand the header by 4 bytes to include
bit depth (8 or 16), which could then be factored into the load
routines of both our apps (we would crush 16 bit nbrushes down to
8 bits, and you would expand 8 bit brushes to 16 bits). As a file
format change, it would allow is backward compatibility, since
the format changes nothing in the other header fields.

> By the way, where would I find your docs for the GIMP gbr format?

After reading this mail, I drew up a specification of the gbr
format. It's fairly straightformward, and is obvious from the
header files & source, but a text file documenting the format is
no harm.

I will put it in the devel-docs directory of the GIMP CVS, and
attach it inline here (I believe that our list software, and
probably yours, doesn't like attachments).


The GIMP Paintbrush File Format Version 2 (.gbr)


Bytes 0  - 3:  header_size: 
        Type: 32 bit unsigned int
        Value: size of brush header (28) + length of brush name

Bytes 4  - 7: version
        Type: 32 bit unsigned int 
        Value: The file format version. Currently

Bytes 8  - 11: width
        Type: 32 bit unsigned int 
        Value: Brush width

Bytes 12 - 15: height
        Type: 32 bit unsigned int 
        Value: Brush height

Bytes 16 - 19: bytes
        Type: 32 bit unsigned int 
        Value: Colour depth of brush. 
        1 = greyscale, 4 = RGBA

Bytes 20 - 23: magic_number
        Type: 32 bit unsigned int 
        Value: GIMP brush magic number. 
        ('G' << 24) + ('I' << 16) + ('M' << 8) + 'P'

Bytes 24 - 27: spacing
        Type: 32 bit unsigned int 
        Value: Default spacing to be used for brush. Percentage
        of brush width.

Bytes 28 - (header_size - 28):
        Type: char *
        Value: UTF-8 string - name of brush

        Size: width * height * bytes
        Type: uchar *
        Value: Pixel values (row-first) for brush

       David Neary,
       Lyon, France
Gimp-developer mailing list

Reply via email to