Sort by EXIF date

[Ludger]

I hope this is the right place, so here we go:
Good evening,
I am new to this forum and have just recently moved my private picture and movie gallery to a Coppermine-based site. I like the software very much with one exception: I painfully missed the option of sorting the album thumbnails by the original date from EXIF data. And since I am used to making the things I miss myself, I started making a new plugin for exactly this purpose. Now this thing is basically done, I am still testing...
To do what it is supposed to do, my plugin depends on 2 CPGPluginAPI-Lines that I added to functions.inc.php. Would it be possible to add these two "plugs" to future releases of Coopermine 1.5 and 1.6? My plugin works with these two versions.
Best regards from Aachen, Germany
Ludger
PS: I have opend a smal part of my site on http://bergdriesch22.de . The universal registration password is himbeereis123 .

[Ludger]

...these are the modified functions.inc.php . In the 1.5 version I added lines 1367 and 2155, in 1.6 I added the same lines at 1415 and 2177.
PS: I updated the patching according to what Ron did (see below).

[Αndré]

Some remarks. The check for $main_version is probably not needed, if you use the database wrapper functions, e.g. cpg_db_num_rows instead of mysql_num_rows.

I haven't found any code to insert the EXIF timestamp for files that will be added after plugin installation.

It seems you insert all EXIF timestamps during plugin installation. This will probably fail on large galleries with a comparatively small timeout value. You should better do this in a loop and add just (let's say) 100 items a time, like we do in the admin tools. Maybe a separate button to update (missing) EXIF timestamps will to the trick.

The plugin hooks themselves looks valid.

[Ludger]

The check for $main_version is probably not needed, if you use the database wrapper functions, e.g. cpg_db_num_rows instead of mysql_num_rows.

You are right. This saves me about 30 lines of code.

I haven't found any code to insert the EXIF timestamp for files that will be added after plugin installation.

My hook into CPGPluginAPI::action('add_file_data_success', $CURRENT_PIC_DATA) got lost somehow. Now it is in again.

It seems you insert all EXIF timestamps during plugin installation. This will probably fail on large galleries with a comparatively small timeout value. You should better do this in a loop and add just (let's say) 100 items a time, like we do in the admin tools.

The updates already take place in a loop as one query execution per loop. Here is the loop:

   while ($picture = single_picture($result2)) {
      $result = load_exif($picture);   
   };

And here is the function called:

function load_exif($picture) {
   global $CONFIG;
   $exifdata = exif_read_data($CONFIG['fullpath'].$picture['filepath'].$picture['filename']);
   if (isset($exifdata['DateTimeOriginal'])) {
         $datum = $exifdata['DateTimeOriginal'];
         $isexif = 1;
      } else {
         $datum = date('Y-m-d H:i:s:', filectime($CONFIG['fullpath'].$picture['filepath'].$picture['filename']));
         $isexif = 0;
      };
   $result = cpg_db_query("update {$CONFIG['TABLE_PICTURES']} set sbe_exif_date='{$datum}', sbe_source_is_exif='{$isexif}' where pid = {$picture['pid']}");
   return $result;
}

Just putting another big loop around my small one does not make sense for me, does it?

Maybe a separate button to update (missing) EXIF timestamps will to the trick.

I think, this is not needed, because EXIF is added after Upload. But still a button to re-EXIF (for example once you have exchanged some pictures) would be useful. I am just wondering about the right place for that button. I attached an updated version of the plugin...

[Ludger]

...forgot the link...

[Αndré]

The updates already take place in a loop as one query execution per loop. Here is the loop:

   while ($picture = single_picture($result2)) {
      $result = load_exif($picture);   
   };

Maybe "loop" was the wrong word. What I meant is something like we do in the admin tools when resizing pictures. It processes a couple of images, then reload the page and then process the next couple of images. Without a reload of the page (or AJAX) you still may exceed the PHP maximum execution time.

[ron4mac]

Also:  you shouldn't rely on exif_read_data() being available. See the change I had to make here because of that.

[Ludger]

André: I understand the problem. Had that timeout once on my real-life system. I am heading for launching a JavaScript, that starts a couple of Ajax-Worker-Spawns for the database. It will be interesting to see, if I can manage that through the plugin backdoors...

[Ludger]

Ron: I understand that there is already an EXIF reader in the software. Is that reachable for plugins? I would like to use it as fallback...

[ron4mac]

Ron: I understand that there is already an EXIF reader in the software. Is that reachable for plugins? I would like to use it as fallback...

Yes, you would do that similar to how it is done in the link above.
For a plugin, just add include_once 'include/exif.php';

[Ludger]

...I have now implemented the things you were proposing:

• The initial Generation of EXIF data is now done on many small queries via AJAX. Also, this process now runs asynchronous, meaning the user can do different things in the meantime.
• In case PHP-EXIF is not present, the plugin chooses the internal EXIF decoder already built into the Coppermine. Though, I found this one to be not very reliable, especially with Canon-JPGs it throws a lot of exceptions. The PHP7-decoder is also not 100%, so would you like me to check for the problem?

[Ludger]

...fixed one problem with reading the file date in case there is no exif on certain Linux-Server...

[phill104]

Seems to be coming on nicely. I have changed your membership to Contributor so you can add updated versions to your first post.

[Αndré]

would you like me to check for the problem?

Any suggestions for improved cpg functions are welcome In an ideal world we would just call cpg_exif (or whatever is the current or future name) and the function chooses itself the best way to retrieve the EXIF data according to available PHP EXIF functions.

[Ludger]

Seems to be coming on nicely. I have changed your membership to Contributor so you can add updated versions to your first post.

Thank you, Phill...

[Ludger]

In an ideal world we would just call cpg_exif (or whatever is the current or future name) and the function chooses itself the best way to retrieve the EXIF data according to available PHP EXIF functions.

This sounds very good, lets go for it! I will look into this next year...
For now I am not 100% happy with my sort_by_exif-plugin because my videos (.mp4) still get sorted by the file date. And the file date ist reset by the upload routine of coppermine. If I do batch-upload using sftp (not ftp) everything is OK. From my point of view there are two options to fix this:

• Improve the upload routine to conserve the file date
• Enable my plugin (and later cpg_exif) to read the most common metadata standards from video files

I think the second is better, because safer. Also, it would be helpful to visualize the origin of the sorting date of the image in the thumbnail list, maybe by a green, yellow or red LED-type indicator... Later I would like to add some metadata edit functionality to my plugin to enable easy fixing of problems...

[Ludger]

This thing is gaining shape and starting to get useful:

This Plugin now contains necessary additions for organizing the gallery by metadata:
- An option to sort the thumbnail list of an album by original date and time (from EXIF) is added.
- In admin mode the thumbnail list indicates the status of EXIF date: Green -> OK, Yellow -> not available.
- Also the metadata timestamp ist indicated in that list.
- For videos (MP4 only) the quicktime-metadata ist used.
Right now, the Plugin still needs two lines added in functions.inc.php for 2 new plugin-hooks.
Please see the second posting in this thread...

[ron4mac]

I will add the hooks to CPG 1.6, somewhat modified as to name and return code.

Code Select Expand

$sort_array = CPGPluginAPI::filter('thumb_get_pic_data_sortarray', $sort_array);
as:

Code Select Expand

$sort_array = CPGPluginAPI::filter('pic_data_sort_array', $sort_array);
and:

Code Select Expand

$sort_array = CPGPluginAPI::filter('thumb_get_pic_pos_sortarray', array($sort_array, $pid))[0];
as:

Code Select Expand

$sort_array = CPGPluginAPI::filter('pic_pos_sort_array', array($sort_array, $pid));
For this second one, there is no reason for you to return an array.
[edit]
Oops .. my error .. second one does need to be returned as a bundled array.
Implementing as:

Code Select Expand

list($sort_array) = CPGPluginAPI::filter('pic_pos_sort_array', array($sort_array, $pid));

[Ludger]

Implementing as:

Code Select Expand

list($sort_array) = CPGPluginAPI::filter('pic_pos_sort_array', array($sort_array, $pid));

Ups, I had to look up the list command in my PHP documentation: http://php.net/manual/en/function.list.php. This looks like we will run into problems with PHP 5, because the reading sequence there is different... I did not test that, but anyway, my hook-handler in the plugin does require both parameters (the array and the photo id) but does not change the id. So it is not necassary to return both:

Code Select Expand

$sort_array = CPGPluginAPI::filter('pic_pos_sort_array', array($sort_array, $pid));
would do the trick if I change the return of the plugin routine...

[ron4mac]

Plugin filters need to return a result in the same form as variables passed to it. It is passed to other filters of the same type and must continue to be in the same form. (something I initially forgot  )
So your plugin needs to return an array of the sort_array and pid (as you were doing).