11 Replies Latest reply on Dec 17, 2014 8:27 AM by ScottAR

    GetThumbnail

    ScottAR

      Title

      GetThumbnail

      Post

      Hello. I've been using FMP11 for a long time, as I hadn't had a need for the features of newer versions... until one particular one caught my eye:

       

      http://www.filemaker.com/help/12/fmp/html/func_ref1.31.14.html

      But knowing the GetThumbnail function exists doesn't quite answer some practical questions. Without getting bogged down in details, here's the setup and the issues: 

      I have a BIG database (30k records) of a database of images (again, without getting into details, my situation made FM a better option than a graphic database). It contains a lot of relevant text fields and a single container field that contains a thumbnail. With FMP11, I'd basically scripted (using non-FM tools) to copy an image selected in Finder, resize it proportionally to 500 pixels horizontally, and paste that into the container.

      The database has gotten VERY big (22gb), presumably because of tens of thousands of embedded images in that container field.

      My questions, therefore, are these:

      1) would the GetThumbnail function result in a smaller database?

      2) how would I go about converting the existing database to use the function in place without having to re-import a vast number of image?  Would something like this ("Putting It on Autopilot") work to convert the existing images, or only on those that are later imported?

      3) Would I need to create an empty copy of the existing database--i.e., with the same fields, except with GetThumbnail for the container, and then import the existing database into it?

        • 1. Re: GetThumbnail
          philmodjunk

          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.

          • 2. Re: GetThumbnail
            ScottAR

            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.

            • 3. Re: GetThumbnail
              philmodjunk

              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.

              • 4. Re: GetThumbnail
                ScottAR

                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?

                 

                • 5. Re: GetThumbnail
                  philmodjunk

                  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.

                  • 6. Re: GetThumbnail
                    ScottAR

                    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?

                    • 8. Re: GetThumbnail
                      philmodjunk

                      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.

                       

                      • 9. Re: GetThumbnail
                        ScottAR

                        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.

                        • 10. Re: GetThumbnail
                          Sorbsbuster

                          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.

                          • 11. Re: GetThumbnail
                            ScottAR

                            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.