Re: [Gimp-developer] EXIF and Gimp parasites (was: Current work)
Maybe I said this before, I can't remember, but the standard for trying to describe generic metadata is Dublin Core. So before burning too much midnight oil trying to organise metadata into neat categories at least type Dublin Core into a search engine. Even if one decided that DC itself was inappropriate for Gimp it does slice the cake up very neatly and you can re-use that hard work :) e.g. DC.Title = Wilber.GNU DC.Creator = [EMAIL PROTECTED] DC.Contributor = [EMAIL PROTECTED]; [EMAIL PROTECTED] DC.Date = 2001-10-04 DC.Format = image/png; 400x600 DC.Subject = Unholy alliance; RPC; Image manipulation DC.Publisher = GNOME Press Oh, and if someone actually defines some metadata standards for Gimp above and beyond those already described in the documentation for parasites then I will do what I can to help implement them for PNG, TIFF, PCX and any other file plugins I've been maintaining in the past. BUT we need a metadata editor, just a simple little thing with N text entry boxes that lets you change the metadata while changing the data (as one would expect) rather than hacking it into each and every file save dialog. Just IMO of course. Maybe I can find some time at the weekend to get an alpha GTK+ version and update this Red Hat system to run 1.3 CVS Gimp. Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF and Gimp parasites (was: Current work)
On Tue, 04 Dec 2001, Nick Lamb wrote: Maybe I said this before, I can't remember, but the standard for trying to describe generic metadata is Dublin Core. So before burning too much midnight oil trying to organise metadata into neat categories at least type Dublin Core into a search engine. Even if one decided that DC itself was inappropriate for Gimp it does slice the cake up very neatly and you can re-use that hard work :) I am quite familiar with Dublin Core because a part of my work involves dealing with semantic web and other funny things like CC/PP, UAProf, UDDI, WSDL, ... But this is a solution to the wrong problem. My goal is not to invent new ways to organize the metadata. I simply want to be able to parse, modify and save the metadata that is already defined in some standards such as EXIF and TIFF/EP. If recommend that you have a quick look at the document describing how EXIF data could be stored in PNG files. This document is available from http://pmt.sourceforge.net/exif/drafts/d020.html. It already contains a long list of tags that should be supported. Oh, and if someone actually defines some metadata standards for Gimp above and beyond those already described in the documentation for parasites then I will do what I can to help implement them for PNG, TIFF, PCX and any other file plugins I've been maintaining in the past. Nice to know... ;-) BUT we need a metadata editor, just a simple little thing with N text entry boxes that lets you change the metadata while changing the data (as one would expect) rather than hacking it into each and every file save dialog. Just IMO of course. This is exactly what is proposed in bug #61499. Take a look at this: http://bugzilla.gnome.org/show_bug.cgi?id=61499 See also bug #65181, which includes a small screenshot from PSP. It would be nice to have a plug-in that attaches itself to the menu entry Image-File-Properties and allows the user to view and edit the metadata in a user-friendly way. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF and Gimp parasites (was: Current work)
On Tue, 04 Dec 2001, Dave Neary wrote: On Tue, Dec 04, 2001 at 03:32:18PM +0100, Raphael Quinet wrote: Some time ago, I submitted two bug reports about this: http://bugzilla.gnome.org/show_bug.cgi?id=56443 (EXIF and metadata) http://bugzilla.gnome.org/show_bug.cgi?id=61499 (editing metadata) I saw and read these (and the standards you pointed to), and understood them to mean I've found this information, but don't have the time to work on them. That, and the facyt that the TODO item was unassigned, convinced me that ti was up for grabs :) That's right. Since I did not (and still do not) know how much time I will be able to spend on that, I did not want to have this task officially assigned to me because that could create expectations that I might not be able to fulfill. But I started working on it anyway. As I mentioned in bug #56443, I suggest that you read the discussion about EXIF on the PNG and MNG tools page (http://pmt.sourceforge.net/) The Rationale section of the proposal explains why the metadata should not be stored as one big chunk, but instead should be split in individual values and each value should be interpreted, converted or discarded as appropriate. [...] That has been thought of, and I don't think that one metadata structure rules that out. In a way, it's just one bucket in which we store the various pieces of information. Of course each of them would be individually modifiable, and would be modified as a matter of course during the manipulation of the image (a good example would be the width height parameters). If there is only one metadata structure, then the Gimp and the plug-ins will have to use the same structure. I would like to avoid that and decouple the plug-ins from the core as much as possible. This means that it should be possible to run a plug-in that supports new metadata tags with a version of the Gimp that uses an older version of the structure. If the new tag is present in the image file, then the plug-in should be able to load it from the file, attach it to the image and later save it to the file even if the Gimp does not know what it is. Or vice-versa: it should be possible to use a new version of the Gimp without having to recompile or relink the plug-ins. Using parasites has the advantage that you do not need to modify anything in the core: it only has to be done in the plug-ins (following the documentation that would be distributed with the Gimp). That's why I think that the first thing to do would be to define a list of standard image parasites in the Gimp, with precise definitions of the data types and constraints (so that's why I started studying the specs of the various image formats). Once this list is established and approved by everybody, this can be implemented in the load/save plug-ins. There is already a document in the source tree describing some parasites (devel-docs/parasites.txt) so we could expand it and add more information about the constraints (valid ranges and so on) for each parasite. I have a problem with creating potentially dozens of parasites and attaching them to images (possibly on a case by case basis, with some parasites not getting attached for some image types), when we could attach one object instead. My goal is to allow the Gimp to attach the appropriate metadata to the files that have a format that supports this information -- not more, not less. This means that GIF will only include a 7-bit ASCII comment limited to chunks of 255 bytes (without saying it if is a copyright message or document name or author name or whatever), while JPEG/EXIF will have many more features but maybe not the same as the ones supported by TIFF/EP or the proposed extensions to PNG. I do not want to attach extra information to the files if this information was not planned in the specification for that file format. If the spec includes only a limited number of fields, then the Gimp should only save those and drop the other ones because other programs reading or writing these images would ignore or even choke on the non-standard information added by the Gimp. So I do not want to be able to hide EXIF information in a TGA file using extension fields (although this would be possible). I simply want to be able to support the native metadata for each file format in the best possible way so that the Gimp could easily exchange this information with other programs. This means that we will loose some information when converting from one file format to another, but this is IMHO a better solution. Think about what would happen if the Gimp would include some additional metadata in a proprietary field added to some image format. If you modify and then save this file using another program, you will in the best case loose that information and in the worst case the program will copy this unknown metadata back into the new file and it will not match the new contents
Re: [Gimp-developer] EXIF and Gimp parasites (was: Current work)
On Tue, Dec 04, 2001 at 07:07:23PM +0100, Raphael Quinet wrote: On Tue, 04 Dec 2001, Dave Neary wrote: That has been thought of, and I don't think that one metadata structure rules that out. In a way, it's just one bucket in which we store the various pieces of information. Of course each of them would be individually modifiable, and would be modified as a matter of course during the manipulation of the image (a good example would be the width height parameters). If there is only one metadata structure, then the Gimp and the plug-ins will have to use the same structure. I would like to avoid that and decouple the plug-ins from the core as much as possible. That was my general idea. I can see that it has disadvantages (as you mention, back-compatibility and needing to do lots of stuff in the core are two). That parasites are supported in XCF is something of a red herring - as Sven's been at pains to point out, xcf is due for a spring clean to address some of the problems that are showing up with it, and in my vision of things metadata could be saved separate from an image, if we wanted to (similar to a thumbnail, as I said). This means that even if an image format doesn't support some of the data tags which are in our metadata object, the option will be there to save the metadata and retrieve it distinct from the image. This means that it should be possible to run a plug-in that supports new metadata tags with a version of the Gimp that uses an older version of the structure. If the new tag is present in the image file, then the plug-in should be able to load it from the file, attach it to the image and later save it to the file even if the Gimp does not know what it is. Or vice-versa: it should be possible to use a new version of the Gimp without having to recompile or relink the plug-ins. Using parasites has the advantage that you do not need to modify anything in the core: it only has to be done in the plug-ins (following the documentation that would be distributed with the Gimp). Here's where I run into a bit of trouble :) Under my scheme we'd have to extend the metadata object. But that would be OK. We I believe that this would happen rarely enough that our metadata object could handle the change. My goal is to allow the Gimp to attach the appropriate metadata to the files that have a format that supports this information -- not more, not less. My goal is to have a generic set of metadata which are somewhat modifiable by the user, and parts of which will be saved in image formats which support those parts (to use your example, we would not try to put any more than 255 bytes of ascii info into a gif. The rest of the metadata which we have about that image would not be completely ignored - the user would have the option of saving the metadata object in a well-defined format, and keeping all of the information he'd associated with the object. The image is still completely standard compliant, and the user has access to the data he created with the image if he wants it. This means that we will loose some information when converting from one file format to another, but this is IMHO a better solution. Think about what would happen if the Gimp would include some additional metadata in a proprietary field added to some image format. If you modify and then save this file using another program, you will in the best case loose that information and in the worst case the program will copy this unknown metadata back into the new file and it will not match the new contents of the file. Sure. But if you read an exif, and get an almost-full metadata object, and then you save a gif, youy would still have the option of saving that data separate to the image. Or even editting it, before saving. With parasites (if I understand correctly), you'd be throwing that info away. See my comment above about decoupling the core and the plug-ins. Besides, the parasites are not that bad. They are reasonably compact (in memory and in the XCF file) and easy to access from a plug-in. I think that it is nice for a plug-in to be able to fetch or set only the gimp-comment parasite without having to know anything about the other parasites that may be set on the image. My issue is not with parasites in principle, but for (say) exif, which supports about 50 meaningful data fields, that's an awful lot of parasites. I can see that making plug-in coding a lot hairier. I favour the former, but this is probably because we have different goals in mind about this metadata: - I would like to make sure that the Gimp can exchange as much information as possible with other programs (using the metadata that is supported natively by each file format -- maybe at the cost of loosing some information). This is a common goal. I believe we should store a superset of the data needed by each format, and let the plug-ins choose which data to write and/or ignore. - If I have understood
Re: [Gimp-developer] EXIF and Gimp parasites (was: Current work)
On Tue, Dec 04, 2001 at 10:36:50PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: The possibility to save the data indepently of the image format in a separate file a good idea but doesn't speak against using parasites for metadata. In fact, it's trivial to implement another Load/Save-Plug-In that implements just this. It could also trivially define a dialog to edit this parasite-metadata. The problem is entirely mapping metadata to parasites, just as it would be a problem mapping it to a non-standard API. That's what should discussed. we already have a rudimentary parasite editor. If you talk about the perl version - it was never finished because obviously nobody uses it for anything else than debugging. -- -==- | ==-- _ | ---==---(_)__ __ __ 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
