[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    Re: [Gimp-developer] metadata and JPEG - plans and current status
From:       Raphaël Quinet <raphael () gimp ! org>
Date:       2008-07-23 14:51:44
Message-ID: 20080723165144.a7197563.raphael () gimp ! org
[Download RAW message or body]

On Wed, 23 Jul 2008 11:20:41 +0200, Roman Joost <romanofski@gimp.org> wrote:
> On Tue, Jul 22, 2008 at 04:50:41PM +0200, Raphaël Quinet wrote:
> > [...]
> > Currently, the metadata tree is only available inside the metadata
> > editor, which is implemented as a plug-in.  This results in several
> > round-trips via the PDB whenever something must be updated.
[...]
> In my unexperienced point of view, it looks like this should be
> clarified first, before I try to improve the current metadata editor.
> IMHO your last point seems to be the way to go, all other attempts like
> the first one seems to be totally inefficient and error-prune.

Yes, this is also my point of view.  The best way to go is to have the
metadata tree available in the core with some PDB calls allowing plug-ins
to get/set data, and also have a "libgimp-metadata" library that can be
used by the file plug-ins for performing tasks such as converting between
Exif and XMP.  The editor itself could still be a plug-in, but the
lower-level parts of metadata handling would be included in the library
and another part of it would be in the GIMP core.

To recap, the three scenarios are:
1) metadata editor/viewer + metadata format converter + storage are all
   done by a plug-in (current situation);
2) metadata editor/viewer + metadata format converter done by a plug-in,
   but storage handled in GIMP core;
3) metadata editor/viewer done by a plug-in, metadata format conversions
   in a GIMP metadata library, and storage handled in GIMP core.
In the longer term, we can also think about a scenario 4 in which parts
of the metadata viewer/editor could be handled by the core, but that is
not for the short term anyway.

Although I think that it makes a lot of sense to have the metadata
tree inside the core as in scenario 3, Sven seems to disagree so I
would like to have his opinion before deciding how to proceed.

> > So contrary to what I originally planned, I think that the code for
> > converting to/from Exif should be based on that library.  This will
> > also make our code smaller and easier to maintain.
> My current plan was to provide a read-only view of the currently stored
> metadata inkl. a button to update the view. This included the conversion
> from Exif to XMP. Currently from my point of view - correct me if I'm
> wrong - the conversation will be called from the imagefile plugin (e.g.
> jpeg-load), after the Exif data is attached as a parasite. The metadata
> exif-decode procedure will convert the Exif data to XMP than, to be able
> to display it as XMP data in the metadata browser.

I think that you got it right. :-)  In scenario 1 above, when a file is
loaded the Exif block should be converted to XMP immediately (or more
precisely, it should be converted to a metadata tree, which happens to be
serialized as XMP) and then the metadata parasite is attached to the image.
Later, when the user starts the metadata editor or viewer, the parasite is
retrieved from the image and decoded into a metadata tree that can be
displayed to the user.

Note that in scenarios 2 and 3, it would not be necessary to convert the
metadata tree into XMP and store it in a parasite, because that tree would
be managed by the core.  The metadata viewer would only have to retrieve
the relevant elements for display or editing.  In fact, in scenarios 2 and
3 the metadata viewer/editor would not have to care about the XMP syntax:
it would only need to know the name and data type of the things that it
wants to display.

> Now after the pros and cons about handling metadata is clarified by your
> mail, how different do we set our priorities to move forward for this
> editor and the metadata management? I think we should setup a roadmap
> first, setup tasks afterwards and start implementing them.

Well, the thing that could change the plans significantly is a decision
about whether or not we integrate the metadata tree inside the core.  And
I would like to get Sven's comments about that.

If we start with scenario 2 (for example), then it should not be too hard
to switch to scenario 3 later.  However, if we start with 1, then it is
not easy to migrate to 2 or 3 later.  Most of the new code would have to
be rewritten differently.

-Raphaël
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[prev in list] [next in list] [prev in thread] [next in thread]