1) if you used it to resize the pixel dimensions of your embedded graphics, yes. But you can also get a smaller file by inserting references to your graphics instead of embedding them.
2) You can just use replace field contents on the container field with the get thumbnail function to do a batch update of all your container field images in one massive batch operation. Don't even need a script. But this would take awhile to complete.
3) That could be done, but as long as you have a back up copy on file, it's not necessary and will take longer as you'd have to move more data around than just your image files.
1) I'd considered using references, but decided against it because it's too easy to get broken in case the original is moved around or the like.
2/3) I don't mind the time if it means a smaller file (of course, just saving 1-2 gb wouldn't mean much). Either method, wouldn't I need two copies just to be safe? I'd hate to do a batch update and find that I'd goofed up somehow.
1) A valid concern if multiple users need "write" access to that shared directory where you park all the files. That's why v12 and 13 offer external storage as an option. That option does not require that any users have "write" access to the folder where the images reside.
2/3) Yes, but your 2nd copy can just be the original copy before you tried to modify it with Replace Field Contents.
How much savings in size will depend on how much you chose to downsample the resolution of your image files. I suggest opening a copy of your file and using GetThumbNail on a found set of just a few records to see how this can work and you can compare the file size before and after to see how much the file size changed and to estimate how much this will reduce the size of your file. After you do this operation, you can use Save a copy as with the "compressed" option to probably recover a bit more space and some users report a pretty dramtic file size reduction by importing all of your data from all of your tables into a clone of the file--a detail I had not recalled when making my original post.
Thanks for your replies.
All the image files are on two external drives; the 30k FM records are representative of hundreds of thousands of images--i.e., each record (and containered image) describes a particular discrete set. My concern was more that I'd have to move the images around for different reasons (e.g., if I rearranged folders, moved them to new drives, et al) and that would break the links.
I see that the format is GetThumbnail(field;width;height). Can height be left blank in some way so that the image width is resized according to X, while the height is changed to whatever number is proportionate? Also, assuming I'm reading it correctly, you can use "Self" for field to use the contents of same field you're doing the calculation on; any reason to prefer that over the field's actual name?
You'll get quicker answers if you take a file and try this out on the file to see for yourself.You have to specify a height. Why would you want to leave it blank? See the examples in Help on how you might use this function call.
I haven't purchased it yet. V. 11 has been working fine for me; before I buy 13 based on this one feature I wanted to be sure it would work out.
I'd leave height blank because I don't know what it would be. If I was going to resize a 4000 x 3000 image (just to use round numbers) down to 500 wide, that would be 375 on the Y. But if the next image is 4000 x 3500, then using a 500x375 preset would change the proportions. I've read that FM will retain the proportions of the original image for the thumbnail, but it's not clear that it knows which axis to retain as the default (I want to always force the X axis). If it's going to do so--maintain the proportion--than isn't setting one of the axes superfluous?
You can use a calculation to reduce both dimensions by the same percentage to give just one example.
And it is possible to get the current pixel dimensions first in order to calculate the new dimensions that you want to use with GetThumbnail in order to downsample the image.
isn't setting one of the axes superfluous?
Nevertheless you'll need to specify that dimension as a parameter from what I can tell. More things you can try with your trial copy to see what happens.
Well, testing it out with
GetThumbnail ( Self ;500 ; 600 )
the database grows from 22.3 GB (the size I'm trying to shrink) to 27.8. That's by cloning the old database (i.e. no records) and adding that to the container field, along with "Do not replace value of field (if any)" unchecked, then importing the records from the full database into the cloned one.
I would link by relationship, and use a script to pick up the image from wherever it is first, and store it in your defined location (whether or not you use FM13's 'External Storage' function.) The file size will be small. Your only reason not to is in case you don't maintain 'Good File Management Practice'. But I'm guessing that you really would want good housekeeping practices, anyway. For example if you now amend an image file it will not amend the image in your database. I would store all the images in a mapped drive. if you want to move them, simply re-map the drive letter to that new location.
I really wish you'd just accept my decision to NOT store the images externally; it wasn't made on a whim. If not and a longish explanation is needed, here's the shortest I can come up with:
It's a database of about a million images dating back to the late '90s. For obvious reasons there was no practical way I could put EVERY image into the database (nor do I need to), so instead I have a representative image for each set (anywhere from a dozen to a couple of hundred) of distinct groups of images. That representative image--call it a cover--shows me at a glance what the set is all about better than keywords can. Because the only purpose of the cover is to give me a visual summary of the set, it does not ever change so I don't need it updated within the database. So, outside of database file size, there's no good reason to keep the cover image stored externally.
Further, there's the issue of the losing the link to the images, if kept externally. I have all of the images divided up by Folder>Subfolder>Subsubfolder (and no deeper) by logical categorization. Since the images go back so far and there are so many of them, I sometimes discover that I'd wrongly filed their sets, and so change their locations, sometimes between hard drive volumes (the full collection is divided between two 4 TB drives). For that and other reasons, I think the links would break.
Also, about a year and a half ago, one of the drives they were stored on failed beyond recovery--it wouldn't mount, and even removing the drives and plugging them into docks wouldn't mount them. I had it all backed up, and put the backup online and ordered a new backup drive. In that two day window, all of the data disappeared from the drive. I don't mean the drive was erased or otherwise obviously corrupted--I mean that every single folder was present in its proper position, but they were all totally empty. Every data recovery app I used (DiskWarrior, Disk Utility, TechTool Pro) said that the drive was just fine, no problems detected. I used data recovery software to recover a large percentage of images (sidenote without going on a tangent: don't use Stellar Mac Data Recovery software). Hundreds of thousands of images in no real order and without the original file names.
But I had the Filemaker database with the embedded cover images--kept on a different drive--and those records have been crucial in my slow re-sorting of those images. Had I used a reference to the original files, that container field would be empty and I'd really have been further up a certain creek, this time without the paddle.
In short, I need and want the images to be within the database.