Hi, David Neary <dave@xxxxxxxxxxxxxxxxxxxxx> writes: > 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). parasites are stored and loaded from XCF files perfectly fine. Even global parasites attached to The GIMP are stored between sessions. There's nothing wrong with using this feature. > 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. 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. > 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 GIMP GIF plug-in limits this to 240 byte. > 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. I don't think so. The data would not be saved in the GIF file, but would still be attached to the image and could be saved in an XCF, another format that supports more metadata tags or a separate file. > > 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 think the contrary is true. If you introduce a structure with 50 fields to the GIMP core, you will have to add an awful lot of new PDB calls to make it accessible to the plug-ins. If you use parasites, the plug-in can easily look up the interesting parasites (the ones it understands) and use them. > > - 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 already have a rudimentary parasite editor. I don't like it much but it prooves that you can create a GUI for parasites easily. A Properties dialog should probably avoid to listen all parasites but limit itself to the ones defined for meta data. > > 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. I'd definitely vote for Raphaels proposal. Image metadata is what parasites have been designed for in the first place. I can only see one problem with parasites and that is the lack of type information. Parasites are named data blocks and it's left to the user how to interpret the data. I have no clue what information EXIF actually contains; it would probably help if you could write up a short summary. Salut, Sven
