image size frustration (warning: long)

[JackP]

I work for a University, and I have a client who has a FileMaker database with about 750 records. Each record has a picture. While the client was using the database locally, she was storing references to the images, and all was well.

Then she decided that she wanted to host the db on FileMaker Server (my department). She wanted to be able to see the images in:

1. FileMaker instant web publishing (on our Unlimited box)

2. Through the FileMaker interface when opening remotely off the Server box.

She also needs to occasionally take a copy of the database out into the field on her laptop, far from internet access, to gather new data. She would then update the version on our Server box with the new info.

Problem: we can't store images by reference and accomplish her goals. For one thing, our Server and Unlimited boxen are Windows, while her laptop is a Mac. Forgive me if I'm wrong, but doesn't FileMaker use absolute paths? Also, her collaborators (in other countries) need to be able to see the images through the FileMaker interface when opening remotely, and she can't predict what machine they'll be on at any given moment.

So, that leaves the option of storing the images in the db instead of references. There's only one problem: after importing the images, the database is over 800MB. The database and the images fit handily on a single Zip disk, back in the good old days of storing by reference. These images are all around 100k jpegs, and they appear to be expanding by a factor of 10 when imported directly into the db.

This kills the deal... when the client's colleague in Germany tried to open the database remotely, it took several minutes to switch from one record to another... presumably because FileMaker had to download about a megabyte of image data to display each record.

Does anybody have any suggestions for me at this point? I've looked for plugins to help me, but to no avail. It seems that image importing should not be this problematic. Is there a way to store images in the database that doesn't suck? I've looked for plugins to help with this, but to no avail. I can't understand why this happens in the first place, frankly.

An awesome solution would be if I could store a reference to the file location, but have that file location be a URL. Then I could store the images on a webserver and not worry about the size of the database.

I sincerely hope someone can point out a solution to this that I have missed!

Thanks,

Jack Pinette

[LiveOak]

Sound like the most flexible solution is to store images in the FM file. Chances are that the images being stored are at a much higher resolution than is required for screen viewing. Using larger than needed images makes the operation slow even using references, as FM has to render a downsample on the fly. Storing larger than needed images within FM just eats up disk space.

One option is to downsample all the images to the size required at 72 dpi screen resolution. If a standard size thumbnail will server (128x128, etc.) you can use the Troi-File plug-in to create thumbnails directly into FM.

We are working on an image storage system for one client with a 200,000 image capability. We are using 1) 128x128 thumbnails in FM 2) 75 dpi referenced images and 3) 300 dpi referenced images in different places to provide both navigation speed and higher resolution, as needed.

-bd

[JackP]

Thanks, LiveOak.

I was really hoping not to have to work with multiple copies of the images, but it looks like that may be necessary. I'll look into storing thumbs in the db. Maybe I'll toss the originals on a webserver and have a button to jump to the appropriate URL.

[LiveOak]

In the databases we've done, image storage for FM to FM access and Web access are treated as separate issues. On the web/Lasso side, images are stores external to FM and not displayed using FM container fields. The only thing stored in FM for Lasso access is a reference in a text field.

On the FM to FM side, you can trade off the need to use both thumbnails and container fields with references against just using a larger thumbnail.

-bd

[Steven H. Blackwell]

quote:

---

Originally posted by Jack Pinette:

There's only one problem: after importing the images, the database is over 800MB. The database and the images fit handily on a single Zip disk, back in the good old days of storing by reference. These images are all around 100k jpegs, and they appear to be expanding by a factor of 10 when imported directly into the db.

[/QB]

---

Under preferences--> turn OFF "Store Compatible Graphics". This stores both the original jpeg and a PICT copy as well. BTW, you have to do this BEFORE importing, it will not affect the files already imported.

HTH

Old Advance Man

[Partha]

Hi,

Don't know how helpful this will be, but I took a round-about way to solve the same problem.

Set all the JPEGs on a system with a Web Server software under their specific folders.

To open them from clients, I just used the "Open URL" command of FM Pro.

Rgds, Partha