Metadata: Exif orientation flag is wrong when converting HEIC photos to JPEG

[hiro5id]

Photos seems to be imported upside down, and some times sideways. Even though I am certain I did not take the photo upside down.

Here is a sample:

Orientation appears to be ok?

[graciousgrey]

Could you send example files to samples@photoprism.app ?

[lastzero]

The Exif orientation flag is probably missing or invalid.

[hiro5id]

Is that possible for it to be missing @lastzero even though I've imported it directly from iPhone using Apple's own Image Capture app?

[hiro5id]

ok @graciousgrey sent with subject line sample of original photos regarding issue 2214

[lastzero]

What version are you using? Any custom environment or user settings?

[lastzero]

Disabled any features?

[hiro5id]

i'm on the latest available release in dockerhub and in your github repo.. this is the image photoprism/photoprism:220302-buster
These are the environment varialbes and there is nothing overridden or disabled in the Settings page of PhotoPrism web interface.

      PHOTOPRISM_ADMIN_PASSWORD: "xxxxxxxxxxxx"          # PLEASE CHANGE: Your initial admin password (min 4 characters)
      PHOTOPRISM_SITE_URL: "xxxxxxxxxxx"  # Public server URL incl http:// or https:// and /path, :port is optional
      PHOTOPRISM_ORIGINALS_LIMIT: 10000               # File size limit for originals in MB (increase for high-res video)
      PHOTOPRISM_HTTP_COMPRESSION: "gzip"            # Improves transfer speed and bandwidth utilization (none or gzip)
      PHOTOPRISM_DEBUG: "false"                      # Run in debug mode (shows additional log messages)
      PHOTOPRISM_PUBLIC: "false"                     # No authentication required (disables password protection)
      PHOTOPRISM_READONLY: "false"                   # Don't modify originals directory (reduced functionality)
      PHOTOPRISM_EXPERIMENTAL: "false"               # Enables experimental features
      PHOTOPRISM_DISABLE_CHOWN: "false"              # Disables storage permission updates on startup
      PHOTOPRISM_DISABLE_WEBDAV: "false"             # Disables built-in WebDAV server
      PHOTOPRISM_DISABLE_SETTINGS: "false"           # Disables Settings in Web UI
      PHOTOPRISM_DISABLE_TENSORFLOW: "false"         # Disables all features depending on TensorFlow
      PHOTOPRISM_DISABLE_FACES: "false"              # Disables facial recognition
      PHOTOPRISM_DISABLE_CLASSIFICATION: "false"     # Disables image classification
      PHOTOPRISM_DARKTABLE_PRESETS: "false"          # Enables Darktable presets and disables concurrent RAW conversion
      PHOTOPRISM_DETECT_NSFW: "true"                 # Flag photos as private that MAY be offensive (requires TensorFlow)
      PHOTOPRISM_UPLOAD_NSFW: "true"                 # Allow uploads that MAY be offensive
      PHOTOPRISM_DATABASE_DRIVER: "mysql"            # Use MariaDB 10.5+ or MySQL 8+ instead of SQLite for improved performance
      PHOTOPRISM_DATABASE_SERVER: "xxxxxxxxx"     # MariaDB or MySQL database server (hostname:port)
      PHOTOPRISM_DATABASE_NAME: "xxxxxxxx"         # MariaDB or MySQL database schema name
      PHOTOPRISM_DATABASE_USER: "xxxxxxxx"         # MariaDB or MySQL database user name
      PHOTOPRISM_DATABASE_PASSWORD: "xxxxxxxxxxx"       # MariaDB or MySQL database user password
      PHOTOPRISM_SITE_TITLE: "PhotoPrism"
      PHOTOPRISM_SITE_CAPTION: "Browse Your Life"
      PHOTOPRISM_SITE_DESCRIPTION: ""
      PHOTOPRISM_SITE_AUTHOR: ""
      ## Hardware video transcoding config (optional)
      #PHOTOPRISM_FFMPEG_BUFFERS: "64"              # FFmpeg capture buffers (default: 32)
      #PHOTOPRISM_FFMPEG_BITRATE: "32"              # FFmpeg encoding bitrate limit in Mbit/s (default: 50)
      #PHOTOPRISM_FFMPEG_ENCODER: "h264_v4l2m2m"    # Use Video4Linux for AVC transcoding (default: libx264)
      #PHOTOPRISM_FFMPEG_ENCODER: "h264_qsv"        # Use Intel Quick Sync Video for AVC transcoding (default: libx264)
      # PHOTOPRISM_INIT: "intel-graphics tensorflow-amd64-avx2" # Enable TensorFlow AVX2 & Intel Graphics support
      ## Enable TensorFlow AVX2 support for modern Intel CPUs (requires starting the container as root)
      # PHOTOPRISM_INIT: "tensorflow-amd64-avx2"
      ## Run as a specific user, group, or with a custom umask (does not work together with "user:")
      # PHOTOPRISM_UID: 1000
      # PHOTOPRISM_GID: 1000
      # PHOTOPRISM_UMASK: 0000
      HOME: "/photoprism"
      ```

[lastzero]

Thanks for reporting this! The heif-convert script was not in /usr/local/bin. Should be fixed with 342904a. Started a new Development Preview build for testing...

[l8gravely]

Will new versions (when released) fix existing imported images or will we need to rescan the library?

[lastzero]

No, the JPEGs must be replaced but your app doesn't know which ones are affected. Even a complete rescan won't recreate existing JPEGs. Might have to add a parameter to the convert command to selectively recreate only jpegs for specific file types or dates. In any case, only a human seeing the pictures can make a decision what needs fixing.

[lastzero]

Advanced users could manually delete affected JPEGs from the filesystem (based on a search pattern, for example with the find command), then run "photoprism convert" and finally index. Complete rescan should not be necessary.

[hiro5id]

@lastzero wouldn't running photoprism thumbs --force regenerate and replace all the thumbnails ?

[lastzero]

Next build will include a --force flag for the convert command so that you can replace existing JPEGs in the sidecar folder (originals folder remains untouched), see 4be948c.

[l8gravely]

>>>> "Michael" == Michael Mayer ***@***.***> writes:

Michael> No, the JPEGs must be replaced but your app doesn't know Michael> which ones are affected. Even a complete rescan won't Michael> recreate existing JPEGs. Might have to add a parameter to the Michael> convert command to selectively recreate only jpegs for Michael> specific file types or dates. In any case, only a human Michael> seeing the pictures can make a decision what needs fixing. Right, a human needs to make the decision, but it would be nice if there was a way in the web interface to force a re-scan/regenerate of the thumbnails when there's a change in the file. Does photoprism only use the exif data once, when creating thumbnails and such? If so, then having an 'update' button might be a nice way to do it. John

[hiro5id]

to force a re-scan/regenerate of the thumbnails

I believe that photoprism thumbs --force will do that, no ?

[l8gravely]

>>>> "Roberto" == Roberto Sebestyen ***@***.***> writes:

Roberto> to force a re-scan/regenerate of the thumbnails Roberto> I believe that photoprism thumbs --force will do that, no ? Do you want to regenerate all the thumbs or just those which the source image changed? This is the key question to me.

[hiro5id]

Well, I guess it would be nice to be able to target specific folder or something like that. But I don't really care to at the moment. I will just run the thumbnail regen process all night long if I have to over my entire collection. Because I do know that I have other photos that are flipped the wrong way, it has been a problem with the previous version too, I just didn't bother to reach out for help. Now in the latest version it bothered me enough to actually ask about it.

[hiro5id]

or just those which the source image changed

Also @l8gravely , my source images haven't changed. My problem is that the source images are being imported wrong, meaning that it is generating thumbnails flipped or oriented the wrong way. The source images are fine, even when viewed in photoprism. I'ts just the thumbnail preview that is flipped for me. I am hoping that @lastzero 's fix of including the heif-convert script in the /usr/local/bin folder is the fix..... I have done that within my current docker container, so that I don't have to wait for another release. I am currently re-running the thumbnail generation with the --force flag, we'll see if that fixes my problem.

[lastzero]

The photoprism thumbs --force command does not replace the JPEG sidecar created from the HEIF file, but only the thumbs based on it.

[hiro5id]

You are right.... @lastzero .... it didn't update my badly oriented photos ☹️ .... what to do 🤔
darn... not even a complete rescan does it. ☹️

[hiro5id]

OK... I must be doing something wrong bacause I added the heif-convert script in the /usr/local/bin folder. I have deleted the sidecar files, and the did a complete re-index but they still got imported flipped around. Perhaps I'll have to wait for the official release.

[l8gravely]

>>>> "Roberto" == Roberto Sebestyen ***@***.***> writes:

Roberto> or just those which the source image changed Roberto> Also @l8gravely , my source images haven't changed. My Roberto> problem is that the source images are being imported wrong, Roberto> meaning that it is generating thumbnails flipped or oriented Roberto> the wrong way. The source images are fine, even when viewed Roberto> in photoprism. I'ts just the thumbnail preview that is Roberto> flipped for me. I am hoping that @lastzero 's fix of Roberto> including the heif-convert script in the /usr /local/bin Roberto> folder is the fix..... I have done that within my current Roberto> docker container, so that I don't have to wait for another Roberto> release. I am currently re-running the thumbnail generation Roberto> with the --force flag, we'll see if that fixes my problem. Oh right, yes, I recall now. Sorry! Of course the source image(s) haven't changed, it's just the EXIF/HEIF data wasn't read properly the first time around. Hmm... I wonder if the DB has a field where they note if the metadata wasn't read, so that a rescan would only need to go through those photos. I'm all about optimizing things when you have 70,000+ photos. I've got 100+gb of thumbnails myself. John