Thanks for the link.

But since it worked before without the plugin I'd rather convert things to the previous state. ALSO if viewed with any other imaging software the pictures are shown correctly.

Hi,

I have a similar, but slightly different problem.

I'm new to piwigo, so don't know if this behavior has changed, as noted by TheDoc.

I ftp files to a gallery, and sync. Landscape photos work well, just as expected.

Portrait photos are another matter. If I manually rotate and save a photo (on my desktop, then ftp the photo to my site), it works well, and exactly as expected.

However, if I don't manually rotate the photo (its orientation is defined by the embedded EXIF data), this is what happens:
1) photo displays well and properly rotated on my desktop prior to ftp to my site
2) after ftp & sync, the database entry gives a width wider than the height - it seems to come into the system in landscape mode
3) in viewing my piwigo gallery, the thumbnails and photo come out squished and fat - the portrait photo forced into landscape mode (and obviously distorted)
4) Unusual, but the iOS app displays everything correctly - the iOS app must go directly to the photos (and associated EXIF data, ignoring the database dimensions) to figure out the proper orientation.

To me, it appears that the initial sync of the new photo to the database isn't taking EXIF data into account.

As a newbie, I may have something set incorrectly, but it doesn't seem so. I'm happy to try troubleshooting if someone gives me a pointer as to where to look.

Dear executive,

Thank you for the suggestion - I tried uploading the same photo (not manually rotated, but requiring rotation as noted in the EXIF data), and the web upload worked perfectly.

So clearly, there is some difference in the code for web upload (and implied sync) and the manual sync (after ftp).

I'm interested in keeping physical albums, so would really like the manual sync to take EXIF data into account.

Any troubleshooting tips?

Thanks.

Hi all,

I've been pouring over the piwigo code, trying to make sense of this, and have come to the following conclusion (of course I may be wrong! Would not be the first time):

1) Uploading with the web interface, piwigo checks the exif data, and sets the database entry "rotation" correctly. Everything works as expected.

2) Using FTP to create physical albums, then using synchronize, piwigo does NOT check the exif "Orientation" of the photos. I would have thought it would have done this.

So I took it upon myself to try to fix it, and I think I have succeeded. I created a personal plug in that added a new exif tag, "rotation", that has the value needed for piwigo based on the "Orientation" exif data. And it is working on the few photos I've tried to this point.

Here is my local config:
<?php
/*
  Added the following to show more information per photograph

  Note that "rotation" normally doesn't exist; it is created and
  added onto the $exif array using a personal plugin
*/

$conf['use_exif'] = true;
$conf['show_exif'] = true;

$conf['show_exif_fields'] = array(
  'DateTimeOriginal',
  'Make',
  'Model',
  'FocalLengthIn35mmFilm',
  //'Orientation',           // remove comment if you wish to see exif orientation
  //'rotation',              // and resulting rotation
  'UserComment'
  );

$conf['use_exif_mapping'] = array(
  'date_creation'        => 'DateTimeOriginal',
  'comment'              => 'UserComment',
  'rotation'             => 'rotation',
  );

?>
===========================================

and here is the Personal Plugin I created:
<?php
/*
Plugin Name: Rotate
Version: 1.0
Description: Use EXIF data to set variable "rotation"
Plugin URI:
Author: hgregg
Author URI:

EXIF orientation ==> piwigo rotation   change
    1, 2                0 or NULL      no rotation
    3, 4                2              180 rotation
    5, 6                3              270 clockwise
    7, 8                1               90 clockwise

This is a bit of a hack, adding a non-exif tag to the array, but it seems to work.
*/

add_event_handler('format_exif_data', 'rotation_based_on_exif_data');

function rotation_based_on_exif_data($exif, $filepath) {

  if (array_key_exists('Orientation', $exif)) {
    switch($exif['Orientation']) {
      case 3:
      case 4:
        $exif['rotation'] = 2;
        break;
      case 5:
      case 6:
        $exif['rotation'] = 3;
        break;
      case 7:
      case 8:
        $exif['rotation'] = 1;
        break;
    }
   
  }
 
  return $exif;
}


?>
===========================================

This may not be very elegant code (I have very little [read as none before this project] php coding experience), but does update the "rotation" database entry upon sync.

TheDoc - would this work for you? I believe our issues are similar ...

Kind regards,
hgregg.

It turns out that sometimes a NULL is passed to this PersonalPlugin, and it gives unsightly errors. The below code is an update to correct this.

===================

<?php
/*
Plugin Name: Rotate
Version: 1.1
Description: Use EXIF data to set variable "rotation"
Plugin URI:
Author: hgregg
Author URI:

EXIF orientation ==> piwigo rotation   change
    1, 2                0 or NULL      no rotation
    3, 4                2              180 rotation
    5, 6                3              270 clockwise
    7, 8                1               90 clockwise

This is a bit of a hack, adding a non-exif tag to the array, but it seems to work.
*/

add_event_handler('format_exif_data', 'rotation_based_on_exif_data');

function rotation_based_on_exif_data($exif, $filepath) {
 
  if (!is_null($exif)) {
    if (array_key_exists('Orientation', $exif)) {
      switch($exif['Orientation']) {
        case 3:
        case 4:
          $exif['rotation'] = 2;
          break;
        case 5:
        case 6:
          $exif['rotation'] = 3;
          break;
        case 7:
        case 8:
          $exif['rotation'] = 1;
          break;
      }
    }
  }
  return $exif;
}


?>

Some more info:

When I force the graphics library to "gd" the images are shown correctly!

Unfortunately, there seems to be no "[DEBUG]    [i.php]    convert" output for the gd library. But at least some thing to dig further...