Re: [Gimp-developer] EXIF in JPEGs and TIFFs
On Fri, 2003-03-14 at 20:09, Jason Van Patten wrote: > Is there a plan to support reading/writing EXIF information found in > files such as JPEGs and TIFFs? Sure. The plan is to come up with some mechanism to store information (like EXIF) in and convert that information between several different file formats, including JPEG and TIFF (Sven et aliud). The current state is that there has been a patch to preserve and edit EXIF information in JPEGs using libexif. This patch never got into the GIMP nor was updated to 1.3.x as (1) it would add another dependency to an external library (2) it would not reach the goal as stated in above plan. > And, libexif is JPEG-centric. It's certainly handy, but it'd be even moreso > to support other file formats (TIFF specifically.) This request pops up a lot. My camera is really old and can't produce TIFFs. So, I don't have any incentives to add support for TIFFs to libexif. But I will happily integrate patches that are sent to me. -- Lutz Müller <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Occasional Bug List
On Wed, 2002-11-06 at 23:05, David Neary wrote: > Looks kind of plaform-specific... how would you go about doing > that for Solaris, SGI or Windows? Alternatively, if someone hacks up a plain-C-library called libmem or similar for figuring out free memory and stuff like that on various systems, we can join the efforts in gimp and libgphoto2. Lutz -- +--+ | Lutz Müller +49 (7156) 34837 | | | | Hans-Sachs-Strasse 5 | | 71254 Ditzingen http://www.topfrose.de | | Germany [EMAIL PROTECTED] | +--+ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The Occasional Bug List
On Wed, 2002-11-06 at 23:09, Guillermo S. Romero / Familia Romero wrote: > And for OSes that do not have that, like FreeBSD 4.6? It does not take > into account details like disk speed or shared systems either. After I wrote the email, I verified. There is currently even support for *BSD. If someone wants to add a solution for Windows or other OS, he/she is certainly very welcome :-) Lutz -- +--+ | Lutz Müller +49 (7156) 34837 | | | | Hans-Sachs-Strasse 5 | | 71254 Ditzingen http://www.topfrose.de | | Germany [EMAIL PROTECTED] | +--+ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Occasional Bug List
On Wed, 2002-11-06 at 22:54, David Neary wrote: > Seems like a reasonable metric - but the default tile cache is 32M, > and most people have upwards of 128M RAM these days. Maybe if we > were to use this metric we should consider upping the default > tile cache to at least 64M? If you're loading images from a > camera with 3 megapixels, 32M is big enough to have 1 image open > with 2 layers and no undo levels. Which seems a little harsh :) In libgphoto2, someone recently implemented reading the available memory from /proc/meminfo (if available) and act according to that. The code is at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gphoto/libgphoto2/libgphoto2/gphoto2-filesys.c?rev=HEAD&content-type=text/vnd.viewcvs-markup Look for gp_get_free_memory. Lutz -- +------+ | Lutz Müller +49 (7156) 34837 | | | | Hans-Sachs-Strasse 5 | | 71254 Ditzingen http://www.topfrose.de | | Germany [EMAIL PROTECTED] | +--+ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dependancies (used to be xinput)
On Thu, 2002-06-06 at 20:17, Philip Brown wrote: > Fair enough. But that being the case, please fix the configure script so > that when "pangoft2" is not found, it prints out a more useful message Instead of writing these lines (and your other mails), why don't you submit a patch? I am pretty sure that people will welcome your contribution. Lutz -- +------+ | Lutz Müller +49 (7156) 34837 | | | | Hans-Sachs-Strasse 5 | | 71254 Ditzingen http://www.topfrose.de | | Germany [EMAIL PROTECTED] | +--+ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP for Windows 1.2.3?
On Tue, 2002-03-12 at 21:31, Tino Schwarze wrote: > > So, to over-simplify, what would be the point in porting software to > > Windows that intends to provide you with an emulation of software (for > > Windows) you already got with the camera? > > Uhm. Maybe because you get a consistent interface in Win* as well as in > Linux? Or maybe you don't need to rely on crappy, cheap > shipped-with-camera software? Or maybe gphoto will evolve while the > shipped-with-camera software will not? > > I can imagine several reasons for a gphoto port to Win*. It's always > nice to have a choice! That, and often, the windows software doesn't give access to all features of the camera, doesn't use the full download speed, doesn't let you capture images (because the vendor wants you to buy additional software), or simply does not run on Windows because it has been designed for Windows only. Lutz -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP for Windows 1.2.3?
On Tue, 2002-03-12 at 17:42, Branko Collin wrote: > And, as I said, for us it would not be bad to ride the wave of the > digital camera. If some Windows guy steps forward to port gphoto2 (http://www.gphoto.org) to Windows, you would even have digital camera support _in_ the GIMP through gtkam's plugin (i.e. capture from within the GIMP, download directly into the GIMP, etc.). Lutz -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 2002-02-06 at 16:06, Raphael Quinet wrote: > 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. As this conflicts directly with my dislike to copy & paste instead of using common libraries, I won't do that. See, libexif is needed by gphoto2, a command-line frontend to libgphoto2. And libexif-gtk is used by gtkam, a GTK frontend to libgphoto2. I hope that libexif will be used by other exif tools, especially command-line tools. I am not willing to keep several libexif versions together or to answer for incompabilities among those. Perhaps someone else... > Also, the GTK+ user interface should probably be > converted to a separate plug-in to view and edit all file properties. libexif-gtk is an EXIF editor. If someone wants to write a gimp-parasite editor, this is ok. But I'd still like to give users the possibility to access/edit all EXIF data, because a gimp-parasite editor will never be able to cover all EXIF tags. Just think of MakerNote the contents of which vary from manufacturer to manufacturer. Lutz -- +------+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] EXIF information in JPEG files
On Wed, 2002-02-06 at 14:50, Raphael Quinet wrote: > The only > thing that should be checked is the usage of the "gimp-*" names, which > should have a pre-defined name and type. There are currently only one or two pre-defined names and types that relate to EXIF data. Once you have defined the parasites, I'll come up with a converter "parasites <-> EXIF data". > 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. Besides, that would save you a lot of writing, as you can just point to the EXIF reference for names. 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. Lutz -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
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 2>&1; 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
#include
+#ifdef HAVE_EXIF
+#include
+#endif
+
#include
#include
@@ -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_u
Re: [Gimp-developer] EXIF information in JPEG files
On Mon, 2002-02-04 at 14:29, Dave Neary wrote: (...) Just so that you get an impression of libexif-gtk, I put up a screenshot of gexif, a frontend to libexif-gtk, on http://helena.bawue.de:8080/~lutz/projects/libexif/index.html I imagine this dialog being accessible either through some menu or through the JPEG-save-dialog (additional tabs). However, I first need to get either a larger disk for my laptop or a new computer in order to be able to work on this - don't have a gtk > 1.2.x installation here. Lutz 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). -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] EXIF information in JPEG files
On Mon, 2002-02-04 at 15:04, Sven Neumann wrote: > > 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? > > if it solves our problems and works for non-JPEG images too, I don't > see any problem in adding such a dependency to gimp-1.3. EXIF information is specific to JPEG files. Therefore, editing and storing EXIF information make sense with JPEG images only. Sure, you could try to save/hide/convert it in other image formats, but this is not the purpose of the EXIF specification. I'll try to come up with something and ask again together with a patch. Lutz -- +------+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] EXIF information in JPEG files
On Mon, 2002-02-04 at 14:29, Dave Neary wrote: > Thereare a couple of other libraries which do pretty much the same > thing - > see the relevant bug numbers in bugzilla (not sure what they are right > now). > I haven't had a chance to look closely at this, but it looks good. There is python stuff, a C++ library, lots of programs, but no plain C library. Plus, everything out there is designed for _extracting_ EXIF data, not _editing_ it. This is why I designed libexif(-gtk). > Yup. We use a straight call to libjpeg's header parser, which doesn't > know > anything about exif. A couple of people (myself and Raphael Quinet) > were > looking at this with a view to adding support in 1.3 at least about a > month > and a half ago. So I am the third person looking at 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? > The last I had done was a very > simple > hack which replaces our call to the header reader with a call which > read exif > information. This is now a one-line call to libexif (exif_data_new_from_data()). > The next step would have been to specify how that > information > would be passed over and back between the main gimp and the jpeg > plug-in. > There was some discussion on this, and it was agreed by everyone > (eventually) that parasites were the way to go. Ok, I'll look into this. > There was a proposal before to have an exif data editor This is libexif-gtk - just call gtk_exif_browser_new () and you've got the editor... > (or even a > parasite editor) > as well, but I reckon the first step is getting the exif stuff read > into some well-defined > structure, Already there in libexif. > and getting it written out to files in the same proper > structure without > destroying it. Not yet done. I'll try. Lutz -- +--+ \|||/ | Lutz Müller+49 (7156) 34837 | (o o) | +---ooO-(_)-Ooo---+ | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.topfrose.de | | Germany[EMAIL PROTECTED] | ++ signature.asc Description: This is a digitally signed message part
[Gimp-developer] EXIF information in JPEG files
Hi!
I have written an EXIF library in plain C ("libexif") and some GTK+
widgets for displaying and modifying EXIF data ("libexif-gtk"). Both are
available on http://libexif.sourceforge.net. I use them to display EXIF
tags in gphoto2 (command-line frontend) and gtkam (GTK+ GUI).
However, when loading images from a digital camera directly into gimp
and letting GIMP save the images (i.e. as JPEG files), all EXIF
information gets lost. In addition, right now, gimp doesn't offer access
to EXIF information when loading JPEG files.
How do I go about adding EXIF support to gimp? Should I distribute a
loader for JPEG files that replaces the current one? Submit a patch to
gimp's JPEG loader and configure.in to --enable-exif if libexif(-gtk) is
installed?
In any case, how do I save "per-image" (not per-loader) EXIF data?
Lutz
--
+------+ \|||/
| Lutz Müller+49 (7156) 34837 | (o o)
| +---ooO-(_)-Ooo---+
| Hans-Sachs-Strasse 5 |
| 71254 Ditzingenhttp://www.topfrose.de |
| Germany[EMAIL PROTECTED] |
++
signature.asc
Description: This is a digitally signed message part
[Gimp-developer] gimp & gphoto2
Now that the capture plugin works, people would like to be able to download pictures from their cameras directly from within gimp. However, that is not that easy. Can it be that there is no possibility to register something like "camera:/folder/my_file.jpg" (like "http://...";)? Even if above were possible, it seems that it would not result in thumbnails, folder and file listings (gtk-file-selection is too limited for that - no hooks for file/folder listings), another possibility would be to write a file opening dialog for files on digital camera. But where do I hook that up? There is no "/File/Open" submenu where I could put the menuitem in. That functionality doesn't fit into "/File/Acquire". I suppose there are no plans to make gimp use gnome-vfs (a gphoto2 plugin for gnome-vfs already exists). Have you thought about writing something like gimp-vfs where I could write a gphoto2 plugin for? Ideas? Lutz -- \|||/ ++ (o o) | Lutz Mueller +49 (7156) 34837+---ooO-(_)-Ooo---+ | | | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.uni-karlsruhe.de/~Lutz.Mueller | | Germany[EMAIL PROTECTED] | +--+ msg01307/pgp0.pgp Description: PGP signature
[Gimp-developer] gimp & gphoto2
Hi! I thought you could be interested in this: gtkam, a GTK frontend to gphoto2 (http://www.gphoto.org) has been expaned to include a gimp-plugin that lets you capture images with your digital camera. When clicking on "/File/Acquire/From Camera...", you'll get a life preview dialog. If you then decide to capture a full image, the image gets captured, downloaded and is ready for post-processing. Thanks to the gimp team for making this possible through the plugin-mechanism. If you like to try it out, get latest CVS sources of gphoto2 and gtkam from http://www.sourceforge.net/projects/gphoto. Happy hacking and image processing! Lutz -- \|||/ ++ (o o) | Lutz Mueller +49 (7156) 34837+---ooO-(_)-Ooo---+ | | | Hans-Sachs-Strasse 5 | | 71254 Ditzingenhttp://www.uni-karlsruhe.de/~Lutz.Mueller | | Germany[EMAIL PROTECTED] | +--+ msg01265/pgp0.pgp Description: PGP signature
