After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 507790 - Sort by exif date doesn't work as expected
Sort by exif date doesn't work as expected
Status: RESOLVED FIXED
Product: gthumb
Classification: Other
Component: general
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
Depends on:
Blocks:
 
 
Reported: 2008-01-07 08:26 UTC by Pascal Schott
Modified: 2008-02-11 13:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Pascal Schott 2008-01-07 08:26:39 UTC
Gthumb (2.10.6) seems to use the field Exif.Image.DateTime to sort the pictures, whereas I think it should use Exif.Photo.DateTimeOriginal.
Comment 1 Michael Chudobiak 2008-01-07 13:13:29 UTC
Well, gthumb trunk looks for tags in this order:

DATE_TIME
DATE_TIME_ORIGINAL
DATE_TIME_DIGITIZED

Why do you think DATE_TIME_ORIGINAL should be preferred over DATE_TIME?

- Mike


Comment 2 Pascal Schott 2008-01-07 13:43:06 UTC
Hi,

I am interested in having my pictures sorted by the date/time when they were token. If I modify a picture using the Gimp, DATE_TIME is modified and the picture will no longer appear at the right place. In contrast, DATE_TIME_ORIGINAL remains unchanged.

Thank you for your interest,

Pascal
Comment 3 Paolo Benvenuto 2008-02-09 10:58:22 UTC
I think other reason to use date time original is that with jhead (which I'm using when the camera clock was wrong) the date time is modified and not the date time original.
Comment 4 Paolo Benvenuto 2008-02-09 11:31:55 UTC
In the preceedint comment I was wrong. It's gimp that changes the DateTime field when saving the photo.
Comment 5 Paolo Benvenuto 2008-02-09 12:00:34 UTC
Working with exiv2 on some photo, I could note the folloing:
- DateTime is actually Exif.Image.DateTime, i.e. is the timestamp of the "image"
- DateTimeOriginal is actually Exif.Photo.DateTimeOriginal, i.e. is the timestamp of the photo.
- DateTimeDigitized: the same as DateTimeOriginal

Perhaps gimp changes the image timestamp because it's an "image software". It changes the datetime according to when the image was modified.

However, gthumb is a "photo software", and then it shouldn't consider Exif.Image.DateTime in ordering the photos, but Exif.Photo.DateTimeOriginal, which really is the timestamp of when the photo was shot.
Comment 6 Michael Chudobiak 2008-02-09 12:10:07 UTC
The trunk version of gthumb sorts using DateTimeOriginal. I hope to release it soon as 2.11.0. Please try it.

- Mike
Comment 7 Michael Chudobiak 2008-02-09 13:02:56 UTC
I've updated gthumb-2-10 as well. gThumb 2.10.9 and later will sort by DateTimeOriginal.

In the meantime, please try trunk. Trunk now uses exiv2 to read metadata.

- Mike
Comment 8 Pascal Schott 2008-02-09 17:28:51 UTC
Thank you very much for the fix. What is the procedure for testing "trunk" ? I found this page : http://www.t2-project.org/packages/gthumb.html, but the version proposed for download is 2.10.8.
Comment 9 Michael Chudobiak 2008-02-09 18:03:27 UTC
See http://developer.gnome.org/tools/svn.html

Basically:

svn co http://svn.gnome.org/svn/gthumb/trunk your-dir
cd your-dir
./autogen.sh --prefix=/usr  (the "prefix" part is for Ubuntu, Fedora)
make
su; make install

You may need to install quite a few support packages first - autogen will tell you if something is missing. (On Fedora, try:

yum groupinstall "GNOME Software Development"

to get most of the libraries. Once you have all of the prerequisite packages installed, it is quite easy to compile from trunk.

If trunk gets updated, you can update your installation by:

svn update
make
su; make install

Let me know if you run into trouble.

- Mike
Comment 10 Pascal Schott 2008-02-09 20:21:43 UTC
Hi Mike,

I fear that using trunk is somewhat beyond my skills. Here is what I get (on Ubuntu 7.10) :

$ ./autogen.sh --prefix=/usr
/usr/bin/gnome-autogen.sh
checking for autoconf >= 2.53...
  testing autoconf2.50... not found.
  testing autoconf... found 2.61
checking for automake >= 1.8...
  testing automake-1.10... not found.
  testing automake-1.9... found 1.9.6
checking for libtool >= 1.5...
  testing libtoolize... found 1.5.24
checking for glib-gettext >= 2.2.0...
  testing glib-gettextize... found 2.14.1
checking for intltool >= 0.30...
  testing intltoolize... found 0.36.2
checking for pkg-config >= 0.14.0...
  testing pkg-config... found 0.22
checking for gnome-doc-utils >= 0.4.2...
  testing gnome-doc-prepare... found 0.12.0
checking for gnome-common >= 2.3.0...
  testing gnome-doc-common... found 2.20.0
Checking for required M4 macros...
Checking for forbidden M4 macros...
Processing ./configure.in
Running libtoolize...
Running glib-gettextize... Ignore non-fatal messages.
Copying file mkinstalldirs
Copying file po/Makefile.in.in

Please add the files
  codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
  progtest.m4
from the /aclocal directory to your autoconf macro directory
or directly to your aclocal.m4 file.
You will also need config.guess and config.sub, which you can get from
ftp://ftp.gnu.org/pub/gnu/config/.

Running intltoolize...
Running gnome-doc-common...
Running gnome-doc-prepare...
You should update your 'aclocal.m4' by running aclocal.
Putting files in AC_CONFIG_MACRO_DIR, 'm4'.
Running aclocal-1.9...
aclocal:configure.in:53: warning: macro `AM_PATH_ORBIT2' not found in library
aclocal:configure.in:286: warning: macro `AM_GCONF_SOURCE_2' not found in library
Running autoconf...
configure.in:53: error: possibly undefined macro: AM_PATH_ORBIT2
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:286: error: possibly undefined macro: AM_GCONF_SOURCE_2

Comment 11 Michael Chudobiak 2008-02-09 22:06:33 UTC
Don't give up yet! You're almost there!

Do you have libgconf2-dev and glib2-dev installed?

- Mike
Comment 12 Pascal Schott 2008-02-10 16:03:56 UTC
Thanks, libgconf2-dev and a bunch of other "-dev" packages were missing. Now, the "autogen" step seems to work, but "make" produces the following errors (though libexif-dev) is intalled :

(...)
../libgthumb/jpegutils/.libs/libgthumb-jpegutils.a(jpegtran.o): In function `set_exif_orientation_to_top_left':
/home/pascal/Paquets/gthumb/libgthumb/jpegutils/jpegtran.c:110: undefined reference to `exif_data_get_byte_order'
/home/pascal/Paquets/gthumb/libgthumb/jpegutils/jpegtran.c:119: undefined reference to `exif_content_get_entry'
/home/pascal/Paquets/gthumb/libgthumb/jpegutils/jpegtran.c:121: undefined reference to `exif_set_short'
../libgthumb/.libs/libgthumb.so: undefined reference to `exif_data_save_data'
../libgthumb/.libs/libgthumb.so: undefined reference to `exif_data_new_from_data'
../libgthumb/.libs/libgthumb.so: undefined reference to `exif_data_dump'
../libgthumb/.libs/libgthumb.so: undefined reference to `exif_data_ref'
../libgthumb/.libs/libgthumb.so: undefined reference to `exif_data_unref'
collect2: ld returned 1 exit status
make[3]: *** [gthumb] Erreur 1
make[3]: quittant le répertoire « /home/pascal/Paquets/gthumb/src »
make[2]: *** [all-recursive] Erreur 1
make[2]: quittant le répertoire « /home/pascal/Paquets/gthumb/src »
make[1]: *** [all-recursive] Erreur 1
make[1]: quittant le répertoire « /home/pascal/Paquets/gthumb »
make: *** [all] Erreur 2

Comment 13 Michael Chudobiak 2008-02-10 16:56:21 UTC
Oops, that is a bug!

I'll fix it today or tomorrow.

- Mike
Comment 14 Michael Chudobiak 2008-02-10 17:21:12 UTC
OK, that should be fixed now. Type:

svn update

and try "make" again.

- Mike
Comment 15 Pascal Schott 2008-02-10 19:25:35 UTC
It worked !
The photos are now sorted as expected.
Thank you very much for the fix and your help.
Comment 16 Michael Chudobiak 2008-02-10 19:55:18 UTC
Thanks for testing! You've already helped identify one bug!

Let me know if other problems arise.

- Mike
Comment 17 Pascal Schott 2008-02-10 20:03:15 UTC
Perhaps one little problem : when I click on a photo, the exif information DateTime is copied to the comment field of the picture. The only way I've found so far to remove this comment is to delete the .comment field from the directory.
Comment 18 Michael Chudobiak 2008-02-11 13:50:42 UTC
OK, I've tweaked the comment-metadata loader a bit. It only reads the metadata date if other metadata (a comment, a location, or keywords) have been loaded. I think this is better.

The problem is that almost all photos have DateTime metadata, but relatively few have comments / locations / keywords - but we still want to load things consistently.

- Mike