Hi Raphaël, On Tue, Jul 22, 2008 at 04:50:41PM +0200, Raphaël Quinet wrote: > Since Roman has offered to improve the metadata handling in GIMP, Sven > asked me to document what my plans were for the metadata editor and the > JPEG plug-in. Well, these plans are best summarized in the mail that I > sent last year: > > [...] plans > > Maybe a few points from the first message (2.6 roadmap) should be > clarified a bit. In that message, I wrote: > [...] Thanks for clearing this up a bit. This makes the metadata browser far more complex than I intentionally thought. > [...] > > 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. For > example, assuming that Exif would now be handled correctly, the > current implementation would lead to the following scenario when a > JPEG image is saved: > > [...] tremendous amount of calls > > And here is what would happen if the metadata tree could be managed by > the GIMP core, but we still assume that the conversion to/from Exif is > done by an external plug-in: > > [...] less tremendous amount of calls > > Furthermore, here is what would happen if the metadata tree could be > managed by the GIMP core and some common metadata operations (such as > the conversion to/from Exif) would be in a "libgimp-metadata" library > linked directly with the file plug-ins that need it: > > [...] less, less amount of calls > > Sorry for the long details, but using an example like this is probably > the best way to explain why it would make sense to have some parts of > the metadata handling performed by a library, and why it would be > better if the metadata tree could be managed by the GIMP core instead > of being constantly converted to/from XMP and stored in a parasite. 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. > In my message from last year, I also wrote: > > + convert EXIF to XMP > > + convert XMP to EXIF > > The initial goal of the code that I started writing (and never finished) > for the conversion to/from Exif was to get rid of the dependency on > libexif. That library had caused several severe stability problems in > the past and most developers (including myself) wanted to replace it by > some code that was more stable. > > [...] > 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. 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. Cheers, -- Roman Joost www: http://www.romanofski.de email: romanofski@xxxxxxxx
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
