*** Bug 150403 has been marked as a duplicate of this bug. ***

could be nice

*** Bug 162739 has been marked as a duplicate of this bug. ***

*** Bug 303393 has been marked as a duplicate of this bug. ***

As a workaround it's possible to extract the exif creation time and touch the
file to make the modified time match (this was noted in Bug 162739).  It's a
fragile solution since further changes will reset the modified time, but it may
be an acceptable compromise in some environments.

I've created a script to automate this process for directories of images.  It is
primarily for my own use, but I've made it available at
"http://lococo.org/mike/exif-touch/" in case it may be interesting to other
users.  I hope end-user workarounds are considered appropriate in the bug
database, and I apologize if not.

yeah, that's essentially what I do, though my script isn't quite as large as
yours:  http://www.crushedredpepper.com/nikon/scripts/exiftouch

:)

The duplicate bug 142590 suggested using comment date.  This seems to be a  
better idea because exif data may not exist for all images.  There's already an  
easy way to take the comment data from the exif date. 

It's worth noting that as of 2.6.5 (and perhaps earlier) gthumb can set the
modified date to match the exif date, so scripts to do so are not necessary. 
Look in the "Tools" menu at the "Change Date" option.

Yes, but the modified date is the date it was modified. The exif date is the
date it was taken.

I too would like to see an option to sort by exif date.  I want two seprated dates kept on the file but am usually most interested in the date the picture was taken, not the date I modified(renamed) the file.

A sort by Exif DataTime tag mode has been added to CVS HEAD.

- Mike

It seems to me that this feature slows down the image browsing too much. I guess you have to read the exif data of all of the images in a folder before displaying them and this must be the cause of the slowness.  You should change the code in such a way that the exif data is only read when it's required to sort images, that is when the user chooses the "sort by exif datetime" option.

I reopen the bug because I don't like the status quo...

OK, I'll take a look.

- Mike

Sorry, Paolo, I didn't notice the performance loss on my system. Thanks for the feedback!

Anyway, I've committed a new patch so that the Exif DateTime tags are only read when sorting in the Exif DateTime mode. The file mtime associated with the tag is recorded, to detect changed DateTime tags (and to allow "caching" of unchanged ones).

I left the catalog_web_exporter and catalog_png_exporter routines as-is with the simpler code, since performance isn't really an issue there. (Also, the "ImageData" struct is not visible to the libgthumb code currently, unlike the FileData struct, so it isn't as simple to tweak the sort routine for these functions.)

Let me know if you see room for improvement.

- Mike

well, you asked for it :) 

due to the fact that reading comment files is faster than reading the exif data inside an image, the following optimization could be implemented:

if comment mtime < image mtime 
  read the exif data from the image and save it in the comment file
else
  read the exif data from the comment file
end

this way sorting by exif date is slow only the first time you visit a folder.

This sort of exif data cache could be used in other parts of the code as well.

Err.. wait a minute, please don't touch mtimes. If the file hasn't been modified, the mtime should stay the same.

The performance problem should only affect people who enable the exif date sorting, so everyone else shouldn't have the exif date even read, they use the old sorting method and see no change in performance.

I think you misunderstood, you don't have to change the image mtime, you have just to compare the comment file mtime and the image file mtime and update the comment data when the image is newer than the comment.

(In reply to comment #16)
> if comment mtime < image mtime 
>   read the exif data from the image and save it in the comment file
> else
>   read the exif data from the comment file
> end
> 
> This sort of exif data cache could be used in other parts of the code as well.


Hmmm... that's clever... I'll have to think about it for a while, because I haven't worked with the comments codebase.

It has to work nicely on read-only filesystems too, where we don't have comments.

The current code will probably do for now, but I'll open a new bug to record the idea.

(Sorry about the compiler warnings in my patches... I'll be more careful in the future. I'm learning.)

- Mike