On Tue, Dec 04, 2001 at 10:36:50PM +0100, Sven Neumann wrote:
> David Neary <[EMAIL PROTECTED]> 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.
My point was simply that since the general idea was to associate
metadata with an image, we could do so under either scheme, and
the fact that xcf stores parasites is pretty much a distinct
> > 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.
I would have hoped that the benefit of one structure is that we
could accomplish exactly that in one pdb function. I may be
> > 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)
> 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.
Fair point. So the options are to define a standard set of
parasites which get set and read at appropriate points, some of
which can be modified by the user, and then implement the
setting/editting/writing of the parasites in the appropriate
places (which would be the image format plug-ins and the image
metadata editor plug-in). We could also implement read/write
operations for the image metadata there.
> 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
Unless there's a relatively easy way to pass one block of data
around with a drawable, I've been convinced. If I get some time
I'll do a brief write-up of what can be done in exif (it's a
pretty long list, but divides pretty nicely into groups).
/ David Neary, \
| E-Mail [EMAIL PROTECTED] |
\ Phone +353-1-872-0654 /
Gimp-developer mailing list