Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Explanation as to why exif data is only available when importing from a 'device'

Featured Replies

This is not so much about wanting a solution but about wanting to know the technical reasons behind the inability to import exif data with an import of images from a hard drive.

 

As a photographer the usual workflow is to dump the CF or SD card data to HD first so it can be sorted, assessed etc. 

 

FMP11 can import the image's exif metadata from a 'device' such as a camera, smartphone or card reader but not from an image directory on a hard drive. I would prefer to import after this workflow step is completed and not directly from the camera.

 

I know there are solutions to this problem via plugins, Java script integration, RAMDisk creation and so on but I would just like to know what is the technical caveat that restricts FMP (and other programs) from importing exif from a hard drive? 

I don't know the answer, but I can offer you a guess:

 

At some point, Apple established a protocol by which pictures could be transferred from a digital camera to the iPhoto application (this part is not a guess). Then someone at Filemaker had an idea: "Why don't we use this to transfer images directly to Filemaker containers?". Next thing, the engineer in charge of implementing this said: "This is cool: did you know this protocol also transfers EXIF data? Why don't we channel this to some text fields while we're importing the images?"

 

Note that this feature was discontinued in version 12 and starting from version 13, EXIF data (or at least some of it) is available through the GetContainerAttribute() function.

  • Author

OK Your guess makes sense.

1. I will have to delve into v13 to see what has changed/added to address this issue - GetContainerAttribute.

2. So Filemaker v11 is relying on an implementation of Mac OS and iPhoto to achieve this? What happens on Windows?

I'm still scratching my head over the fact that the metadata is a part of the file header no matter where it is - CF, SD, HD. Its not just FMP that has this issue it seems.

 

Thanks Comment. Always appreciate your input.

So Filemaker v11 is relying on an implementation of Mac OS and iPhoto to achieve this? What happens on Windows?

 

Nothing. This is a Mac-only feature.

 

 

I'm still scratching my head over the fact that the metadata is a part of the file header no matter where it is

 

Maybe, but I suspect Filemaker (v.11 and earlier) is not getting it from there.

  • Author

OK. I started looking at Javascript libraries and some FMP integration but instead found a reasonable solution for anyone who's interested. Not sure if it works cross platform yet but it works on Mac. Can someone test? A free plugin called ExifPlugin parses the exif data (both platforms).

 

I played around a bit with the included demo file and generated a layout and field structure that made more sense.  Each exif display field has an auto enter calculation so that it can store the specific exif data on a 'folder' import. I realised this only works on images stored in the DB itself so a quick script to import a folder of images then re-import the image container again as reference only from the same folder.

 

The first import is slow for 2 reasons. 1. It is storing the whole image so this will be many Mb's per image and 2. generating a thumbnail of the image in the FMP process is very slow. This could be taken out of the equation but I like the concept of a tiny image reference embedded in the DB, just in case.

 

The second import simply updates the image container from actual file to reference only, and is quick. The best thing is that the DB is now 180Kb vs 20.5Mb for 4 images yet displays the same info. Of course the DB now always needs the images in the original folder to reference to.

 

So I am now thinking that the script could perform without dialog if you were to think of the folder it selected the images from as a watch folder (hard coded) and a bit of extra shell script could then move the files to their final storage location and then update the file paths for the container reference. Could be a useful tool.

 

So here it is. (Don't try this on a folder of 900 images unless you're willing to wait for a long time.) Special thanks go out to jensteich.de for the FREE plugin and to Comment for keeping my mind active. 

 

ExifPlugIn.zip

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.