We successfully upload both .tif and .jpg files to the Dropbox plugin and then and associate the files with items in our Omeka databases. Once associated with an item, the files get transferred to our Amazon S3 account as expected and desired.
Once uploaded, the public pages show the following error for .tif files: Sorry, we were unable to find the document at the original source. Verify that the document still exists. This error does not occur with .jpg files. This appears to be a 'bug' with .tif file handling.
It's hard to say if this is an Omeka issue since there is an AS3 account involved in the mix.
Are the files stored in the "archive" directory on the same server as the Omeka installation or have you rerouted this someone how? Omeka may not know where to find them.
Are you using the Google Docs Viewer or something similar to display the TIF files?
That message doesn't sound like anything normally produced by either Omeka or S3.
What we know is the following:
1) We upload a file into 'Dropbox', i.e. ~/web/omeka/plugins/Dropbox/files/original_filename.tif (or .jpg as the case may be) on our web server.
2) When we do the 'upload from Dropbox' routine in the Omeka application to bring the item in as 'a new item', several things happen:
2.1) The original file is renamed to a long hex representation and then copied into the 'files' directory of our S3 bucket. This is precisely the same behaviour that we experience if we keep files onto the web server described in (1) above. Except for the file name, there is no apparent change to the file itself. File size, metadata as well as the name suffix (.tif or .jpg) remains intact.
2.2) A somewhat reduced sized copy of the file is renamed to the same hex representation as seen in 2.1 above and copied into the 'fullsize' directory of our S3 bucket. The file format is converted from .tif to .jpg. Every file in the 'fullsize' directory is .jpg, whether or not the original source was .tif or .jpg. (These files are easily readable, they are in no way corrupted for display.)
2.3 A very reduced sized copy of the file is renamed to the same hex representation as seen above and copied into the 'square thumbnails' directory in .jpg format.
2.4 A reduced copy (smaller than 'fullsize' and larger than 'square thumbnail' is renamed to the hex representation seen above and copied into the 'thumbnails' directory in .jpg format.
2.5 The original file is cleared from the ~/web/omeka/plugins/Dropbox/files directory on our web server.
The above behaviour is completely expected.
My suspicion is that the Omeka 'public' pages fetch their display images from the 'fullsize', 'square thumbnail' and 'thumbnail' directories as needed. When the original file has .tif format, Omeka is not recognizing the presence of the .jpg files for display. There appears to be a disconnect brought to bear by the change in the file name suffix.
I view the .TIF files using a variety of viewers including 'eye of gnome', 'shotwell', 'GIMP' as well as through the Firefox browser. The .tif files are uncompressed. I am not familiar with 'Google Docs Viewer'.
I'm asking about the DocsViewer plugin for Omeka, which uses Google Docs to display some files on item pages.
The error message you're mentioning comes from Google, not from Omeka or Amazon.
How big are these tiff files? When you start getting up into the tens of megabytes, Google Docs often doesn't work as well.
If you want to always use the JPG thumbnails and "fullsize" images, you could use the item_thumbnail or item_fullsize functions.
The DocsViewer for Omeka is indeed based on Google Docs.
Yes, tracing the code suggests that the Google generates the error message.
The .tif files are about 10 MiB. I have since experimented with various .tif file formats: .tif uncompressed, .tif with JPEG compression and .tif with LZW compression. These compression methods produce files ranging from 2 MiB to 10 MiB in size. I get the same error through Omeka on all of the .tif file types. The error does not occur when using .jpg or .png file types.
"If you want to always use ... item_thumbnail or item_fullsize functions."
The documentation for these functions suggest they could be called from within an 'items/show.php' page. There are at least three such pages in our installation. I am not familiar enough with the Omeka coding to determine from where the function calls be made.
Do you have any advice on where to insert the item_fullsize/item_thumbnails code?
Thanks in advance for your help.