A few months ago I discovered a simple technique that significantly reduced the size of a database that included many container field images.
I used a couple of FileMaker script steps to copy the container field to the clipboard and then paste the clipboard directly back into the field. I looped through the records to perform this operation for all records.
Go to Record/Request/Page [First]
Loop
Copy [Select; CONTACTS::Photo]
Paste [Select; CONTACTS::Photo]
Go to Record/Request/Page [Next; Exit after last]
End Loop
The resulting stored information as reported by the Length() function of each FileMaker container field was up to 10 times smaller! I performed my tests on Mac OS 10.6.4 with FileMaker 11. I had one database that went from 1.2 GB to around 400 MB after performing this operation on many records. This is significant…especially for speed when accessing these fields over the WAN. It also makes the file much easier to backup.
There seems to be no down side to this method. It is possible that many of these container fields were populated in previous versions of FileMaker which may have stored information in the container in a different manner. My theory is that there may have been additional preview images stored or cross platform versions in PICT/WMF and that the clipboard operation removes them and only leaves the native JPG which displays fine across Windows or Mac.
Notes:
- This technique most likely will not work with other types of data like sounds or PDF files that are stored in container fields and I did not do any testing of those data types.
- Sometimes this technique can actually increase the size of the stored image. I’m not sure under what circumstaces this occurs. It’s important to test and use the Length(Image) function to see how big the actual stored image is.
At this point, what I know is that it worked for me and this particular database. Your mileage may vary…but if it helps, it will significantly improve the performance of your database.
If anyone understands what is going on here underneath the hood I’d love to know more and see if there would be any disadvantages to using this technique.
Reduced to 72 DPI?
I did a couple of tests to see what was going on here. For the purpose of the tests, I created a new database file with a single Container field in FileMaker 11 Advanced.
Test 1: Single image
I imported a single 4MB JPEG image into a container field – file size = 4.2MB. I then tried a manual copy and paste. No change in file size. I then did an Export Field Contents step and the exported file was the same size as the original.
Test 2: Multiple images
I imported a folder of 243 slides that I had scanned, all JPEG files. Image sizes ranged from 7.1 to 13.9MB. Final file size after import was 2.12GB. I used Save a Copy (compacted) and created a new file. The compacted copy was the same size as the original 2.2GB. I then ran your script on the 243 images.
After the Copy/Paste script ran, I checked the file size with “Get Info” and found it unchanged at 2.12GB. Just to be sure, I ran another Compacted Copy but the resulting file was still 2.12GB.
My guess is that what happened with your database has something to do with the kinds of images and the way they were stored in previous versions of FM and/or your file got compacted along the way. I’ve seen some FM files reduced in size by more than 50% if they have been in use for a long time and never compacted.
HI. So I came across your script bc I am having the same issue with slow FMP Adv 11 database over a network. I have found that there are several hundred images in my database that range from 5MB-32KB. I did a test of your script but I am not sure if it worked. Do you know if there is a way to set up something on a mac that automatically reduces image file sizes on a clipboard to less than 30KB so when it pastes back into the database it will be no more than 30KB? Or any other updates/suggestions since your posts?
Thx again!
Kara
One way to deal with this issue of large container field images is to use a product like SuperContainer from 360Works http://www.360works.com/supercontainer/. It stores the images outside of FileMaker and creates a thumbnail image that is small for display purposes. You could set up an AppleScript to automatically resize an image using an external application like GraphicConverter that is triggered off the modification of the container field when you paste into it. The only issue here is that all users would need to have that application available and be on a Mac. You could also set up a nightly script to run that would resize any images above a certain specified size. I might opt for this last method.
Hi Tim,
the nugget for me in your piece was the Length() function – one issue that I have had in the past is not knowing if there was anything in the container field or not. I have in the past used a script to manage the insertion of a picture and error capture to check if the user aborted the import – but this feels a little uncertain. Using the length() option will tell me if the container has been filled or not. I use this where I have one layout that has options to display one. two, three or four images in differing arrangements depending upon how many pictures appear on a record. This will help make that far more secure
If anyone has any other ways of checking on the contents of a container – lets have them!
- Thanks!
Troi has a plugin that will resize images and reduce their size in the container. You can set the size. Particularly useful if you are only using the graphic for display at a fixed size on the layout. The original image on disk is not affected.
I used Snaggit to capture two side by side Filemaker windows, the script editor and the script. I copied and pasted into Filemaker the screen capture later to learn the images were over 2 Megs in size. So I saved the images to disk as pngs into a folder then imported the folder. The size of the pngs averaged 200k or 10%.
Performance over a remote connection will be affected by the size of the images.
What a typical outside-of-the-box thinking!
Great example, Tim. I agree it must have to do something with unnecessary previews generated by previous version of FileMaker. But whatever it is, even if it had worked only in your one specific case with one specific database, the most important lesson to learn IMHO is that even something that look like a nonsense at first sight may be a functional solution.
I tried the technique using a screen capture image which is rather large, 3 Megs, and it was not reduced in size. If I first save that image as a JPEG, the size is reduced by the software compression to about 200K.
JPEG and PNG files are by nature compressed to about 1/10th or so the size of the full image. JPEG discards some information that we can’t see and then the compression reduces the size further. Since they are already compressed there is little we can do to shrink their size.
Different images will be reduced in size, for instance a monochrome image will reduce the smallest while a complex photography will produce the larger size file.
I think I remember that EPSF files contained multiple sized images and these may be what Filemaker reduced in the example.
If Filemaker is going to do any changing of the image (I don’t think it will) then the image would have to be in a format that is not reduced such as RAW photos, etc.
My guess is that your paste eliminated some corrupt data or cleaned up the corruption. Any blank container fields in the file?