10 Replies Latest reply on Aug 14, 2015 8:19 AM by philmodjunk

    Image based database is very slow

    BenHough

      Title

      Image based database is very slow

      Post

      Hi all

      I have developed a solution for the Art business I work for. We have maybe 100 records of artworks. Each record has 5 container fields into which a set of buttons can load and delete images and pdf documents relating to the artworks.

      I have written into the script of these buttons that filemaker should store a reference to these images and pdf, since the images are often quite high resolution jpgs and I did not want to increase the size of the database file to unreasonable proportions. I was also told that it was best practise to reference files rather than store them in Filemaker.

      However, having loaded all the images into the records, the performance of filemaker is slow beyond belief.

      It is certainly worsened by the fact that the setup in my office is as such: my computer hosts the filemaker file while the images are on a NAS drive in our local network.

      I can see that it may be better to store all images relating to the database on the host computer, but would it be even better to store them all in the DB file?

      I am getting mixed messages from my online searches in this matter. Filemaker themselves write the following:

      Calculation fields should be stored whenever possible.  Unstored calculations calculate "on the fly" when needed, which is much slower.  Avoiding finds on unstored calculation fields or doing record level access calculations on large files, can prevent slowness in databases.
       

       

       

      Many thanks in advance for any advice and views

       

        • 1. Re: Image based database is very slow
          philmodjunk

          With Hi-resolution images, there's a lot of data to transmit from the hard drive to the monitor screen of the person viewing the image. This is true no matter how/where the image is stored.

          The best bet to improve performance is to NOT use a layout with 5 container fields on it showing 5 different hi res images for each record. Use low res thumbnails of these images on such a layout and use a different layout with a large format container field to display a single image in hi res only when the user clicks a button to view that image in detail.

          • 2. Re: Image based database is very slow
            steveromig

            Ben -

            Thank you for your message

            I suspect the images being stored on the NAS is not helping your performance issues and you could benefit from storing your container content in your FileMaker Pro solution or moving your externally stored container data to the same drive as your FileMaker solution.

            And FYI...stored and unstored calculations is not the same thing as storing your container data inside your solution versus externally.  A stored calculation does just that - it stores the results of the calculation and doesn't constantly recalculate the results unless some action  warrants it.  An unstored calculation calculates the result of the calculation every time it is displayed which will slow things down.

            TS_Shark
            FileMaker, Inc.

            • 3. Re: Image based database is very slow
              BenHough

              Thanks Phil. I was thinking thumbnails would be solution, but I am not 100% clear how filemaker handles images. For example - it seems that FM only loads images when they come into user view - only 1 container is shown on the main layout, while the rest are stored in a pop up, and those images seem to load only when requested. correct me if I am wrong.

              Does filemaker have any thumbnail operations built in, or is it necassary to manually create and load them in?

              • 4. Re: Image based database is very slow
                philmodjunk

                You can use the GetThumbnail function to generate thumbnail copies of your images and these allow you to precisely control the resolution of the thumbnail just produced and a script could loop through your images and produce one such thumbnail for each.

                You can also manage thumbnail options specified for all your container fields. See: "Managing performance with thumbnails" in FileMaker help for more info on these options.

                • 5. Re: Image based database is very slow
                  BenHough

                  Brilliant - that's great news. Cheers Phil

                  • 6. Re: Image based database is very slow
                    BenHough

                    Phil - given that my images are stored by reference, I seem to be having the issue reported on the Known Bugs List here:

                    http://forums.filemaker.com/posts/127431d34e

                    When a script step of the following is run:

                    Set Field ( Works::ImageThumbnail ; GetThumbnail ( Works::Image 1 ; 100 ; 100 )

                    I return a question mark. However, if the image in container 'Image 1' is embedded rather than stored as reference, the image loads in the thumbnail container when this script is run.

                    Is it safe to say that this bug is not resolved in FM14? Any solutions?

                    • 7. Re: Image based database is very slow
                      philmodjunk

                      That situation doesn't seem to match what you are trying to do here.

                      The key detail:

                       GetThumbNail returns a ? instead of the expected image if the specified resolution is greater than that of the original image.

                      In your situation, you are supposed to be creating thumbnails with a resolution that  is LESS than that of the original image.

                      • 8. Re: Image based database is very slow
                        BenHough

                        Yes - I was confused by that part of the known bugs issue because for me it is on all image resizing (the thread attached to the know bugs entry is concerned with images with transparency in them - that is not the case with me either).

                        I don't know if you can recreate this on your own machine. I'm on Windows 10 with FM 14 Pro, and I am getting an error exactly as described:

                         GetThumbNail returns a ? instead of the expected image if the specified resolution is greater than that of the original image.

                        Except, as you say, the circumstance in bold is not true here.

                        I am going to test this in a new DB in several ways and will upload any test files if the issue persists.

                        Thanks

                        • 9. Re: Image based database is very slow
                          BenHough

                          Update -- 

                          I have tested this in isolation and the problem occurs when an image is stored by reference which sits on a networked drive rather than a local one.

                          I keep the images of art works on a NAS (as detailed above) and refernece them to a DB on my local drive. When a thumbnail request handles an image which is stored by reference on a NAS, it returns '?'

                          So I guess that is that, unless any solution can be thought of?

                          • 10. Re: Image based database is very slow
                            philmodjunk

                            I suggest that you write this up as a new bug report in Report an Issue.

                            But as a work around, you can use Insert Picture to insert the file referenced in your current container into a global field, embedding the image temporarily in that global container field. And now your use of GetThumbnail should work for you.

                            See this thread for an example file that has a calculation field that can extract a filepath from a container field where the file was inserted into the container field "by reference": Exploring the use of a $Path Variable in Scripts