Forums » problems uploading 16-bit TIFFs

RSS feed for this topic

Info

  1. delevinson Posted 2 years ago

    Hi,
    A few weeks ago we started to have 'file not found problems' when uploading 16-bit TIFFs that are more than approx. 25 MB. In the archive directory, the TIFF is stored in the files subdirectory, but the fullsize subdirectory gets two jpgs with garbled file names. Same thing happens in thumbnails and square_thumbnails.

    For example, I upload test1-16bit.tif. In files is test1-16bit_1ffe127e39.tif
    In fullsize is test1-16bit_1ffe127e39-0.jpg and test1-16bit_1ffe127e39-1.jpg.

    The URL returned by Omeka for the item is http://learn.lakeforest.edu/omeka/archive/fullsize/test1-16bit_1ffe127e39.jpg
    so I get a file not found.

    I don't have this problem with 16-bit TIFFs smaller than 25 MB. They upload just fine.

    This happens with the dropbox, and also when I upload directly into a new item (I adjusted my php.ini to allow uploads of large files). It seems like this problem started about the time of the Omeka 1.1 upgrade. Can anyone help? Thanks!

  2. wanderingwill (Omeka Dev Team) Posted 2 years ago

    Does this problem also occur for other large files besides TIFs?

    The weird looking strings on the end of the filenames are supposed to be there.

    Have you tried manually downloading the file using SFTP from your server and looking at the file? Maybe the file is not corrupt - maybe there is some permissions problem downloading it from the webserver.

    Let me know if this helps.

  3. delevinson Posted 2 years ago

    Thanks for your reply.

    I uploaded a 40 MB PDF and a 250 MB AIFF sound file into omeka. They opened just fine--no "file not found."

    I understand about the weird looking string at the end of my filenames. But after that, Omeka is adding the "-0" and "-1" in my example's filename, before the extensions. That's what is causing the 404.

  4. DaveLester Posted 2 years ago

    I wonder if there was a problem detecting the proper mime type when you uploaded the file. Try browsing your items in the admin panel, and view an item in where you've attached a tiff file. Click the filename listed under "View File Metadata", and tell me what Omeka lists as the Mime Type / Browser, Mime Type / OS, and File Type / OS. If these are empty or this info is wrong, then we may know the problem. If not, we'll keep looking.

  5. delevinson Posted 2 years ago

    The type metadata looks correct:
    Mime Type / Browser:
    image/tiff
    Mime Type / OS:
    regular file
    File Type / OS:
    TIFF image data, little-endian

    This is the same as for a tiff which successfully uploaded.

  6. DaveLester Posted 2 years ago

    When you say that you're uploading files, do you mean through the regular administrative interface of Omeka, or are you using the Dropbox plugin? Is it possible that your server is timing out or limiting the file sizes that you're POSTing via HTTP.. resulting in these errors?

    If you can, try out the Dropbox plugin and let us know if the problem persists.

  7. delevinson Posted 2 years ago

    It's doing this both when I upload directly into a new item (I adjusted my php.ini to allow uploads of large files) and with the dropbox.

    My first project created a lot of 8-bit greyscale TIFFs of less than 20 MB, so we never came across this problem. My second project is a group of color 8 1/2 x 11 inch pages, which generate larger files.

  8. delevinson Posted 1 year ago

    I tracked down the error. My scanner driver (SilverFast) was creating a multipart TIFFs for each scan. SilverFast's HiRePP feature embeds a low-resolution copy of the scan as a subfile in the TIFF to aid with opening very large files.

    ImageMagick's convert application extracts both subfiles from the TIFF in the dropbox, and makes two separate JPEGs out of them, with -0 and -1 added to the end of the filenames. Omeka is expecting to find a JPEG with the original name only, so it presents a 'file not found' message.

    I turned off the HiRePP feature, and my images are working fine now.

Reply

You must log in to post.