Can you explain more fully why you are doing this?
Why a separate database?
Why on a different drive? (I can see why you might use a dedicated drive for the image files, but why put the database on a separate drive?)
What version of FileMaker are you using? (FileMaker 12 introduced some new features for working with container fields)
The idea was that this would be a seperate database that would hold images that are of the quality needed for: publications OR to be used on a website.
When consulting our IT people before starting this project (they are contracted to us) they suggested placing the images and new database on this drive (which is actually the same drive that the Old Large database is stored on??)
I don't know that it has to be seperate but that was the original thought, maybe so we wouldn't slow down the use of the Old Large database when looking through the large TIFF/JPEG files (I plan on creating buttons that download these images to staff computers)
We have version 12.
If both sets of files are located on partitions of the same drive, I don't see how that will significantly improve performance. The same hardware has to read/write the data from the same storage media. Putting such a DB on a completely different computer server, on the other hand, could keep the "load" from accessing a very high resolution image from adversely affecting response times for other users using your original database.
You may want ask your IT folks to explain the reasoning behind their suggested change in greater detail.
I would suggest that very high resolutions images be treated carefully whether or not you move them to the control of a separate database file. (Though images for hard copy publication typically require far higher resolution than those to publish to the web.)
A single artwork record can link to a table of multiple image records--each with a different container field that references a different artwork file for the same artwork--providing support for both high and low resolution images. And then you can limit access to the records for Hi Res images to just those users or tasks that require it. Those users that are currently just browsing a catalog of images can be presented with much smaller "thumbnails" of the images.
Given that you have FileMaker 12, you can use externally stored container fields to hold references to your image files and you can use the GetThumbnail function to produce lower res copies of existing images if you have the need for such in your database.
Could you explain this more?
"Given that you have FileMaker 12, you can use externally stored container fields to hold references to your image files and you can use the GetThumbnail function to produce lower res copies of existing images if you have the need for such in your database."
If I am understanding the above statement, we wouldn't need a new db/table, but a new layout that would hold thumbnail reference images to the large jpegs/tiffs via the GetTumbnail function?
Not quite. I don't know how your current database is designed so specific descriptions of what to do may not fit your actual database.
You can set up this data model:
Artworks::__pkArtworkID = Images::_fkArtworkID
A container field in Images can store a reference (via External Storage) to single image file for that artwork, but you can 2, 3 or even more such Image records and the image resolution of the file referenced in each such image record can be different. An added field in Images can identify whether the image is hi res or lo res. Then you can use filtered portals or added relationships that only match to one type of image or another to selectively display either a hi res or lo res image for that artwork.
GetThumbNail is a function that you can use in a script to generate lower res copies of existing image files if you need to be able to do that.
Would it be possible to store the jpegs/tiffs as a refernce in the container field in this 'High Res Image' layout? Would THAT cut down on loading time, storage, etc? Would the user be able to see an the image/jpeg/tiff in the layout if stored as a reference?
IF stored as a reference is it possible to export image (using a button) to the user's desktop?
I would recommend that all of your images, Hi and Lo res, be either inserted "by reference" or inserted into a container field with external storage specified.
Either method stores only a reference to the file in the container field.
when you say "external storage specified", do you mean store images elsewhere on my computer?
which I do, but I have never checked the "store as a reference" option when placing images in the db. (my process is: right click-insert image in the specified container field-and browse untill i find my image in my images folder).
If is start inserting images "by reference" can I still create a button that has a script on it so the user can download that image on to their desktop?
External Storage is a new option first introduced in FileMaker 12. It allows for some simpler options for dealing with referenced image files in a container. I suggest that you look up this term in FileMaker help to learn more about it than I care to copy and paste from the help system to this forum.
"store a reference" is the original option for only inserting the file path to a file located elsewhere (can be anywhere on your network).
External storage is different and is not used with that check box selected when inserting images. In it, files are copied from the container field into which it was inserted to a specified storage location and then the container field is updated to replace that copy in the container field with a reference to the copy now placed in the specified storage location.
which I do, but I have never checked the "store as a reference" option when placing images in the db.
Then your current design does NOT store a reference to those image files. Instead, you have a physical copy of the file stored inside the database. This is NOT what I recommend for a database for managing large numbers of images.