Re: [Gimp-developer] EXIF information in JPEG files
Raphael Quinet wrote: The basic idea is that each file plug-in that supports metadata can convert the EXIF data (or other meta-data) to/from GIMP parasites. [snip] Note that it is important that each individual item in the EXIF data is converted to a separate GIMP parasite instead of importing the whole EXIF data in one big chunk because some parts of the EXIF data must be modified when the image is re-saved (also, some file formats do not support all fields so it is easier to work with them if they are saved in separare parasites). I'm not sure I agree with you here... I thought the matter was closed and that we were in agreement last December, but as I understand it there is no reason to have more than one parasite for exif data (or if you prefer a more generic metadata parasite which encompasses a superset of exif). My understanding, from what Sven and Mitch told me back then, was that a part of a parasite could quite easily be modified independant of the rest. So your concern about bits being modifiable does not imply (as you suggest) different parasites for different bits of data. At least that's how I understand it. I'm not sure whether the discussion was on- or off-list (I get mixed up sometimes), but that's what I took away from it. I just don't know how to handle the dependency on libexif(-gtk). You know, libexif itself is quite small and could be included in gimp (although I'd keep it separately), but libexif-gtk is getting bigger and bigger as more widgets are added. Therefore my question: Is it ok to introduce a (conditional --enable-exif) dependency on libexif(-gtk) for gimp? Well, I don't know what is the best thing to do. libexif should probably be integrated directly into the JPEG plug-in (and maybe adapted for the TIFF and PNG plug-ins) but I assume that large parts of it would have to be rewritten in order to use GIMP parasites as the storage format for all data. I agree here - just replace the bits that parse the jpeg header currently with the appropriate bits that parse the exif info and put it in a usable format/structure. There's no need to add a dependency on libexif, just add the code either to the existing jpeg.c, or in another file called something imaginative like exif.[ch], and link them together when making the jpeg plug-in. I would keep the gtk stuff (the interface) separate from the jpeg plug-in completely. As Raphael suggests, I would use it possibly as a basis for a generic parasite editor, or specifically as an image metadata editor. -Raphael Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Tue, 5 Feb 2002, Dave Neary wrote: Raphael Quinet wrote: [...] Note that it is important that each individual item in the EXIF data is converted to a separate GIMP parasite instead of importing the whole EXIF data in one big chunk because [...] I'm not sure I agree with you here... I thought the matter was closed and that we were in agreement last December, but as I understand it there is no reason to have more than one parasite for exif data (or if you prefer a more generic metadata parasite which encompasses a superset of exif). There are several reasons for using individual parasites for each part of the EXIF data instead of using a single parasite including the whole structure: * The metadata is likely to be useful for other plug-ins, even if they do not understand the full EXIF format. If the EXIF data is saved in one big chunk, then every file plug-in that wants to use a part of the information (for example, only the author name or only the date at which the original image was created) would have to be able to decode the EXIF format, deal with struct padding, byte-ordering problems, and so on. It should not be necessary to do all this in a plug-in if the only thing that it wants to do is to get a string or a timestamp from the metadata associated with the image. * The EXIF standard requires some fields (e.g., DateTime, Software) to be updated by any application that conforms to that standard. If a plug-in does not understand or does not need some of these fields, then it is better to drop them instead of copying them blindly. Using separate parasites makes the default behavior correct (because if a plug-in does not know how to handle a part of the EXIF data, it will not know its name either so it will not get it and copy it). * Instead of rephrasing them, I will simply quote three additional reasons directly from the proposal to include EXIF data in the PNG file format (http://pmt.sourceforge.net/exif/drafts/d020.html): - The data is potentially useful to human readers; this proposal allows them to view the information with existing PNG software. If it were kept in binary form, only special-purpose applications would be able to read it. Also, combining different data management methods (as in Exif format that embeds TIFF and JPEG encoded stuff), makes things unwieldy. - Data that is of no conceivable use after the image has been converted from the original format (JPEG tables, TIFF tiling layout, etc.) would be unnecessarily saved, wasting space. - The data would be at risk of being unnecessarily discarded by PNG editors. * The GIMP can use more metadata than what is defined in the EXIF standard. This could be done (and is already done) by using separate parasites for saving generic or GIMP-specific information. For consistency reasons, it would be better if all plug-ins would simply have to know the name and type of a parasite in order to be able to access its value, instead of having to go through an intermediate parsing step if the data is saved in the EXIF block. My understanding, from what Sven and Mitch told me back then, was that a part of a parasite could quite easily be modified independant of the rest. The parasites are just untyped blocks of data, so a plug-in could certainly copy everything, modify a part of the data and then re-attach the updated parasite to the image. But again this would assume that all file plug-ins that want to use (a part of) the metadata are able to parse the EXIF block. I would prefer to avoid this requirement. [snipped other comments for which we agree] -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Raphael wrote: On Tue, 5 Feb 2002, Dave Neary wrote: Raphael Quinet wrote: [...] Note that it is important that each individual item in the EXIF data is converted to a separate GIMP parasite instead of importing the whole EXIF data in one big chunk because [...] I'm not sure I agree with you here... I thought the matter was closed and that we were in agreement last December, but as I understand it there is no reason to have more than one parasite for exif data (or if you prefer a more generic metadata parasite which encompasses a superset of exif). There are several reasons for using individual parasites for each part of the EXIF data instead of using a single parasite including the whole structure: [snipped points] Your points all have merit. My problem is now, and has always been, that a parasite per piece of data would mean adding an extra 50 or 60 parasites which would be relatively persistent. That makes things pretty complicated, to my mind. Instead we could store the whole metadata in a nice format (say as xml?) as one parasite, and have it parsed in one place. Then people who want to use bits of the metadata would just use the bits they wanted, and ignore the bits they didn't (in terms of file formats this certainly doesn't contradict your concern about things being copied blindly - it amounts to the same thing as your opinion that those things should be ignored blindly). I think one structure, defined in one place, makes the handling of metadata cleaner. I'd equate it somewhat loosely to the move from a number of preferences to one preferences structure which we had a while back. I think your concerns about passing around data which will eventually be ignored, and incurring an overhead through parsing one big object into something meaningful, are real. I think they could probably be addressed easily. My understanding, from what Sven and Mitch told me back then, was that a part of a parasite could quite easily be modified independant of the rest. The parasites are just untyped blocks of data, so a plug-in could certainly copy everything, modify a part of the data and then re-attach the updated parasite to the image. But again this would assume that all file plug-ins that want to use (a part of) the metadata are able to parse the EXIF block. I would prefer to avoid this requirement. And herein lies the crux - one object which is parsed by any object that wants to use bits of it, or multiple objects which are the bits. I think the cleanliness of having everything in one place is appealing. I think it could make things less convoluted for places thgat use a lot of the data, and not too bad for places that only use a little. Maybe we'll never agree :) Then again, maybe someone else will offer an opinion, and one of us will realise how wrong we were? Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
On Tue, 2002-02-05 at 19:08, Raphael Quinet wrote:
Hi Lutz!
On Tue, 5 Feb 2002, Lutz Müller wrote:
PS: It would be nice if this mailing list program could automatically cc
replies to anyone sending mails to this list while not being subscribed
(like me).
Does this mean that you have not seen the two replies that I posted
yesterday, and the discussion today between Dave Neary and myself?
Just read it on the web. As I don't have gtk-1.3 and greater available
on my system, I won't be able to contribute anything right now.
In case you are interested in a proof of concept of the alternative 1
big EXIF parasite:
Attached are diffs against gimp-1.2.2:
- configure.in (adding an opt. dependency to libexif-gtk)
- acconfig.h (#undef HAVE_EXIF)
- plug-ins/common/Makefile.am (EXIF_LIBS, EXIF_CFLAGS)
- plug-ins/common/jpeg.c (some lines of code)
Apply them and you will be able to edit EXIF data when the JPEG format
chooser will pop up after selecting a filename. In addition, EXIF
information will not get lost if you open a JPEG file and save it again
as JPEG.
If you define how parts of the EXIF information should be stored in
individual parasites so that they are accessible to other plug-ins, I
can easily write an importer/exporter (EXIF data - GIMP format).
However, I think the user should still have the possibility to add/edit
EXIF tags that are not handled by those individual parasites.
Lutz
--
+--+ \|||/
| Lutz Müller+49 (7156) 34837 | (o o)
| +---ooO-(_)-Ooo---+
| Hans-Sachs-Strasse 5 |
| 71254 Ditzingenhttp://www.topfrose.de |
| Germany[EMAIL PROTECTED] |
++
--- configure.in.orig Tue Feb 5 23:19:52 2002
+++ configure.inTue Feb 5 23:24:56 2002
@@ -643,7 +643,38 @@ dnl fi
dnl AC_SUBST(PYGIMP_CFLAGS_NOUI)
dnl AC_SUBST(PYGIMP_LIBS_NOUI)
dnl AM_CONDITIONAL(BUILD_PYTHON, $build_python)
-
+
+dnl ---
+dnl libexif-gtk: JPEG files can contain EXIF data. If libexif-gtk is installed
+dnl on the system, gimp can use it to read this data from
+dnl JPEG files and save it (if the file is saved again in
+dnl the JPEG format). In addition, gimp can offer the user the
+dnl possibility to edit (!) EXIF data.
+dnl ---
+exif_msg=no (http://www.sourceforge.net/projects/libexif)
+try_exif=true
+AC_ARG_WITH(exif, [ --without-exif Don't use libexif],[
+ if test x$withval = xno; then
+ try_exif=false
+ fi])
+if $try_exif; then
+ AC_PATH_PROG(PKG_CONFIG,pkg-config)
+ if test -n ${PKG_CONFIG}; then
+ AC_MSG_CHECKING([for libexif-gtk])
+ if ${PKG_CONFIG} --exists libexif-gtk /dev/null 21; then
+ EXIF_CFLAGS=`$PKG_CONFIG --cflags libexif-gtk`
+ EXIF_LIBS=`$PKG_CONFIG --libs libexif-gtk`
+ exif_msg=yes
+ AC_DEFINE(HAVE_EXIF)
+ fi
+ AC_MSG_RESULT($exif_msg)
+ else
+ AC_WARN([Not searching for libexif - pkg-config not found.])
+ fi
+fi
+AC_SUBST(EXIF_CFLAGS)
+AC_SUBST(EXIF_LIBS)
+
GIMPINSTALL=
if test $INSTALL = $ac_install_sh; then
--- acconfig.h.orig Tue Feb 5 23:29:29 2002
+++ acconfig.h Tue Feb 5 23:08:46 2002
@@ -19,6 +19,7 @@
#undef HAVE_CATGETS
#undef HAVE_DIRENT_H
#undef HAVE_DOPRNT
+#undef HAVE_EXIF
#undef HAVE_FINITE
#undef HAVE_GETTEXT
#undef HAVE_IPC_H
--- Makefile.am.orig Tue Feb 5 23:30:17 2002
+++ Makefile.am Tue Feb 5 23:18:09 2002
@@ -15,6 +15,7 @@ INCLUDES = \
-I$(top_srcdir) \
-I$(top_srcdir)/intl \
$(GTK_CFLAGS) \
+ $(EXIF_CFLAGS) \
-I$(includedir)
libexec_PROGRAMS = \
@@ -722,6 +723,7 @@ jpeg_LDADD = \
$(top_builddir)/libgimp/libgimpui.la \
$(top_builddir)/libgimp/libgimp.la \
$(LIBJPEG)\
+ $(EXIF_LIBS)\
$(GTK_LIBS)\
$(INTLLIBS)
--- jpeg.c.orig Tue Feb 5 23:06:55 2002
+++ jpeg.c Tue Feb 5 23:08:13 2002
@@ -138,6 +138,10 @@
#include jpeglib.h
#include jerror.h
+#ifdef HAVE_EXIF
+#include libexif-gtk/gtk-exif-browser.h
+#endif
+
#include libgimp/gimp.h
#include libgimp/gimpui.h
@@ -273,6 +277,9 @@ static JpegSaveInterface jsint =
static gchar *image_comment = NULL;
static GtkWidget *restart_markers_scale = NULL;
static GtkWidget *restart_markers_label = NULL;
+#ifdef HAVE_EXIF
+static ExifData *exif_data = NULL;
+#endif
MAIN ()
@@ -424,6 +431,10 @@ run (gchar *name,
default:
break;
}
+#ifdef HAVE_EXIF
+ exif_data_unref (exif_data);
+ exif_data = NULL;
+#endif
g_free
