Tilepic Sometimes Makes Huge Files

robc

Is there any way to improve the efficiency of displaying JPG files that have large dimensions?

For example, I upload a 5 MB file that's JPG compressed and represents something like 30 to 70 megapixels. The tilepic system will generate nearly 1 GB of data, when all I really want to do is view the original file.

Would it be possible to disable tilepic only for JPG media? I still prefer to use tilepic where large TIF media would take too long to download.

monica

Have a look in media_processing.conf. This controls what is created for each file type and what the default view version is.

JPG and TIFF are bundled together under the Image MEDIA_TYPES by default, but you can create a separate MEDIA_TYPE to process JPG and potentially other lossy formats like PNG etc. Just copy the image block and edit it as you need for JPG, then point the JPG format type (under MEDIA_ACCEPT) to the new type you have created.

This also contains all the settings for the size/quality of the derivatives that are created.

robc

I'll have to experiment with that. I tried changing only the media_display.conf file in pawtucket and that didn't work by itself.

robc

I think the pawtucket config is taking effect, but the UniversalViewer is requesting the path to the original media followed by /info.json and the Apache 404 message is being returned instead of rewriting to index.php. I'll have to check some higher level configs.

robc

Yeah this is a mess here and it's not Apache's fault. Even if I force it to rewrite the media path with /info.json on the end into index.php then pawtucket just says View does not exist.

robc

Another part of the problem ...

https://providence.readthedocs.io/en/latest/providenceConfiguration/mainConfiguration/media_processing.conf.html

The SCALE operation doesn't have a shrink-only mode. All four existing modes use a fixed size value, so there's no way to say "make this image no more than 3000 px wide".

It looks like this system just isn't flexible enough to do what I was hoping for.

robc

Current workaround was to delete the unwanted representation(s), resize the JPG and upload it for display, then ZIP the original and upload it for archive purposes.

jeffschneider

This thread is pretty relevant. I followed the steps in the last post and it works well

https://support.collectiveaccess.org/d/300487-300487/4

robc

Yeah I had read that one but I don't know which viewer they were using. I'm relying on UniversalViewer for touch support. As long as it's incompatible with the "original" media I will need a different solution.

Also, when I tested the original JPG from disk into Chrome, the load time was horrendous. So the workaround where I display a manually-resized version in tilepic format and then attach a ZIP, it works out relatively nicely.

robc

One of the properties mentioned in the docs is called no_upsampling. Does anyone here know what that would do or if it would be helpful here?