Hi,
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
stuff.
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).
Cheers,
Dave.
The GIMP Paintbrush File Format Version 2 (.gbr)
------------------------------------------------
HEADER
------
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
BODY
----
Size: width * height * bytes
Type: uchar *
Value: Pixel values (row-first) for brush
--
David Neary,
Lyon, France
E-Mail: [EMAIL PROTECTED]
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
