Support TIFFs on WMF wikis
Closed, ResolvedPublic

Description

From #mediawiki in January:

<GerardM-> Brion, why do we not support tiff files ?
<GerardM-> this would make a big difference for the image restoration projects
<brion> GerardM-: i think we haven't quite got round to it. tiffs are a bit complicated in that it's a meta-format with many possible actual encodings
<brion> check if there's an extension for it already in the works and plop it on my queue to look at :)
<GerardM-> it prevents the restorations to be taken seriously by people outside or WMF ... you can not repeat the work from compressed files
<GerardM-> Brion, at the start of the fundraiser, localisation software was written for the banner ..
<brion> yes, tiffs are great. :) i'm convinced -- just make sure that any existing extension or bug gets bumped and add me as CC

I can't find a bug filed regarding TIFF support, so I've filed this one and CC'd Brion.


Version: unspecified
Severity: enhancement
URL: http://meta.wikimedia.org/wiki/Restoration.wikimedia.org

bzimport set Reference to bz17714.
MZMcBride created this task.Via LegacyFeb 28 2009, 7:05 AM
bzimport added a comment.Via ConduitFeb 28 2009, 7:21 AM

HighInBC wrote:

This would be particularly useful as the Library of Congress keeps the high quality original scans in tiff format, it would be great to not have to convert them to jpg, or downsample them below 12.5 megapixel for png.

brion added a comment.Via ConduitMar 5 2009, 1:29 AM

Adding basic support for uploading TIFFs *without* inline rendering should be pretty easy, and sufficient for current needs (very large, high-quality source files, which will have smaller versions uploaded for online use).

Will want to test/confirm offline that file type verification is good before switching the config switch though.

bzimport added a comment.Via ConduitMar 5 2009, 1:47 AM

mike.lifeguard+bugs wrote:

(In reply to comment #2)

Adding basic support for uploading TIFFs *without* inline rendering should be
pretty easy, and sufficient for current needs (very large, high-quality source
files, which will have smaller versions uploaded for online use).

Yes, one would think that uploading smaller versions for viewing would be sensible. That is not a view shared by everyone, however: http://durova.blogspot.com/2009/02/failure-to-thumbnail.html

bzimport added a comment.Via ConduitMar 13 2009, 4:34 PM

mdale wrote:

We could use something like VIPS http://www.vips.ecs.soton.ac.uk/ to render out thumbnails for very large images (including TIFFs) without loading the whole image into memory.

Also I highly recommend we send out the http "attachment" header when passing links to those high res images. They crash most systems/browsers. So we should only let people "download" the image. ( Instead of linking for in-browser display. ) Not everyone intuitively will know to right click on the image to save target as.

bzimport added a comment.Via ConduitMar 13 2009, 4:54 PM

mdale wrote:

also see command line usage cpu / memory / speed comparisons:
http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use

brion added a comment.Via ConduitMar 16 2009, 10:13 PM

Set on test & commons with currently no native thumb support.

Threw together some quick experimental support in r48462 -- once synced this will allow the image width/height to be recorded properly and exif metadata shown, and optionally thumbnailing for images not exceeding the max image size for thumbing.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.