On Tue, 06 Feb 2002, Adam D. Moss wrote:
 > Raphael Quinet wrote:
 > > But it needs to be extended with all the names of the EXIF parasites.
 > > So I will try to do that this week.  Basically, I think that it would
 > > be enough to use the name "gimp-blah" for each "blah" field of the
 > > EXIF data and simply copy the descriptions given in the EXIF standard.
 > Fair enough, though if a parasite is going in the general-purpose
 > gimp-* namespace care should probably be taken not to impose
 > constraints specific to the EXIF form of that metadata upon
 > a more general-purpose gimp-wide version.

OK, so this means that any EXIF data that could also be used by other
plug-ins (such as Artist, Copyright, ImageDescription, ColorSpace and
many others) should use the gimp-* namespace and the type checking
should be relaxed if we can forsee other uses than what is described
in the EXIF standard.  If would then be up to the JPEG save plug-in to
constrain this parasite to the acceptable range when it saves it as

 > > Some of the fields will have to be discarded (or set read-only or not
 > > persistent) because they only make sense for the original file format
 > > and are irrelevant once the image is converted to an RGB bitmap.
 > Also fair enough, though I'd consider prefixing these with exif-
 > or similar to avoid polluting gimp-* forever.

If I am still following you correctly, this means that all parts of
the EXIF data that should not be persistent (such as SamplesPerPixel,
JPEGTables, YCbCrCoefficients, Interlace, ExifOffset and others that
are marked as "drop" in the PNG-EXIF proposal) would use a different
namespace.  These parasites would use the "exif-*" namespace and would
be discarded when the file is saved (even if it is saved in another
EXIF file, because that information must be re-constructed instead of
being copied).

On Tue, 06 Feb 2002, Lutz Müller wrote:
 > On Wed, 2002-02-06 at 14:50, Raphael Quinet wrote:
 > > Maybe we could also define
 > > the "exif-*" namespace as common, although it could also be
 > > "gimp-exif-*".
 > It would be _really_ easy if you used the tag names for those parasites,
 > i.e. gimp-exif-FillOrder or gimp-exif-SpectralSensitivity.

Yes, that's what I was planning to do.  Except that I would convert
the MixedCaseNames to hyphen-separated-names in order to be consistent
with other parts of the GIMP.

So the parasites would be split in several categories:
1 - "gimp-*" for existing persistent parasites that are already shared
     by several plug-ins (e.g, "gimp-comment" although the definition
     of this one is much too vague, as a consequence of the different
     meaning that it can have in different image formats).
2 - "gimp-exif-*" for new persistent parasites derived from the EXIF
     specification and that could be used by other plug-ins such as
     TIFF or PNG.  I will probably follow the list given in the
     PNG-EXIF proposal.
3 - "exif-*" for new non-persistent parasites derived from the EXIF
     specification.  These ones might be displayed in the "File
     Properties" dialog if we ever have one, but they would never be
     saved again in a file and they would not be used by other

The second category could be merged with the first one if we drop the
"-exif" part of the name and put everything under "gimp-*".  I do not
know what is better.  Comments?

 > Besides, that would save you a lot of writing, as you can just point to
 > the EXIF reference for names.

Sure, that was my goal.

 > By the way, libexif-0.3 and libexif-gtk-0.2 is out. If you use that, you
 > can even access the thumbnail embedded in the EXIF data using gimp-1.2.2
 > and my patches posted earlier. Again, just a proof of concept, but it
 > works.

Thanks.  I will have a look at it as soon as possible.  But as I wrote
previously and as Dave agreed, it would probably make more sense to
merge this code directly into the JPEG plug-in instead of requiring an
additional library.  Also, the GTK+ user interface should probably be
converted to a separate plug-in to view and edit all file properties.


Gimp-developer mailing list

Reply via email to