Re: [Gimp-developer] EXIF information in JPEG files
Having pissed everyone off at this stage with what must seem like either cluelessness or intransigence (let me assure ye that neither impression was intended), I'm going to let the thread (and the debate) die finally... I have been looking at this in a slightly different way to the way that I probably should have, and therefore I have seen issues that aren't really there. I could explain the way I was looking at stuff, or the motivation for my readjustment, but it wouldn't help. Suffice it to say that I have come to realise where the rest of you are coming from, and that you are right. So, to sum up... Raphael said: There are several reasons for using individual parasites for each part of the EXIF data instead of using a single parasite including the whole structure: I (finally) agree. Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 06 Feb 2002, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Wed, Feb 06, 2002 at 02:17:21PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: EXIF data and simply copy the descriptions given in the EXIF standard. Some of the fields will have to be discarded (or set read-only or not persistent) because they only make sense for the original file format It might hurt, but I think the best thing is to not attach these values at all, as there is no semantics attached to them until the core recognizes and modifies them properly on edits (at least for most values). A large part of the EXIF data can be useful for other plug-ins, so it would use the gimp-* namespace for the parasites the semantics of each parasite would be known. Other parts of the EXIF data are less interesting, usually because they describe some properties of the file format that would be changed when the image is saved into a new file (for example, RowsPerStrip, SamplesPerPixel, JPEGInterchangeFormatLength). I think that we should use non-persistent parasites for these parts. The data would not be saved in a new file (unless it is reconstructed by the JPEG/EXIF plug-in) but it would be available after the image has been loaded. Even if the core does not make use of this information, it could still be displayed to the user by a File-Properties plug-in. The dialog window created by this plug-in could provide several tabs that are specific to some file formats. There would be at least one or two tabs for the EXIF data, even for the non-persistent parts. I think that it would be very interesting for the user to know a bit more about the properties of the original file, even if these properties are lost after the conversion to a flat RGB bitmap. Even tools such as ImageMagick's identify do not always provide the information that I am looking for, although I know that it is loaded and parsed by the application. The biggest problem is the format inside parasites - i personally dislike gserialize (unused anyway), and strongly favour very simple decomposing, i.e. scalars (single-valued string-thingy) where possible. So the more parasites the better ;) I fully agree. All pieces of metadata can be decomposed to strings or single numbers. Blocks of raw data should also be allowed for special cases such as ICC color profiles, but only if these blocks are following a well-specified format (including endianness and other things that could cause problems on different platforms). As Sven has already suggested, all text strings should use UTF-8 encoding. It would be up to each plug-in to convert whatever is appropriate for each file format to/from UTF-8 if necessary. Currently, even the usage of gimp-comment causes some problems because some file formats (such as PNG) require ISO-8859-1 (Latin-1) for the character set, some say that the comment should be encoded in the user's current character set (how do you exchange files with others, then?), some others require 7-bit ASCII and most of them do not specify anything. These strings should not have any constraints regarding their length or format (single line or multiple lines of text). It should be up to each plug-in to do the appropriate conversions if necessary. On Wed, 06 Feb 2002, Sven Neumann [EMAIL PROTECTED] wrote: And the most natural place for this is parasites, [...] exactly. If there's a need to improve the current parasites, let's do that now. I could imagine that a more hierachical structure might help, but I'd like to see a real usage case before we consider doing such a change. Is the EXIF data such a usage case? No, all parts of the EXIF data can be stored in a flat list without losing any information. There are some sub-structures such as the GPSInfo, but that can easily be flattened as long as all parasites start with the same prefix (gimp-gps-latitude, gimp-gps-longitude, gimp-gps-img-direction and so on). I had a look at some other file formats that can contain significant amounts of metadata (PNG, TIFF, TGA) and I did not see anything that would require more hierarchical structures. This is not completely true because TIFF can be arbitrarily complex, but we will probably never try to cover all sub-formats of the TIFF standard. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On , 7 Feb 2002, Sven Neumann wrote: exactly. If there's a need to improve the current parasites, let's do that now. I could imagine that a more hierachical structure might help, but I'd like to see a real usage case before we consider doing such a change. Is the EXIF data such a usage case? Uh - it already *is* hierarchical: that's exactly what: gimp-* gimp-exif-* etc are! It's hierarchical by convention, and this isn't checked, sure. But it's quick and easy. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Thu, Feb 07, 2002 at 04:09:01PM +0100, Dave Neary [EMAIL PROTECTED] wrote: This is untrue (or at least, true only by convention). There's a solid argument (your mail is horribly mis-formatted and very hard to read, btw) that all metadata is plug-in independant, and therefore belongs in the gimp- Why is metadata plug-in independent? group. But there's nothing that forces people to honour any parasite naming Yes there is, it's called rules and conventions. The gimp is not about bondage and discipline. convention. I could write a plug-in that creates a parasite with a name not starting with gimp- and uise it in the core, or with the name gimp- and use it only in one plug-in. You could. You could also send the gimp process a kill signal at anytime. That doesn't make it correct, or right to do. one or 50 doesn't really matter, as long as it's documented. That's the major part of the problem. If someone adds metadata that's not documented, that's a problem. Yes. It's a problem because there's no one place that someone can go and say that they have the definitivelist of parasites. Sure, the documentation. That's fine if there are only a few, but if there are many, tracking them becomes a chore. And more it leads to the possibility of inconsistency. Another abstraction layer, of course, doesn't help getting rid of inconsistency. Yes, it does. We would have one parasite, named something original like gimp-image-metadata, and in one header file somewhere we would have the definition of the gimp-image-metadata structure, and the prototypes of the parsing functions.If someone added an extra bit of metadata and forgot to document it in the docs, well it's there in the code in the one place where all the fields supported in the metadata are - one place, definitive. So what does this buy us, apart from anothe rlevel of indiraction, to the current approach which also does all this? The parasites provide a namespace for this. Inventing yet-another-metadata-in-metadata-abstraction doesn't buy clarity. Perhaps not, but it buys consistency. You repeat this again and again. But people fail to see this. That's fine, when the documentation is accurate - if it lags behind anyone who thinks it doesn't is living in a dreaml world) it becomes best redundant and at worst misleading. Adding yet another place where this has to be documented does not, in my eyes, improve the situation. No, because the PNG developer has the definitive list of parasitres in the image metadata definition. If he's adding a new bit of metadata he's adding it there. And in that case, the duplication should be obvious. the definitive list and adding new bit of metadata contradict each other, at least in my mind. If someone could convince me that there were a way to get a list of all the parasites in use in the gimp (core and plug-ins) using the current structure of things, then I'd probably go along. I just have this use grep ;) vision of having a gimp-image-metadata-author in one plug-in, and gimp-metadata-author in another, and gimp-image-author in another, If you mean that this should not happen, I agree. But how would the other approach help this? One author could add a author field and another an image-author field to the structure. Again, another level of abstraction doesn't help at all. Either one avoids these bugs, or not. and so on. Possibly not for something as obvious as that, but you get my point. Yes, but instead you should gice points on why another metadata layer would solve the existing problems. IMnsHO doing the same thing in a slightly different way only increases the places where problems occur. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Thu, Feb 07, 2002 at 02:45:03PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: not be saved in a new file (unless it is reconstructed by the JPEG/EXIF plug-in) but it would be available after the image has been loaded. If it is valid after the image is modified, yes. Otherwise I think it should not be attached at all. appropriate for each file format to/from UTF-8 if necessary. Oh yes, oh yes! ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Thu, 7 Feb 2002, Dave Neary wrote: Marc Lehmann wrote: There is no such thing as non-standard naming in this case. exif doesn't provide a standard name, so you need to make one up. Wether oyu make up one or 50 doesn't really matter, as long as it's documented. That's the major part of the problem. If someone adds metadata that's not documented, that's a problem. It's a problem because there's no one place that someone can go and say that they have the definitive list of parasites. That's fine if there are only a few, but if there are many, tracking them becomes a chore. And more it leads to the possibility of inconsistency. [snip] I think it's much easier to just look at the documentation rather than to run through header files until I can find what I need, hopefully with a sparse one-line comment, even. That's fine, when the documentation is accurate - if it lags behind (and anyone who thinks it doesn't is living in a dreaml world) it becomes at best redundant and at worst misleading. parasites were created for metadata. If they don't work well enough for that parasites should be improved, rather than becoming a legacy layer. To handle something like what we're talking about, you'd need something paralleling the PDB - a parasite database. And that seems to me like overkill. While I think that the problems with inconsistancy are overrated -- mitch and sven seem to review every cvs commit and wouldn't reluctant to revert a commit that adds a parasite without adding it to devel-docs/parasites.txt -- I also don't see why adding a PDB-style self-documenting parasite registry would be bad either. The advantage would be that there would be one place to read about all the parasites, even those that are not included with the GIMP. Before a plug-in could attach a parasite, the parasite would have to be registered. The registration function would take three parameters: the name of the parasite, a blurb about what it does, and the format that the parasite is stored in. (UTF-8, 7-bit ASCII, string representation of a float, etc.) Perhaps even a custom format could be provided that calls a custom verification function. Since more than one plug-in might use a parasite, but all of them have to register the parasite, it's possible that the information registered can conflict. It seems best to make the second registration function fail should the formats be different, but if the blurb is different, it is probably best to silently ignore it. What do you think? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Tue, 5 Feb 2002, Dave Neary wrote: Raphael wrote: There are several reasons for using individual parasites for each part of the EXIF data instead of using a single parasite including the whole structure: [snipped points] Your points all have merit. My problem is now, and has always been, that a parasite per piece of data would mean adding an extra 50 or 60 parasites which would be relatively persistent. That makes things pretty complicated, to my mind. What's the problem with having 50 or 60 parasites attached to an image? The parasites are very small and they are what the GIMP uses to store any kind of metadata about an image. Each of these parts can easily be accessed or modified by using its name. The GIMP parses the list of parasites for you, so you only have to write a few of lines of code to get the current value of gimp-comment (the comment attached to the image) or hot-spot (the position of the hot spot if you are editing a cursor) and modify it. Instead we could store the whole metadata in a nice format (say as xml?) as one parasite, and have it parsed in one place. Then people who want to use bits of the metadata would just use the bits they wanted, and ignore the bits they didn't I do not understand what we would gain by using an XML format to store a list of name-value pairs if the GIMP is already providing a mechanism for doing that: the parasites. This would only add an extra parsing step that is not necessary. It is better to be able to access any part of the data directly by using its name. Using a format such as XML could be useful if many plug-ins had to attach complex data structures such as trees or nested lists to the image (and if these data structures would be used by more than one plug-in) but I do not see any need for that. The EXIF data block itself is a list of name-value pairs so the GIMP parasites are perfectly suitable for that. I think one structure, defined in one place, makes the handling of metadata cleaner. Maybe I am sounding like a broken record, but there is already a structure that is designed for handling metadata: this is the list of parasites. This is precisely why the parasites were added to the GIMP: storage of metadata, and easy access by name. The only thing that is missing is a standard list of names and types for all parasites. Here is a partial list of the names that I could find in the last stable release of the GIMP: - gimp-comment (string) image comment - hot-spot (string) hot spot position, given as two numbers in ASCII - icc-profile (raw) ICC color profile used in TIFF images - gimp-brush-pipe-parameters (raw) GIMP-specific data for brushes In addition, several plug-ins define their own parasites (such as jpeg-save-options or ifscompose-parasite) that are only useful for themselves and does not need to be understood by other plug-ins. It would be trivial to map the names of the all EXIF fields to individual parasites. I will try to post a list before the end of the week, and maybe that could be used as a starting point for a standard list of GIMP parasites. I will also have a look at how much effort would be needed in order to have the types checked by the GIMP core. The parasites are just untyped blocks of data, so a plug-in could certainly copy everything, modify a part of the data and then re-attach the updated parasite to the image. But again this would assume that all file plug-ins that want to use (a part of) the metadata are able to parse the EXIF block. I would prefer to avoid this requirement. And herein lies the crux - one object which is parsed by any object that wants to use bits of it, or multiple objects which are the bits. I think the cleanliness of having everything in one place is appealing. Well, that depends on your point of view: as I see it, the one place is the list of parasites. Several plug-ins are already using this one place and the access functions provided by the PDB to get or change some elements from this list. I still do not see any advantage in using only one element from this list to store another list (or another type of data structure, although I do not expect that we need anything more complex than a list to be used by more than one plug-in). -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 06 Feb 2002, Adam D. Moss wrote:
Raphael Quinet wrote:
The only thing that is missing is a standard list of names and types
for all parasites.
{docs|devel-docs}/parasites.txt
Err... Right. I knew that the file existed (I took a look at it the
last time we discussed the parasites) but I had forgotten its
location. It is indeed included in the GIMP tarball, in the
devel-docs directory.
But it needs to be extended with all the names of the EXIF parasites.
So I will try to do that this week. Basically, I think that it would
be enough to use the name gimp-blah for each blah field of the
EXIF data and simply copy the descriptions given in the EXIF standard.
Some of the fields will have to be discarded (or set read-only or not
persistent) because they only make sense for the original file format
and are irrelevant once the image is converted to an RGB bitmap. I
will probably start with the list given in:
http://pmt.sourceforge.net/exif/drafts/d020.html
-Raphael
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Raphael Quinet wrote: But it needs to be extended with all the names of the EXIF parasites. So I will try to do that this week. Basically, I think that it would be enough to use the name gimp-blah for each blah field of the EXIF data and simply copy the descriptions given in the EXIF standard. Fair enough, though if a parasite is going in the general-purpose gimp-* namespace care should probably be taken not to impose constraints specific to the EXIF form of that metadata upon a more general-purpose gimp-wide version. Some of the fields will have to be discarded (or set read-only or not persistent) because they only make sense for the original file format and are irrelevant once the image is converted to an RGB bitmap. Also fair enough, though I'd consider prefixing these with exif- or similar to avoid polluting gimp-* forever. FWIW I'm in favour of splitting out individual general-purpose parasites rather than a monolithic EXIF parasite. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 06 Feb 2002, Dave Neary wrote: Parasite naming is non-standard. Anyone can create a parasite with any name they want. [...] Where *is* the list of parasites? There are only (as you point out) about 10 persistent parasites, and the list isn't maintained anywhere. One possible approach to the metadata thing (I won't call it a problem yet) is to maintain a list of all the parasites which are used along with a description, and any time someone adds a parasite, they add it (with a description) to the list. devel-docs/parasites.txt is something approaching that. But that makes maintenance pretty difficult, compared to having the code document itself (one metadata structure with typed fields, and a couple of parsing routines). OK, so now the problem is clear: we need a way to enforce some consistency for the names of the parasites in the standard namespace (gimp-*). The plug-ins should be allowed to do anything they want with the parasites in their own namespace (e.g., jpeg-save-options or tiff-save-options) and nobody has to worry about these. The only thing that should be checked is the usage of the gimp-* names, which should have a pre-defined name and type. Maybe we could also define the exif-* namespace as common, although it could also be gimp-exif-*. Any plug-in that attempts to set or get a gimp-* parasite that has not been defined in some central place should cause the core to generate some kind of warning. So, what about this solution: I convert the existing list of common parasites (only the gimp-* parasites in devel-docs/parasites.txt) to a list of strings that can be put in a *.c or *.h file. I also add the EXIF data to this list. Then if the GIMP is compiled in debug mode, I would add some code in the PDB functions for accessing the parasites. This code would trigger a g_warning if the name of a gimp-* parasite cannot be found in the pre-compiled list. The code could also check the type of the parasite automatically, but this would imply an API change for all PDB functions dealing with parasites and that would also require an upgrade of the XCF format. So this would break a lot of things, but maybe it is better to do it as early as possible. Any opinions on this? Note that the *.c or *.h file containing the list of common parasites in the gimp-* namespace could be generated at build time from an XML file. That file could also hold the human-readable documentation of these parasites and it could be used to generate a text file or HTML file documenting the common parasites. I don't see the parasite handler as one place. As a scenario - say that the TIFF plug-in wants to set some metadata information (but not all of it) for a certain image, and later we are saving as PNG, and we want to set some more metadata with the image, wouldn't you consider the two plug-ins as two places? If I add a parasite to the metadata in the TIFF plug-in, the PNG developer knows nothing about it - if I as a lazy developer didn't add it to the list of supported metadata he wouldn't know it existed. And let's say I as the PNG developer want to use the same data, but I call it a slightly different name - now we have two parasites which do the same thing. Those kind of problems are eliminated by definition if all the metadata's defined in one place. The usage of non-standard parasites has not been a problem so far. All authors of plug-ins have correctly followed the guidelines described in devel-docs/parasites.txt. From that point of view, I do not think that it is really important to add a mechanism that checks if the gimp-* namespace is used correctly. But I think that it could be a nice addition, so I will see what I can do about it until next week. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Tue, 06 Feb 2002, Adam D. Moss wrote: Raphael Quinet wrote: But it needs to be extended with all the names of the EXIF parasites. So I will try to do that this week. Basically, I think that it would be enough to use the name gimp-blah for each blah field of the EXIF data and simply copy the descriptions given in the EXIF standard. Fair enough, though if a parasite is going in the general-purpose gimp-* namespace care should probably be taken not to impose constraints specific to the EXIF form of that metadata upon a more general-purpose gimp-wide version. OK, so this means that any EXIF data that could also be used by other plug-ins (such as Artist, Copyright, ImageDescription, ColorSpace and many others) should use the gimp-* namespace and the type checking should be relaxed if we can forsee other uses than what is described in the EXIF standard. If would then be up to the JPEG save plug-in to constrain this parasite to the acceptable range when it saves it as EXIF. Some of the fields will have to be discarded (or set read-only or not persistent) because they only make sense for the original file format and are irrelevant once the image is converted to an RGB bitmap. Also fair enough, though I'd consider prefixing these with exif- or similar to avoid polluting gimp-* forever. If I am still following you correctly, this means that all parts of the EXIF data that should not be persistent (such as SamplesPerPixel, JPEGTables, YCbCrCoefficients, Interlace, ExifOffset and others that are marked as drop in the PNG-EXIF proposal) would use a different namespace. These parasites would use the exif-* namespace and would be discarded when the file is saved (even if it is saved in another EXIF file, because that information must be re-constructed instead of being copied). On Tue, 06 Feb 2002, Lutz Müller wrote: On Wed, 2002-02-06 at 14:50, Raphael Quinet wrote: Maybe we could also define the exif-* namespace as common, although it could also be gimp-exif-*. It would be _really_ easy if you used the tag names for those parasites, i.e. gimp-exif-FillOrder or gimp-exif-SpectralSensitivity. Yes, that's what I was planning to do. Except that I would convert the MixedCaseNames to hyphen-separated-names in order to be consistent with other parts of the GIMP. So the parasites would be split in several categories: 1 - gimp-* for existing persistent parasites that are already shared by several plug-ins (e.g, gimp-comment although the definition of this one is much too vague, as a consequence of the different meaning that it can have in different image formats). 2 - gimp-exif-* for new persistent parasites derived from the EXIF specification and that could be used by other plug-ins such as TIFF or PNG. I will probably follow the list given in the PNG-EXIF proposal. 3 - exif-* for new non-persistent parasites derived from the EXIF specification. These ones might be displayed in the File Properties dialog if we ever have one, but they would never be saved again in a file and they would not be used by other plug-ins. The second category could be merged with the first one if we drop the -exif part of the name and put everything under gimp-*. I do not know what is better. Comments? Besides, that would save you a lot of writing, as you can just point to the EXIF reference for names. Sure, that was my goal. By the way, libexif-0.3 and libexif-gtk-0.2 is out. If you use that, you can even access the thumbnail embedded in the EXIF data using gimp-1.2.2 and my patches posted earlier. Again, just a proof of concept, but it works. Thanks. I will have a look at it as soon as possible. But as I wrote previously and as Dave agreed, it would probably make more sense to merge this code directly into the JPEG plug-in instead of requiring an additional library. Also, the GTK+ user interface should probably be converted to a separate plug-in to view and edit all file properties. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
http://www.ecs.soton.ac.uk/~njl98r/chocbox1.png http://www.ecs.soton.ac.uk/~njl98r/chocbox2.png A potential UI for a textual metadata editor using Dublin Core's element names (and of course internally it could use any parasite names that were deemed fit, but since parasite names are arbitrary text strings it might as well be DC.Creator, DC.Title etc.) EXIF's Artist is DC's Creator and PNG's Author (by convention) EXIF and PNG's Copyright is DC's Rights There are also a number of useful generic metadata structures in EXIF like the GPS data which could arguably be shared with other systems, and might therefore deserve a gimp-foo parasite name. One thing I can't seem to find out (maybe I'm looking in the wrong place) is whether EXIF data is supposed to follow derived works or not. Some contributors to this thread seemed to feel that it was important that a Gimp image must always preserve the EXIF data, but this would only make sense is EXIF is indeed a historical record of the source, and not live metadata. Can someone clear that up (preferably with a reference to an EXIF standards document or something) ? Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 2002-02-06 at 16:06, Raphael Quinet wrote: Thanks. I will have a look at it as soon as possible. But as I wrote previously and as Dave agreed, it would probably make more sense to merge this code directly into the JPEG plug-in instead of requiring an additional library. As this conflicts directly with my dislike to copy paste instead of using common libraries, I won't do that. See, libexif is needed by gphoto2, a command-line frontend to libgphoto2. And libexif-gtk is used by gtkam, a GTK frontend to libgphoto2. I hope that libexif will be used by other exif tools, especially command-line tools. I am not willing to keep several libexif versions together or to answer for incompabilities among those. Perhaps someone else... Also, the GTK+ user interface should probably be converted to a separate plug-in to view and edit all file properties. libexif-gtk is an EXIF editor. If someone wants to write a gimp-parasite editor, this is ok. But I'd still like to give users the possibility to access/edit all EXIF data, because a gimp-parasite editor will never be able to cover all EXIF tags. Just think of MakerNote the contents of which vary from manufacturer to manufacturer. Lutz -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] EXIF information in JPEG files
Nick Lamb wrote: One thing I can't seem to find out (maybe I'm looking in the wrong place) is whether EXIF data is supposed to follow derived works or not. Some contributors to this thread seemed to feel that it was important that a Gimp image must always preserve the EXIF data, but this would only make sense is EXIF is indeed a historical record of the source, and not live metadata. Can someone clear that up (preferably with a reference to an EXIF standards document or something) ? Presumably (and this is just me - I have nothing to support this) that depends on the data. For example, copyright would have to follow the normal rules of derived works (whatever they may be), as would author, but something like GPS (which relates directly to where the image was originally captured) could be copied through unchanged. Some data logically stays read-only, and some data should be modifiable (one example of each would, presumably, be flash energy and image history respectively). Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Raphael wrote: On Wed, 06 Feb 2002, Dave Neary wrote: Where *is* the list of parasites? There are only (as you point out) about 10 persistent parasites, and the list isn't maintained anywhere. OK, so now the problem is clear: we need a way to enforce some consistency for the names of the parasites in the standard namespace (gimp-*). Agreed (if we decide to go for multiple parasites, and it seems like I'm becoming outgunned). We should also work out whether what we've been talking about is exif, to the exclusion of other metadata, or generic metadata, which would include exif data as a subset. Maybe we could also define the exif-* namespace as common, although it could also be gimp-exif-*. Any plug-in that attempts to set or get a gimp-* parasite that has not been defined in some central place should cause the core to generate some kind of warning. If we go with the more generic metadata option, then we would have the option of gimp-metadata-*. But that's minutiae at the moment. So, what about this solution: I convert the existing list of common parasites (only the gimp-* parasites in devel-docs/parasites.txt) to a list of strings that can be put in a *.c or *.h file. I also add the EXIF data to this list. Then if the GIMP is compiled in debug mode, I would add some code in the PDB functions for accessing the parasites. This code would trigger a g_warning if the name of a gimp-* parasite cannot be found in the pre-compiled list. A parasite validator would certainly be a solution. The question would then be whether the overhead of validating every parasite request would outweigh the overhead of parsing one metadata object :-) The code could also check the type of the parasite automatically, but this would imply an API change for all PDB functions dealing with parasites and that would also require an upgrade of the XCF format. So this would break a lot of things, but maybe it is better to do it as early as possible. Any opinions on this? Well, XCF was due an upgrade, but backward compatibility is a concern... Note that the *.c or *.h file containing the list of common parasites in the gimp-* namespace could be generated at build time from an XML file. That file could also hold the human-readable documentation of these parasites and it could be used to generate a text file or HTML file documenting the common parasites. Sounds like a plan. The usage of non-standard parasites has not been a problem so far. All authors of plug-ins have correctly followed the guidelines described in devel-docs/parasites.txt. From that point of view, I do not think that it is really important to add a mechanism that checks if the gimp-* namespace is used correctly. But I think that it could be a nice addition, so I will see what I can do about it until next week. That's primarily because the use of parasites has been limited to a few - notably gimp-comment. Apart from 3/4 commonly used parasites it hasn't come up. If we're passing image metadata around a lot it'll certainly be more of a concern. But we're getting towards agreement. I'm still not convinced that that's the way to go, but I can see that it's certainly at least as workable as my suggestion :) Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 6 Feb 2002, Nick Lamb wrote: http://www.ecs.soton.ac.uk/~njl98r/chocbox2.png ^^^ Looks very nice, but please, please call the last field Copyright instead of Digital Rights Management. Rockwlrs ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 6 Feb 2002, Dave Neary wrote: If we go with the more generic metadata option, then we would have the option of gimp-metadata-*. But that's minutiae at the moment. Isn't the fact that it's a parasite metadata-y enough? I suppose it's possible to attach a parasite to an image for something other than metadata, but I doubt that anyone will ever do it. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, Feb 06, 2002 at 02:11:28PM +0100, Dave Neary [EMAIL PROTECTED] wrote: Parasite naming is non-standard. Anyone can create a parasite with any name they want. Untrue. Names beginning with gimp- are well-defined as belonging to the core. The gimp itself must, at one point, know how to deal with these. The core also is: the aim of having a metadata editor at some stage, 50 or 60 pieces of metadata with (possibly) non-standard naming is complicated. There is no such thing as non-standard naming in this case. exif doesn't provide a standard name, so you need to make one up. Wether oyu make up one or 50 doesn't really matter, as long as it's documented. parasites if we were guaranteed a consistent approach throughout the gimp, but parasites don't give that guarantee by definition almost. Why? What are the problems? The obvious way to maintain a consistency wrt the metadata is to define it in one place, maintain that list in one place, and have it parsed into a usable structure when needed. I think this is exatcly what parasites provide. You say that any piece of metadata can easily be accessed by name. The problem is going to be: What name? I think keeping stuff in one place offers consistency. Well, the everything-in-a-big-blob-approach doesn't help naming at all. At one point you simply have to make up names to access the exif information. The parasites provide a namespace for this. Inventing yet-another-metadata-in-metadata-abstraction doesn't buy clarity. (with a description) to the list. devel-docs/parasites.txt is something approaching that. But that makes maintenance pretty difficult, compared to having the code document itself (one metadata structure with typed fields, and a couple of parsing routines). I think it's much easier to just look at the documentation rather than to run through header files until I can find what I need, hopefully with a sparse one-line comment, even. parasites. Having one metadata structure provides that one place. But parasites _is_ one metadata structure. I don't see why nesting etadata structures inside each other is a good thing - to me it only complicates things. parasites were created for metadata. If they don't work well enough for that parasites should be improved, rather than becoming a legacy layer. the TIFF plug-in, the PNG developer knows nothing about it - if I as a lazy developer didn't add it to the list of supported metadata he wouldn't know it existed. And let's say I as the PNG developer want to use the same data, but I call it a slightly different name - now we have two parasites which do the same thing. Your approach suffers exactly the same problem, btw. Those kind of problems are eliminated by definition if all the metadata's defined in one place. And the most natural place for this is parasites, which exist only to hold metadata. If their definition isn't clear enough then this is the problem to solve. Adding yet another layer makes the situation worse, not better ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, Feb 06, 2002 at 03:41:17PM +0100, Lutz Müller [EMAIL PROTECTED] wrote: It would be _really_ easy if you used the tag names for those parasites, i.e. gimp-exif-FillOrder or gimp-exif-SpectralSensitivity. while i am not strictly opposed, these names are very ugly. more important, though, non-exif-specific metadata (like the above), would gain a lot by being in a common format. exif is not the only metadata format around and it would be nice to have the gimp metadata an abstraction. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: But parasites _is_ one metadata structure. I don't see why nesting etadata structures inside each other is a good thing - to me it only complicates things. parasites were created for metadata. If they don't work well enough for that parasites should be improved, rather than becoming a legacy layer. Ack. One change we definitely should make soon is to enforce UTF-8 encoding on all strings used in parasites (names and values if defined as strings). And the most natural place for this is parasites, which exist only to hold metadata. If their definition isn't clear enough then this is the problem to solve. Adding yet another layer makes the situation worse, not better exactly. If there's a need to improve the current parasites, let's do that now. I could imagine that a more hierachical structure might help, but I'd like to see a real usage case before we consider doing such a change. Is the EXIF data such a usage case? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Raphael Quinet wrote: The basic idea is that each file plug-in that supports metadata can convert the EXIF data (or other meta-data) to/from GIMP parasites. [snip] Note that it is important that each individual item in the EXIF data is converted to a separate GIMP parasite instead of importing the whole EXIF data in one big chunk because some parts of the EXIF data must be modified when the image is re-saved (also, some file formats do not support all fields so it is easier to work with them if they are saved in separare parasites). I'm not sure I agree with you here... I thought the matter was closed and that we were in agreement last December, but as I understand it there is no reason to have more than one parasite for exif data (or if you prefer a more generic metadata parasite which encompasses a superset of exif). My understanding, from what Sven and Mitch told me back then, was that a part of a parasite could quite easily be modified independant of the rest. So your concern about bits being modifiable does not imply (as you suggest) different parasites for different bits of data. At least that's how I understand it. I'm not sure whether the discussion was on- or off-list (I get mixed up sometimes), but that's what I took away from it. I just don't know how to handle the dependency on libexif(-gtk). You know, libexif itself is quite small and could be included in gimp (although I'd keep it separately), but libexif-gtk is getting bigger and bigger as more widgets are added. Therefore my question: Is it ok to introduce a (conditional --enable-exif) dependency on libexif(-gtk) for gimp? Well, I don't know what is the best thing to do. libexif should probably be integrated directly into the JPEG plug-in (and maybe adapted for the TIFF and PNG plug-ins) but I assume that large parts of it would have to be rewritten in order to use GIMP parasites as the storage format for all data. I agree here - just replace the bits that parse the jpeg header currently with the appropriate bits that parse the exif info and put it in a usable format/structure. There's no need to add a dependency on libexif, just add the code either to the existing jpeg.c, or in another file called something imaginative like exif.[ch], and link them together when making the jpeg plug-in. I would keep the gtk stuff (the interface) separate from the jpeg plug-in completely. As Raphael suggests, I would use it possibly as a basis for a generic parasite editor, or specifically as an image metadata editor. -Raphael Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Tue, 5 Feb 2002, Dave Neary wrote: Raphael Quinet wrote: [...] Note that it is important that each individual item in the EXIF data is converted to a separate GIMP parasite instead of importing the whole EXIF data in one big chunk because [...] I'm not sure I agree with you here... I thought the matter was closed and that we were in agreement last December, but as I understand it there is no reason to have more than one parasite for exif data (or if you prefer a more generic metadata parasite which encompasses a superset of exif). There are several reasons for using individual parasites for each part of the EXIF data instead of using a single parasite including the whole structure: * The metadata is likely to be useful for other plug-ins, even if they do not understand the full EXIF format. If the EXIF data is saved in one big chunk, then every file plug-in that wants to use a part of the information (for example, only the author name or only the date at which the original image was created) would have to be able to decode the EXIF format, deal with struct padding, byte-ordering problems, and so on. It should not be necessary to do all this in a plug-in if the only thing that it wants to do is to get a string or a timestamp from the metadata associated with the image. * The EXIF standard requires some fields (e.g., DateTime, Software) to be updated by any application that conforms to that standard. If a plug-in does not understand or does not need some of these fields, then it is better to drop them instead of copying them blindly. Using separate parasites makes the default behavior correct (because if a plug-in does not know how to handle a part of the EXIF data, it will not know its name either so it will not get it and copy it). * Instead of rephrasing them, I will simply quote three additional reasons directly from the proposal to include EXIF data in the PNG file format (http://pmt.sourceforge.net/exif/drafts/d020.html): - The data is potentially useful to human readers; this proposal allows them to view the information with existing PNG software. If it were kept in binary form, only special-purpose applications would be able to read it. Also, combining different data management methods (as in Exif format that embeds TIFF and JPEG encoded stuff), makes things unwieldy. - Data that is of no conceivable use after the image has been converted from the original format (JPEG tables, TIFF tiling layout, etc.) would be unnecessarily saved, wasting space. - The data would be at risk of being unnecessarily discarded by PNG editors. * The GIMP can use more metadata than what is defined in the EXIF standard. This could be done (and is already done) by using separate parasites for saving generic or GIMP-specific information. For consistency reasons, it would be better if all plug-ins would simply have to know the name and type of a parasite in order to be able to access its value, instead of having to go through an intermediate parsing step if the data is saved in the EXIF block. My understanding, from what Sven and Mitch told me back then, was that a part of a parasite could quite easily be modified independant of the rest. The parasites are just untyped blocks of data, so a plug-in could certainly copy everything, modify a part of the data and then re-attach the updated parasite to the image. But again this would assume that all file plug-ins that want to use (a part of) the metadata are able to parse the EXIF block. I would prefer to avoid this requirement. [snipped other comments for which we agree] -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Raphael wrote: On Tue, 5 Feb 2002, Dave Neary wrote: Raphael Quinet wrote: [...] Note that it is important that each individual item in the EXIF data is converted to a separate GIMP parasite instead of importing the whole EXIF data in one big chunk because [...] I'm not sure I agree with you here... I thought the matter was closed and that we were in agreement last December, but as I understand it there is no reason to have more than one parasite for exif data (or if you prefer a more generic metadata parasite which encompasses a superset of exif). There are several reasons for using individual parasites for each part of the EXIF data instead of using a single parasite including the whole structure: [snipped points] Your points all have merit. My problem is now, and has always been, that a parasite per piece of data would mean adding an extra 50 or 60 parasites which would be relatively persistent. That makes things pretty complicated, to my mind. Instead we could store the whole metadata in a nice format (say as xml?) as one parasite, and have it parsed in one place. Then people who want to use bits of the metadata would just use the bits they wanted, and ignore the bits they didn't (in terms of file formats this certainly doesn't contradict your concern about things being copied blindly - it amounts to the same thing as your opinion that those things should be ignored blindly). I think one structure, defined in one place, makes the handling of metadata cleaner. I'd equate it somewhat loosely to the move from a number of preferences to one preferences structure which we had a while back. I think your concerns about passing around data which will eventually be ignored, and incurring an overhead through parsing one big object into something meaningful, are real. I think they could probably be addressed easily. My understanding, from what Sven and Mitch told me back then, was that a part of a parasite could quite easily be modified independant of the rest. The parasites are just untyped blocks of data, so a plug-in could certainly copy everything, modify a part of the data and then re-attach the updated parasite to the image. But again this would assume that all file plug-ins that want to use (a part of) the metadata are able to parse the EXIF block. I would prefer to avoid this requirement. And herein lies the crux - one object which is parsed by any object that wants to use bits of it, or multiple objects which are the bits. I think the cleanliness of having everything in one place is appealing. I think it could make things less convoluted for places thgat use a lot of the data, and not too bad for places that only use a little. Maybe we'll never agree :) Then again, maybe someone else will offer an opinion, and one of us will realise how wrong we were? Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Tue, 2002-02-05 at 19:08, Raphael Quinet wrote:
Hi Lutz!
On Tue, 5 Feb 2002, Lutz Müller wrote:
PS: It would be nice if this mailing list program could automatically cc
replies to anyone sending mails to this list while not being subscribed
(like me).
Does this mean that you have not seen the two replies that I posted
yesterday, and the discussion today between Dave Neary and myself?
Just read it on the web. As I don't have gtk-1.3 and greater available
on my system, I won't be able to contribute anything right now.
In case you are interested in a proof of concept of the alternative 1
big EXIF parasite:
Attached are diffs against gimp-1.2.2:
- configure.in (adding an opt. dependency to libexif-gtk)
- acconfig.h (#undef HAVE_EXIF)
- plug-ins/common/Makefile.am (EXIF_LIBS, EXIF_CFLAGS)
- plug-ins/common/jpeg.c (some lines of code)
Apply them and you will be able to edit EXIF data when the JPEG format
chooser will pop up after selecting a filename. In addition, EXIF
information will not get lost if you open a JPEG file and save it again
as JPEG.
If you define how parts of the EXIF information should be stored in
individual parasites so that they are accessible to other plug-ins, I
can easily write an importer/exporter (EXIF data - GIMP format).
However, I think the user should still have the possibility to add/edit
EXIF tags that are not handled by those individual parasites.
Lutz
--
+--+ \|||/
| Lutz Müller+49 (7156) 34837 | (o o)
| +---ooO-(_)-Ooo---+
| Hans-Sachs-Strasse 5 |
| 71254 Ditzingenhttp://www.topfrose.de |
| Germany[EMAIL PROTECTED] |
++
--- configure.in.orig Tue Feb 5 23:19:52 2002
+++ configure.inTue Feb 5 23:24:56 2002
@@ -643,7 +643,38 @@ dnl fi
dnl AC_SUBST(PYGIMP_CFLAGS_NOUI)
dnl AC_SUBST(PYGIMP_LIBS_NOUI)
dnl AM_CONDITIONAL(BUILD_PYTHON, $build_python)
-
+
+dnl ---
+dnl libexif-gtk: JPEG files can contain EXIF data. If libexif-gtk is installed
+dnl on the system, gimp can use it to read this data from
+dnl JPEG files and save it (if the file is saved again in
+dnl the JPEG format). In addition, gimp can offer the user the
+dnl possibility to edit (!) EXIF data.
+dnl ---
+exif_msg=no (http://www.sourceforge.net/projects/libexif)
+try_exif=true
+AC_ARG_WITH(exif, [ --without-exif Don't use libexif],[
+ if test x$withval = xno; then
+ try_exif=false
+ fi])
+if $try_exif; then
+ AC_PATH_PROG(PKG_CONFIG,pkg-config)
+ if test -n ${PKG_CONFIG}; then
+ AC_MSG_CHECKING([for libexif-gtk])
+ if ${PKG_CONFIG} --exists libexif-gtk /dev/null 21; then
+ EXIF_CFLAGS=`$PKG_CONFIG --cflags libexif-gtk`
+ EXIF_LIBS=`$PKG_CONFIG --libs libexif-gtk`
+ exif_msg=yes
+ AC_DEFINE(HAVE_EXIF)
+ fi
+ AC_MSG_RESULT($exif_msg)
+ else
+ AC_WARN([Not searching for libexif - pkg-config not found.])
+ fi
+fi
+AC_SUBST(EXIF_CFLAGS)
+AC_SUBST(EXIF_LIBS)
+
GIMPINSTALL=
if test $INSTALL = $ac_install_sh; then
--- acconfig.h.orig Tue Feb 5 23:29:29 2002
+++ acconfig.h Tue Feb 5 23:08:46 2002
@@ -19,6 +19,7 @@
#undef HAVE_CATGETS
#undef HAVE_DIRENT_H
#undef HAVE_DOPRNT
+#undef HAVE_EXIF
#undef HAVE_FINITE
#undef HAVE_GETTEXT
#undef HAVE_IPC_H
--- Makefile.am.orig Tue Feb 5 23:30:17 2002
+++ Makefile.am Tue Feb 5 23:18:09 2002
@@ -15,6 +15,7 @@ INCLUDES = \
-I$(top_srcdir) \
-I$(top_srcdir)/intl \
$(GTK_CFLAGS) \
+ $(EXIF_CFLAGS) \
-I$(includedir)
libexec_PROGRAMS = \
@@ -722,6 +723,7 @@ jpeg_LDADD = \
$(top_builddir)/libgimp/libgimpui.la \
$(top_builddir)/libgimp/libgimp.la \
$(LIBJPEG)\
+ $(EXIF_LIBS)\
$(GTK_LIBS)\
$(INTLLIBS)
--- jpeg.c.orig Tue Feb 5 23:06:55 2002
+++ jpeg.c Tue Feb 5 23:08:13 2002
@@ -138,6 +138,10 @@
#include jpeglib.h
#include jerror.h
+#ifdef HAVE_EXIF
+#include libexif-gtk/gtk-exif-browser.h
+#endif
+
#include libgimp/gimp.h
#include libgimp/gimpui.h
@@ -273,6 +277,9 @@ static JpegSaveInterface jsint =
static gchar *image_comment = NULL;
static GtkWidget *restart_markers_scale = NULL;
static GtkWidget *restart_markers_label = NULL;
+#ifdef HAVE_EXIF
+static ExifData *exif_data = NULL;
+#endif
MAIN ()
@@ -424,6 +431,10 @@ run (gchar *name,
default:
break;
}
+#ifdef HAVE_EXIF
+ exif_data_unref (exif_data);
+ exif_data = NULL;
+#endif
g_free
Re: [Gimp-developer] EXIF information in JPEG files
On 4 Feb 2002, at 14:08, Lutz Müller wrote: I have written an EXIF library in plain C (libexif) and some GTK+ widgets for displaying and modifying EXIF data (libexif-gtk). Both are available on http://libexif.sourceforge.net. I use them to display EXIF tags in gphoto2 (command-line frontend) and gtkam (GTK+ GUI). However, when loading images from a digital camera directly into gimp and letting GIMP save the images (i.e. as JPEG files), all EXIF information gets lost. In addition, right now, gimp doesn't offer access to EXIF information when loading JPEG files. How do I go about adding EXIF support to gimp? Should I distribute a loader for JPEG files that replaces the current one? Submit a patch to gimp's JPEG loader and configure.in to --enable-exif if libexif(-gtk) is installed? Dave Neary and Raphael Quinet started work on EXIF for the GIMP. I suggest you contact them. Their discussion can be found here: http://lists.xcf.berkeley.edu/lists/gimp-developer/2001- December/006057.html In any case, how do I save per-image (not per-loader) EXIF data? I believe the idea is that meta-information gets stored in GIMP's parasites, and that the loaders/savers get adapted to do the conversion back and forth (IANAC). -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Hi Lutz, I have written an EXIF library in plain C (libexif) and some GTK+ widgets for displaying and modifying EXIF data (libexif-gtk). Both are available on http://libexif.sourceforge.net. I use them to display EXIF tags in gphoto2 (command-line frontend) and gtkam (GTK+ GUI). Thereare a couple of other libraries which do pretty much the same thing - see the relevant bug numbers in bugzilla (not sure what they are right now). I haven't had a chance to look closely at this, but it looks good. However, when loading images from a digital camera directly into gimp and letting GIMP save the images (i.e. as JPEG files), all EXIF information gets lost. In addition, right now, gimp doesn't offer access to EXIF information when loading JPEG files. Yup. We use a straight call to libjpeg's header parser, which doesn't know anything about exif. A couple of people (myself and Raphael Quinet) were looking at this with a view to adding support in 1.3 at least about a month and a half ago. Then I moved to France, and that got put on the back burner, and my computer's still in storage. The last I had done was a very simple hack which replaces our call to the header reader with a call which read exif information. The next step would have been to specify how that information would be passed over and back between the main gimp and the jpeg plug-in. There was some discussion on this, and it was agreed by everyone (eventually) that parasites were the way to go. So all we need to do is define what information would be available in the exif parasite, and how to get at it. I spent a bit of time at this writing up a short RFC, but it was pretty scattered, and never got finished/posted to the list. How do I go about adding EXIF support to gimp? Should I distribute a loader for JPEG files that replaces the current one? Submit a patch to gimp's JPEG loader and configure.in to --enable-exif if libexif(-gtk) is installed? If you write a wee report which says what exif information you get out of the file, and read up on parasites (which is about where I was at 6 weeks ago), post a mail to the list with reccommendations, and then code whatever comes out of the reccommendations. Until my computer comes out of storage (15th of February) I'll be useless to you, but there are otehrs who were interested in doing this too. There was a proposal before to have an exif data editor (or even a parasite editor) as well, but I reckon the first step is getting the exif stuff read into some well-defined structure, and getting it written out to files in the same proper structure without destroying it. If we can do that, a generic parasite editor can handle the editing of the metadata. In any case, how do I save per-image (not per-loader) EXIF data? I'm not sure what you mean by this... Lutz Hope this helps, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Mon, 2002-02-04 at 14:29, Dave Neary wrote: Thereare a couple of other libraries which do pretty much the same thing - see the relevant bug numbers in bugzilla (not sure what they are right now). I haven't had a chance to look closely at this, but it looks good. There is python stuff, a C++ library, lots of programs, but no plain C library. Plus, everything out there is designed for _extracting_ EXIF data, not _editing_ it. This is why I designed libexif(-gtk). Yup. We use a straight call to libjpeg's header parser, which doesn't know anything about exif. A couple of people (myself and Raphael Quinet) were looking at this with a view to adding support in 1.3 at least about a month and a half ago. So I am the third person looking at it :-) I just don't know how to handle the dependency on libexif(-gtk). You know, libexif itself is quite small and could be included in gimp (although I'd keep it separately), but libexif-gtk is getting bigger and bigger as more widgets are added. Therefore my question: Is it ok to introduce a (conditional --enable-exif) dependency on libexif(-gtk) for gimp? The last I had done was a very simple hack which replaces our call to the header reader with a call which read exif information. This is now a one-line call to libexif (exif_data_new_from_data()). The next step would have been to specify how that information would be passed over and back between the main gimp and the jpeg plug-in. There was some discussion on this, and it was agreed by everyone (eventually) that parasites were the way to go. Ok, I'll look into this. There was a proposal before to have an exif data editor This is libexif-gtk - just call gtk_exif_browser_new () and you've got the editor... (or even a parasite editor) as well, but I reckon the first step is getting the exif stuff read into some well-defined structure, Already there in libexif. and getting it written out to files in the same proper structure without destroying it. Not yet done. I'll try. Lutz -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] EXIF information in JPEG files
Hi, Lutz Müller [EMAIL PROTECTED] writes: So I am the third person looking at it :-) I just don't know how to handle the dependency on libexif(-gtk). You know, libexif itself is quite small and could be included in gimp (although I'd keep it separately), but libexif-gtk is getting bigger and bigger as more widgets are added. Therefore my question: Is it ok to introduce a (conditional --enable-exif) dependency on libexif(-gtk) for gimp? if it solves our problems and works for non-JPEG images too, I don't see any problem in adding such a dependency to gimp-1.3. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Mon, 04 Feb 2002, Lutz Müller wrote: On Mon, 2002-02-04 at 15:04, Sven Neumann wrote: if it solves our problems and works for non-JPEG images too, I don't see any problem in adding such a dependency to gimp-1.3. EXIF information is specific to JPEG files. Therefore, editing and storing EXIF information make sense with JPEG images only. Sure, you could try to save/hide/convert it in other image formats, but this is not the purpose of the EXIF specification. EXIF is specific to JPEG files, but you find almost the same information in the TIFF/EP format. So we should try to have a generic solution for the GIMP, that is not limited to EXIF only. If you look at bug #56443 and have a look at the proposal for adding EXIF support to the PNG file format (http://pmt.sourceforge.net/exif/index.html), you will see a long table that describes how the individual fields can be mapped from one file format to the other. That's why I wrote in my previous mail that all data should be saved in GIMP parasites, because that would allow each file plug-in to import/export the parts that are appropriate and discard or convert the rest. So we should be able to have something like this: Load JPEG/EXIF file - GIMP parasites - Save TIFF/EP file -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Mon, 2002-02-04 at 14:29, Dave Neary wrote: (...) Just so that you get an impression of libexif-gtk, I put up a screenshot of gexif, a frontend to libexif-gtk, on http://helena.bawue.de:8080/~lutz/projects/libexif/index.html I imagine this dialog being accessible either through some menu or through the JPEG-save-dialog (additional tabs). However, I first need to get either a larger disk for my laptop or a new computer in order to be able to work on this - don't have a gtk 1.2.x installation here. Lutz PS: It would be nice if this mailing list program could automatically cc replies to anyone sending mails to this list while not being subscribed (like me). -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
