auto-save and file formats
Hi people, I'm developing Ogg Vorbis, the free audio compression codec. I'm writing a tool to tune the psychoacoustic model. For that I'm changing the values of some hundred numbers while listening to a piece of music. I can already do that in a text editor, but that's tedious. So I "invented" a new way of human computer interaction for this purpose. I'm going to create an image file with as many pixels as I have numbers, then paint the image and extract the values from that image file, and listen to the music all the time. I think I'll do that with a grayscale image, and I'd like to use GIMP for that. Here are my two questions: 1. When are you going to implement auto-save? I can already use GIMP with manual saving, but an auto-save function with a saving interval of down to 10 ms (if that's possible) would let me track my changes constantly. 2. Which of the file formats that GIMP can write would be best to just extract the color values of all pixels? It should be easy and fast. I've found xpm, that would work. But with xpm I still have to look up the color for each pixel in a table. Is there a format that simply stores the color values for each pixel directly? Thanks for your help. Robert
Re: auto-save and file formats
Stephen J Baker wrote: Rather than repeatedly saving to disk, you'd probably want a plugin that could copy the current image into shared memory - that would be a gazillion times faster I think. Uff, that's beyond my horizon. Any chance anyone would work with me or another Vorbis guy to do that? Not now, but in 1 or 2 weeks. Uncompressed SGI '.rgb' format is pretty close. Could you point me to some documentation on that format?
Re: auto-save and file formats
Uncompressed SGI '.rgb' format is pretty close. I suggest pnm format. In ASCII it just uses numbers between 0 and 255 to represent colors. That's about as simple as it gets.
Re: Magicless file formats
Sven Neumann wrote: Hi, If a properly named Targa file is not correctly loaded by GIMP, then another plug-in (for example faxg3) uses a file magic that fits this targa file. So which plug-in should load the file ? The one that has the correct file magic or the one that handles the correct extension ? I would prefer the plug-in with the correct file magic. Maybe the file magic of the faxg3 plug-in is too weak ? If I understood the patch correctly, only the extensions of magicless file-formats would be probed before the magic header is used. That would mean you couldn't easily load a fax g3 files named foo.tga anymore, but if it is named foo.gif Gimp would still use the fax g3 loader. On the other hand it would allow you to actually load foo.tga if is is really a Targa file. The patch implements the following logic: (1) Check if the extension matches one of the file_formats we can't properly identify by their magic header. If not, proceed with (2). (2) Check if the header matches one of the magics. If not, proceed with (3). (3) Check if extension matches anything we know. I had the impression, this wasn't clear... OK, I should have read the e-mail with the patch more carefully. This handling looks good. Peter -- Peter Kirchgessner WWW:http://www.kirchgessner.net e-mail: [EMAIL PROTECTED]
Re: Magicless file formats
Hi, OK, I should have read the e-mail with the patch more carefully. This handling looks good. So the patch actually has a good chance to get included. The probability would be even better if you could upload it to ftp://ftp.gimp.org/incoming as described in the README in that directory. At the moment I don't have the time to test the patch, so either someone else applies it or it will be applied when we go through the patches on ftp.gimp.org. By uplocading it there you make sure, it is not forgotten. Salut, Sven
Re: Magicless file formats
(CC:ed to authors)
I went through the file plugins and added magic patterns to those who didn't
register any, and corrected those already exisiting. The only case where I'm
not 100% certain is the MPEG magic number; the ones chosen are from my
/etc/magic file, and all mpegs I've looked at had either of them.
This patch, together with the earlier TGA-and-magicless-load patch, have
been uploaded to ftp.gimp.org as gimp-mattias-000227-0.patch.
--- gimp-1.1.17/plug-ins/common/CEL.c.orig Sat Feb 26 22:43:27 2000
+++ gimp-1.1.17/plug-ins/common/CEL.c Sat Feb 26 22:43:53 2000
@@ -132,7 +132,7 @@
gimp_register_magic_load_handler ("file_cel_load",
"cel",
"",
- "0,string,KiSS\040");
+ "0,string,KiSS\\040");
gimp_register_save_handler ("file_cel_save",
"cel",
"");
--- gimp-1.1.17/plug-ins/common/bz2.c.orig Sat Feb 26 21:15:06 2000
+++ gimp-1.1.17/plug-ins/common/bz2.c Sat Feb 26 21:17:20 2000
@@ -132,9 +132,10 @@
nsave_args, 0,
save_args, NULL);
- gimp_register_load_handler ("file_bz2_load",
- "xcf.bz2,bz2,xcfbz2",
- "");
+ gimp_register_magic_load_handler ("file_bz2_load",
+ "xcf.bz2,bz2,xcfbz2",
+ "",
+ "0,string,BZh");
gimp_register_save_handler ("file_bz2_save",
"xcf.bz2,bz2,xcfbz2",
"");
--- gimp-1.1.17/plug-ins/common/gicon.c.origSat Feb 26 22:28:50 2000
+++ gimp-1.1.17/plug-ins/common/gicon.c Sat Feb 26 22:46:23 2000
@@ -146,9 +146,11 @@
nsave_args, 0,
save_args, NULL);
- gimp_register_load_handler ("file_gicon_load",
- "ico",
- "");
+ gimp_register_magic_load_handler ("file_gicon_load",
+ "ico",
+ "",
+ "0,string,"
+ "/*\\040\\040GIMP\\040icon\\040image");
gimp_register_save_handler ("file_gicon_save",
"ico",
"");
--- gimp-1.1.17/plug-ins/common/mpeg.c.orig Sat Feb 26 21:07:10 2000
+++ gimp-1.1.17/plug-ins/common/mpeg.c Sat Feb 26 21:14:44 2000
@@ -133,9 +133,10 @@
nload_args, nload_return_vals,
load_args, load_return_vals);
- gimp_register_load_handler ("file_mpeg_load",
- "mpg,mpeg",
- "");
+ gimp_register_magic_load_handler ("file_mpeg_load",
+ "mpg,mpeg",
+ ""
+ "0,long,0x01b3,0,long,0x01ba");
}
static void
--- gimp-1.1.17/plug-ins/common/psd.c.orig Sat Feb 26 21:29:26 2000
+++ gimp-1.1.17/plug-ins/common/psd.c Sat Feb 26 21:37:51 2000
@@ -402,7 +402,8 @@
nload_args, nload_return_vals,
load_args, load_return_vals);
- gimp_register_load_handler ("file_psd_load", "psd", "");
+ gimp_register_magic_load_handler ("file_psd_load", "psd", "",
+ "0,string,8BPS");
}
--- gimp-1.1.17/plug-ins/common/psp.c.orig Sat Feb 26 22:50:38 2000
+++ gimp-1.1.17/plug-ins/common/psp.c Sat Feb 26 22:51:06 2000
@@ -398,7 +398,7 @@
gimp_register_magic_load_handler ("file_psp_load",
"psp,tub",
"",
- "0,string,Paint Shop Pro Image File\n\032");
+
+"0,string,Paint\\040Shop\\040Pro\\040Image\\040File\n\032");
/* Removed until Saving is implemented -- [EMAIL PROTECTED]
gimp_register_save_handler ("file_psp_save",
"psp,tub",
--- gimp-1.1.17/plug-ins/common/xpm.c.orig Sat Feb 26 22:51:25 2000
+++ gimp-1.1.17/plug-ins/common/xpm.c Sat Feb 26 22:51:32 2000
@@ -180,7 +180,7 @@
gimp_register_magic_load_handler ("file_xpm_load",
"xpm",
"Load/Xpm",
- "0, string, /* XPM */");
+ "0, string,/*\\040XPM\\040*/");
gimp_register_save_handler ("file_xpm_save",
"xpm",
"Save/Xpm");
--- gimp-1.1.17/plug-ins/common/xwd.c.orig Sun Feb 27 17:32:13 2000
+++ gimp-1.1.17/plug-ins/common/xwd.c Sun Feb 27 18:36:29 2000
@@ -1,7 +1,7 @@
/* The GIMP -- an image manipulation program
*
Re: Magicless file formats
Mattias Engdegård wrote: Anyway, if the user finds that an application doesn't try to load a file whose name ends in .tga as a Targa file (or worse, attempts to load it as a Group 3 fax file), then the same user will assume that the application, or its programmers, or both, are stupid beyond belief. And rightly so :-) I would prefer a program that loads a group3 Fax file even if it is named .tga I cannot believe that such a situation would be more common than attempting to load a properly named Targa file. You can always set the format manually, but the automatic mechanism should be optimized for the common case. If a properly named Targa file is not correctly loaded by GIMP, then another plug-in (for example faxg3) uses a file magic that fits this targa file. So which plug-in should load the file ? The one that has the correct file magic or the one that handles the correct extension ? I would prefer the plug-in with the correct file magic. Maybe the file magic of the faxg3 plug-in is too weak ? -- Peter Kirchgessner WWW:http://www.kirchgessner.net e-mail: [EMAIL PROTECTED]
Re: Magicless file formats
Hi, If a properly named Targa file is not correctly loaded by GIMP, then another plug-in (for example faxg3) uses a file magic that fits this targa file. So which plug-in should load the file ? The one that has the correct file magic or the one that handles the correct extension ? I would prefer the plug-in with the correct file magic. Maybe the file magic of the faxg3 plug-in is too weak ? If I understood the patch correctly, only the extensions of magicless file-formats would be probed before the magic header is used. That would mean you couldn't easily load a fax g3 files named foo.tga anymore, but if it is named foo.gif Gimp would still use the fax g3 loader. On the other hand it would allow you to actually load foo.tga if is is really a Targa file. The patch implements the following logic: (1) Check if the extension matches one of the file_formats we can't properly identify by their magic header. If not, proceed with (2). (2) Check if the header matches one of the magics. If not, proceed with (3). (3) Check if extension matches anything we know. I had the impression, this wasn't clear... The only problem I see with this patch are badly written file_plug_ins that don't provide a magic header but a bunch of extensions since the patch would significantly enhance the possibility that the wrong loader is used. Salut, Sven
Re: Magicless file formats
[ correct description of the patch ]
The only problem I see with this patch are badly written file_plug_ins
that don't provide a magic header but a bunch of extensions since the
patch would significantly enhance the possibility that the wrong loader
is used.
Grepping for gimp_register_load_handler, I get the following matches besides
tga:
mpeg.c: gimp_register_load_handler ("file_mpeg_load", "mpg,mpeg", "");
bz2.c: gimp_register_load_handler ("file_bz2_load", "xcf.bz2,bz2,xcfbz2", "");
gicon.c: gimp_register_load_handler ("file_gicon_load", "ico", "");
pix.c: gimp_register_load_handler ("file_pix_load", "pix,matte,mask,alpha,als",
"");
psd.c: gimp_register_load_handler ("file_psd_load", "psd", "");
url.c: gimp_register_load_handler ("file_url_load", "", "http:,ftp:");
xbm.c: gimp_register_load_handler ("file_xbm_load", "xbm,icon,bitmap", "");
Of these, mpeg, bz2, gicon, and psd have perfectly good magic numbers,
so fixing these are easy. I'll whip up a patch that does this.
The Alias/Wavefront PIX format has no good magic header. The extensions
pix,matte,mask,alpha,als are registred, which is a bit too much. Most of
these are too generic to be of any use; I'd say keep the ".pix" and drop the
rest.
url is a prefix "format" and not really a problem.
xbm is almost identifiable (you could try matching "/*" not followed by " XPM",
or "#define"), but I don't know if the pattern language allows it.
Re: Magicless file formats
Mattias Engdegård wrote: Anyway, if the user finds that an application doesn't try to load a file whose name ends in .tga as a Targa file (or worse, attempts to load it as a Group 3 fax file), then the same user will assume that the application, or its programmers, or both, are stupid beyond belief. And rightly so :-) I would prefer a program that loads a group3 Fax file even if it is named .tga --Peter -- Peter Kirchgessner WWW:http://www.kirchgessner.net e-mail: [EMAIL PROTECTED]
Re: Magicless file formats
Anyway, if the user finds that an application doesn't try to load a file whose name ends in .tga as a Targa file (or worse, attempts to load it as a Group 3 fax file), then the same user will assume that the application, or its programmers, or both, are stupid beyond belief. And rightly so :-) I would prefer a program that loads a group3 Fax file even if it is named .tga I cannot believe that such a situation would be more common than attempting to load a properly named Targa file. You can always set the format manually, but the automatic mechanism should be optimized for the common case.
Re: Magicless file formats
Targa files have no magic header, and cannot be reliably identified that way. [snip] "New" Targa files have a magic string at the end of the file[1], plus a bunch of extra information. The Targa specification tells you how and where to expect it. It does says that for old files you are basically screwed :-( Federico [1] Yes, this is broken.
Re: Magicless file formats
"New" Targa files have a magic string at the end of the file[1], plus a bunch of extra information. The Targa specification tells you how and where to expect it. It does says that for old files you are basically screwed :-( I know that, but since a) the Gimp magic pattern language doesn't seem to allow matching a string at the end of a file, and b) many (most!) TGA files today follow the old specification, it is of no help. Anyway, if the user finds that an application doesn't try to load a file whose name ends in .tga as a Targa file (or worse, attempts to load it as a Group 3 fax file), then the same user will assume that the application, or its programmers, or both, are stupid beyond belief. And rightly so :-) (Was it OK to post a patch to this list, or should I have sent it somewhere else? To some CVS repository? Please forgive my cluelessness.)
Magicless file formats
Targa files have no magic header, and cannot be reliably identified that way.
The TGA plugin tried to register some nonsense magic string which didn't work
anyway, and any attempt to load a TGA file without explicitly selecting the
load format will usually cause gimp to handle it as a group 3 fax or
something. (A correct TGA magic pattern *could* be constructed, but it would
be so generic that it would match a lot of other files as well.)
A reasonable solution is to match the file suffix against all formats that
do not have a magic pattern first, before any attempt to determine the file
type by the header.
I'm a newcomer to gimp development so I didn't know where to send the patch,
but it is short so I included it here.
--- gimp-1.1.17/plug-ins/common/tga.c.orig Wed Feb 23 01:19:04 2000
+++ gimp-1.1.17/plug-ins/common/tga.c Wed Feb 23 03:44:05 2000
@@ -252,10 +252,10 @@
nsave_args, 0,
save_args, NULL);
- gimp_register_magic_load_handler ("file_tga_load",
- "tga",
- "",
- "0,byte,10,2,byte,1,3,byte,0,3,byte,9");
+ gimp_register_load_handler ("file_tga_load",
+ "tga",
+ "");
+
gimp_register_save_handler ("file_tga_save",
"tga",
"");
--- gimp-1.1.17/app/fileops.c.orig Wed Feb 23 01:21:27 2000
+++ gimp-1.1.17/app/fileops.c Wed Feb 23 01:42:04 2000
@@ -1754,16 +1754,64 @@
gtk_widget_set_sensitive (GTK_WIDGET (filesave), TRUE);
}
+static PlugInProcDef *
+file_proc_find_by_name(GSList *procs,
+ gchar *filename,
+ gboolean skip_magic)
+{
+ GSList *p;
+ gchar *ext = strrchr(filename, '.');
+ if(ext)
+ext++;
+
+ for(p = procs; p; p = p-next)
+{
+ PlugInProcDef *proc = p-data;
+ GSList *prefixes;
+
+ if(skip_magic proc-magics_list)
+ continue;
+ for(prefixes = proc-prefixes_list; prefixes; prefixes = prefixes-next)
+ {
+ if(strncmp(filename, prefixes-data, strlen(prefixes-data)) == 0)
+ return proc;
+ }
+ }
+
+ for(p = procs; p; p = p-next)
+{
+ PlugInProcDef *proc = p-data;
+ GSList *extensions;
+
+ for(extensions = proc-extensions_list; ext extensions;
+ extensions = extensions-next)
+ {
+ gchar *p1 = ext;
+ gchar *p2 = (gchar *)extensions-data;
+
+ if(skip_magic proc-magics_list)
+ continue;
+ while (*p1 *p2)
+ {
+ if (tolower (*p1) != tolower (*p2))
+ break;
+ p1++;
+ p2++;
+ }
+ if (!(*p1) !(*p2))
+ return proc;
+ }
+}
+
+ return NULL;
+}
+
PlugInProcDef *
file_proc_find (GSList *procs,
gchar *filename)
{
PlugInProcDef *file_proc, *size_matched_proc;
GSList *all_procs = procs;
- GSList *extensions;
- GSList *prefixes;
- gchar *extension;
- gchar *p1, *p2;
FILE *ifp = NULL;
gint head_size = -2, size_match_count = 0;
gint match_val;
@@ -1771,11 +1819,11 @@
size_matched_proc = NULL;
- extension = strrchr (filename, '.');
- if (extension)
-extension += 1;
+ /* First, check magicless prefixes/suffixes */
+ if( (file_proc = file_proc_find_by_name(all_procs, filename, TRUE)) != NULL)
+return file_proc;
- /* At first look for magics */
+ /* Then look for magics */
while (procs)
{
file_proc = procs-data;
@@ -1810,46 +1858,8 @@
if (size_match_count == 1)
return (size_matched_proc);
- procs = all_procs;
- while (procs)
-{
- file_proc = procs-data;
- procs = procs-next;
-
- for (prefixes = file_proc-prefixes_list; prefixes; prefixes = prefixes-next)
- {
- p1 = filename;
- p2 = (gchar *) prefixes-data;
-
- if (strncmp (filename, prefixes-data, strlen (prefixes-data)) == 0)
- return file_proc;
- }
- }
-
- procs = all_procs;
- while (procs)
-{
- file_proc = procs-data;
- procs = procs-next;
-
- for (extensions = file_proc-extensions_list; extension extensions;
extensions = extensions-next)
- {
- p1 = extension;
- p2 = (gchar *) extensions-data;
-
- while (*p1 *p2)
- {
- if (tolower (*p1) != tolower (*p2))
- break;
- p1 += 1;
- p2 += 1;
- }
- if (!(*p1) !(*p2))
- return file_proc;
- }
-}
-
- return NULL;
+ /* As a last ditch, try matching by name */
+ return file_proc_find_by_name(all_procs, filename, FALSE);
}
static void
file formats
ImageMagick has import / export filters for fpx (only import), pbm, pict and ttf. I think we should include this fileformats also for GIMP
Re: file formats
On Wed, Feb 02, 2000 at 10:58:12AM -0800, Martin Weber [EMAIL PROTECTED] wrote: ImageMagick has import / export filters for fpx (only import), pbm, pict and ttf. I think we should include this fileformats also for GIMP Patches welcome. There is a nice project on sourceforge where you can get support for new plug-in. How will an exported ttf image look like, btw? And whats wrong with existing pbm support? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
