[Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
David,
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.
We're open to that. However, until someone volunteers and sends us a patch,
we have no one ready to take that effort when our format is about to be
replaced anyway.
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
Thanks, appreciate the docs!
To return the favor, enclosed is the spec for CPX that I posted in June. It
is so new it hasn't made it onto our web page docs yet. For clarification,
since my preliminary spec was rather terse, the data blob in CPX is a raw
write of the raster like the PPM P6 format. The CPX format was inspired by
the simplicity of PPM, but with the enhancement of XML tags. Like PPM, all
CPX tags are text but raster data is binary. See at the bottom below.
it would be incorrect to say that we don't identify our team.
I can clarify my meaning, although it seems a moot point. Some GIMP
developers are identified in internal documents within the source code, as
you correctly point out. However,when I asked for a list of developers on
the GIMP list I was told those documents were too inaccurate to be trusted.
It was suggested I could get the names of the GIMP developers by grepping
the check-in names from GIMP CVS -- which seemed a bit of bother -- but I
took the effort to do so anyway. I offered to give that list back to GIMP so
they could post a better public list of developer acknowledgements. The
response was that no new list should be posted by GIMP until it was perfect,
and that my list was inaccurate because Sven and others often check in
patches on behalf of others. I was also told my help wasn't needed.
FYI, using the best information I could gather, we have a list on our web
site recognizing the GIMP developers.
http://cinepaint.sourceforge.net/people/gimp.html
Cheers,
Robin
---
[EMAIL PROTECTED] Hollywood, California
www.CinePaint.org Free motion picture and still image editing software
- Original Message -
From: Robin Rowe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, June 07, 2003 3:11 PM
Subject: [CinePaint-dev] cpx file type
Hi. Just FYI, creating a new image format called CPX (CinePaint XML).
This format will be similar in simplicity to PPM but more flexible using
XML
tags. Both spec and code will be made available.
A 640x480 8-bit image file example.cpx would be laid out something like
this:
CPX
IMG width=640 height=480 depth=8u raster=RGB compress=none bytes=921600
data=...[921,600 raw bytes]...
'depth' may be 8u|16u|16f-ilm|16f-rnh|32f
'raster' may be RGB|RGBA|RGBAZ or alternatively 'planes' with the same
choices
A lot more features could be added later. This is just to let everyone
know
this is in the works and coming maybe in July.
Cheers,
Robin
--
-
[EMAIL PROTECTED] Hollywood, California
www.CinePaint.org Free motion picture and still image editing software
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
Hi, Alan Horkan [EMAIL PROTECTED] writes: The information about the files that are installed in the user The dialog tells you what the names of the files that are going to be installed but not their purpose or roughly how much space they will take. You need to play with the dialog a little more. It does tell you about the purpose of the files. It does only tell the interested user, but it does so. The user does not need to know about the General Public License (it does not apply unless you want to distribute modified versions). I know why developers want it there (evangelism) but it is annoying when Proprietary crap spews non essential license information at you (which most users ignore anyway) something most developers prefer not to copy. The point is that the GPL explicitely asks to present the user with this copyright notice on very startup. I think it is good style to do so at the very first startup at least. Find it annoying, I find it amusing and it definitely doesn't hurt. It will be a day or two before I can build from CVS and look at the changes that you said have been recently made. I dont see any mention in the Changelog yet http://cvs.gnome.org/lxr/source/gimp/ChangeLog The changes are not in CVS yet. The GIMP already does hide complexity in many ways, the GIMP has a menu item to Rotate 90 degrees, would you argue that Rotate is enough and that users are perfectly able to specify 90 degrees if they want it? This is a bad example since there are other reasons for this being a separate menu entry. Take the example of Red Eye correction, you can do Red Eye correction in the GIMP but many programs have a dialog specifically for doing this task which makes things easier but does not make the program any less powerful. We would certainly be happy to include such a dialog. I don't see your point here. We are constantly improving GIMP all over the place. I just don't see why we should put valuable developers time in removing features that have been added for a good reason in the first place. The user install dialog was added because it was needed. It serves its role, it works, there are hundreds of places where developers effort is better spent than in removing it. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pos- XCF file format
Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: the cross posting with the Cinepaint guys brougth this to light. So there is something being done about a XML file format to the GIMP. How is it's development going on? Some developers brainstorm about it from time to time. That's about it. Maybe it could come along with XCF, even though not being complete, on the 1.3.x series? Definitely not. The 1.3.x series is coming to an end and we will certainly not start to change our native file format a few weeks before the first release candidates for 2.0 are supposed to be ready. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [CinePaint-dev] GIMP/CinePaint fileincompatibility
Ernst, Couldn't both teams try to find a common format? In theory yes, but it seems unlikely. Sven said today that GIMP has been (privately) discussing a new XML-based file format for GIMP for more than three years -- which is the first I've heard of it. However, no spec has been made available. Without any knowledge of what GIMP was up to, I've been working on the design of a new XML-based file format for CinePaint for two months. I posted the preliminary spec for comment a month ago, and it is about to go into implementation. It could appear in CinePaint in as little as a month. We're not going to wait for GIMP. Cheers, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Free motion picture and still image editing software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
Hi, David Neary [EMAIL PROTECTED] writes: That said, some day soon, the GIMP developers are going to have to get together for a brainstorning session about how we can communicate better with the user base, and vice versa. With IRC, Bugzilla, 2 mailing lists, usenet, the [EMAIL PROTECTED] mail address, the web page and the GUG (wouldn't it be nice to tie in more tightly with those guys?), there is an awful lot of information flying about, but none of it is getting to everybody. Sven's talked about the dead documentation project, lots of usability issues have cropped up recently on the mailing list, and we seem to have become quite insular in our thinking. I would like us to sit down and talk about how we can make it easier for people to find out what's happenning with the GIMP, and easier for them to let us know what they thing should be happening. The long-due overhaul of the web-site could help to improve this situation. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
Hi, David Neary [EMAIL PROTECTED] writes: The new code is missing a #ifdef somewhere, I think - perhaps composite-mmx.c shouldn't be build at all if USE_MMX isn't defined... but that's another issue. I've added an #ifdef that causes the file content to be skipped. I prefer #ifdefs over automake conditionals since the latter tend to slow down the build and clutter the Makefile.am. My processor does support mmx. It passes the configure test - when I run the configure test manually (that is, load register %mm0 in a .S file), it works fine. However, the same thing in an asm() in a C file seems to not compile. Really weird... So config.h defines USE_MMX for you? Looks as if we have to improve the configure test. The check we use now is copied from DirectFB and seems to work there. In DirectFB we include the assembler code as __asm__ __volatile__ () while the new code in The GIMP seems to be using asm() I don't know this stuff good enough to know the difference, but I'd say we need to change the configure check so that is uses the same asm constructs that the code in app/composite is using. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
Hi David, could you please test the attached diff to configure.in. It should find the problem with your compiler and it even simplifies things a bit. Sven Index: configure.in === RCS file: /cvs/gnome/gimp/configure.in,v retrieving revision 1.465 diff -u -p -r1.465 configure.in --- configure.in9 Jul 2003 23:52:46 - 1.465 +++ configure.in10 Jul 2003 13:40:36 - @@ -423,14 +423,10 @@ AC_ARG_ENABLE(sse, if test x$enable_mmx = xyes; then - dnl Necessary for assembler sources - save_ac_ext=$ac_ext - ac_ext=S - AC_MSG_CHECKING(whether we can compile MMX code) - echomovq 0, %mm0 conftest.S - if AC_TRY_EVAL(ac_compile); then + AC_COMPILE_IFELSE([asm (movq 0, %mm0);], + AC_DEFINE(USE_MMX, 1, [Define to 1 if MMX assembly is available.]) AC_MSG_RESULT(yes) @@ -438,26 +434,21 @@ if test x$enable_mmx = xyes; then AC_MSG_CHECKING(whether we can compile SSE code) - echomovntps %xmm0, 0 conftest.S - if AC_TRY_EVAL(ac_compile); then + AC_COMPILE_IFELSE([asm (movntps %xmm0, 0);], AC_DEFINE(USE_SSE, 1, [Define to 1 if SSE assembly is available.]) AC_MSG_RESULT(yes) - else + , enable_sse=no AC_MSG_RESULT(no) AC_MSG_WARN([The assembler does not support the SSE command set.]) - fi + ) fi - - else + , enable_mmx=no AC_MSG_RESULT(no) AC_MSG_WARN([The assembler does not support the MMX command set.]) - fi - - rm conftest* - ac_ext=$save_ac_ext + ) fi @@ -472,24 +463,16 @@ AC_ARG_ENABLE(altivec, if test x$enable_altivec = xyes; then - dnl Necessary for assembler sources - save_ac_ext=$ac_ext - ac_ext=S - AC_MSG_CHECKING(whether we can compile Altivec code) - echovand %v0, %v0, %v0 conftest.S - if AC_TRY_EVAL(ac_compile); then + AC_COMPILE_IFELSE([asm (vand %v0, %v0, %v0);], AC_DEFINE(USE_ALTIVEC, 1, [Define to 1 if Altivec assembly is available.]) AC_MSG_RESULT(yes) - else + , enable_altivec=no AC_MSG_RESULT(no) AC_MSG_WARN([The assembler does not support the Altivec command set.]) - fi - - rm conftest* - ac_ext=$save_ac_ext + ) fi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
Sven Neumann wrote: We actually had something else in mind but since you don't seem to be interested I won't waste my time explaining our ideas. It is very sad to see that Sven thinks that Robin Rowe is the only person to whom his ideas should be told. Pity the rest of the GIMP developers (current and future) who might like to comment on it. Christopher ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
This isn't quite ready to go yet. But thanks for the note. The default build behaviour right now is to not build the new code. Helvetix On Thu, Jul 10, 2003 at 08:36:44AM +0200, David Neary wrote: Hi, The new MMX composite code in the 1.3 tree doesn't build for me - am I the only one? My processor is a 350MHz K6-2 with mmx support, and the error says that there are a bunch (6, I think) of unknown registers in the asm (%mm0, %mm1, ...). I'm mailing this to the list because, to be quite honest, I'm not sure how many people actually look at bugzilla these days apart from Sven and Raphael. But that's another issue... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
Hi, Christopher Curtis [EMAIL PROTECTED] writes: We actually had something else in mind but since you don't seem to be interested I won't waste my time explaining our ideas. It is very sad to see that Sven thinks that Robin Rowe is the only person to whom his ideas should be told. Pity the rest of the GIMP developers (current and future) who might like to comment on it. We will certainly write down more about this later but at the moment I focus on the release and on the developer conference. The ideas we had so far are quite rough but I will try to summarize them after the conference. I'm only willing to spend time on this right now if someone expresses actual interest. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: [CinePaint-dev] GIMP GBR format spec
[EMAIL PROTECTED] (2003-07-10 at 1140.21 -0400): It is very sad to see that Sven thinks that Robin Rowe is the only person to whom his ideas should be told. Pity the rest of the GIMP developers (current and future) who might like to comment on it. Use the list archives. Search engines let you restrict to servers. And IIRC basically it was about packing XML and some common image format like PNG into a some common archive format like TAR, so while not all soft will be able to open it, at least the user will be able to dissasamble it and load things by hand. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
On Thu, 10 Jul 2003, Sven Neumann wrote: The point is that the GPL explicitely asks to present the user with You are telling me that most of the programs in Gnome and KDE are wrong and the GIMP is right. I will go and read the GPL again and I will read the GPL FAQ and see if I can figure out where is this explicit requirement to display the license. this copyright notice on very startup. I think it is good style to do so at the very first startup at least. Find it annoying, I find it amusing and it definitely doesn't hurt. The changes are not in CVS yet. There was no way for me to know what the recent changes you made are, could you please say what they are? This is a bad example since there are other reasons for this being a separate menu entry. Bad example, fine I'll try another. The GIMP hides information, the GIMP hides the menus in a context/right click menu instead of up front in Menu (at least until recently, now there is at least an option which I am very thankful for). This is hiding useful information, this is adding one extra click to many operations. Many gimp users swear by hiding this information away and many more swear at it. I believe the standard excuse is screen space, but if screen space is really important to you then you would run the GIMP in fullscreen view (with or without a menubar*) which gets rid of the pixels wasted by the window manager (another recent addition it seems). (* Photoshop allows a menubar in fullscreen mode which really allows you to make the most of the available space and still have the convenience of a menubar. If the GIMP does I have not yet figured out how to keep the menubar turned on in Fullscreen mode) Take the example of Red Eye correction, you can do Red Eye correction in the GIMP but many programs have a dialog specifically for doing this task which makes things easier but does not make the program any less powerful. I thought this might be a better example of how hiding unnecessary detail make an application more useful not less useful. If asking all these questions at startup is such a good idea why not ask the users even more questions, why not get them to set every preference? If this is such a good idea why are no other Gnome or KDE programs doing this? Does the operating system or distribution you use include many programs that ask you many questions before you are allowed to use them for the first time? just don't see why we should put valuable developers time in removing I am not asking you to do it. I am asking you to let it happen. The attitude I keep encountering is a strong resistance to progress. I know I probably should have fough for these changes earlier in the 1.3.x cycle but most distributions still ship Gimp 1.2.x. The bulk of GIMP users are not using 1.3.x yet. For most users the changes are going to be quite dramatic anyway which is why I dont understand why my suggestions are so contraversial. I want you to accept that changes like these could and should be made and to stop dragging your heels just because that is the way things are now and have been before instead of giving real reasons for things being the way they are. If you were more receptive then I would be able to go off and worry about getting a suitable patch done (by me or with help or whatever). Sincerely Alan Horkan. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
Hi, Alan Horkan [EMAIL PROTECTED] writes: You are telling me that most of the programs in Gnome and KDE are wrong and the GIMP is right. I will go and read the GPL again and I will read the GPL FAQ and see if I can figure out where is this explicit requirement to display the license. You will certainly find it since it is pretty clear. Almost all GUI applications ignore it however and the GIMP isn't any better. If we would take this really really seriously, we'd have to add a GPL disclaimer to the splash screen. There was no way for me to know what the recent changes you made are, could you please say what they are? I already said that the changes are minor. Basically some UI polishing, nothing that would be worth calling a change. (* Photoshop allows a menubar in fullscreen mode which really allows you to make the most of the available space and still have the convenience of a menubar. If the GIMP does I have not yet figured out how to keep the menubar turned on in Fullscreen mode) Go to the menu and toggle View Menubar. How did you miss this? I am not asking you to do it. I am asking you to let it happen. As I said, the user installation dialog was added for a number of reasons. I don't see why I should let it disappear for no good reason. The attitude I keep encountering is a strong resistance to progress. Sorry, but removing features looks more like a regression to me. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
On Thu, 10 Jul 2003 19:25:22 +0200 Sven Neumann [EMAIL PROTECTED] wrote: The attitude I keep encountering is a strong resistance to progress. Sorry, but removing features looks more like a regression to me. I agree, but if on the second window there is 2 buttons, one to skip the other installation window and one to continue as it is now, is this a regression ? The fact is that people are not stupid but 95% use only 5% of the nice features of Gimp and don't need special settings. Then I'd prefer to see some other settings in the installation process like the default interpolation. @+ Raymond ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
Sven Neumann wrote: Hi David, could you please test the attached diff to configure.in. It should find the problem with your compiler and it even simplifies things a bit. I have stried, and my computer passes the mmx test with flying colours :) It seems that the thing which is annoying my compiler is teh doubling of the % signs - with one % all passes well, with two, not so well. A sligntly modified configure confirms this. Are the two %s necessary to prefix the mm registers? Thanks for the patch, though. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
