Jump to content

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


gerg nnud
 Share

This topic is 2606 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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? 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This topic is 2606 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

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