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 you correctly, your goal is to preserve the > metadata regardless of the file format being used and you want to > ensure that all load/save operations in the Gimp will keep this > information intact (but maybe not if other programs are used). Not necessarily, but I would like to offer the option to edit the metadata in a standard interface (a la Image->Properties, and the paintshop pro metadata editor), which is made difficult if we're never sure what data's around. I would also like to offer the option of saving data separate to the image in an associated file. Of course, this would be useless to all other apps, but it might become standard practise :) > We also have different ideas in mind regarding the implementation: > - I would like to implement this without requiring any changes in the > core. The plug-in authors would only have to export/import the > corresponding parasites in the file and would not depend on any > changes done in the core or in other plug-ins, so this can > already be done for the current stable version of the Gimp. > - You would like to implement this in the core by adding a new > metadata structure that is attached to the image. That's a fair summary :) I think that the one-off hit we'd take in the core is worth it, and that parasites would be at best inconsistent, and at worse extremely messy for plug-in programmers. I can see problems with both approaches. Mine's not back-portable, and it's a bit tricky when standards change in the future. But it's also consistent throughout the application, and given that plugins choose what data they want to read/write, I don't think I'd have a major problem with it. > So it is not surprising that we disagree. I think that I am right and > you think that you are right. ;-) Does anybody else have an opinion > on this? I think we might reach a compromise yet :) Cheers, Dave. -- .------------------------------. / David Neary, \ | E-Mail dneary@xxxxxxxxxx | \ Phone +353-1-872-0654 / `------------------------------'
