On Fri, Sep 11, 2009 at 1:41 PM, David Gerard <dgerard(a)gmail.com> wrote: I don't suppose there's any easy way to use an automatic jpg thumbnail....... but only if the browser appears not to have an appropriate plug-in for displaying tiffs inline. —C.W.

On Fri, Sep 11, 2009 at 3:12 PM, David Gerard <dgerard(a)gmail.com> wrote: Could be feature creep but I was just thinking those few whose browsers do support tiff might for whatever reason prefer thumbnails which are in fact a scaled tiff. —C.W.

On Sat, Sep 12, 2009 at 6:08 AM, Charlotte Webb <charlottethewebb(a)gmail.com> wrote: The DjVu and PDF handlers provides thumbnails as jpgs. I would expect that the TIFF handler will also do this, otherwise it will not integrate with the Proofread Page extension. -- John Vandenberg

Hoi. The one reason why we need TIFF documents is because museums and archives typically store their digitised material as TIFF. When we receive digitised material from a partnering organisation the best way to get it is as a TIFF. Usually we get them as JPG but when we have a relation like with the Tropenmuseum where we can request a super high resolution TIFF for restoration. It is important to have this picture as a TIFF on Commons because in that way we maintain a link with the original material. In this way we also prove that the restoration is a best effort practice to make historical material into something that retains its authenticity but is useful as an illustration. Yes, 100MB is not big even for single paged documents. The biggest file we want to upload but cannot is over 600 Mb. Obviously they are a minority. Thanks, GerardM 2009/9/12 Federico Leva (Nemo) <nemowiki(a)gmail.com>

Gerard Meijssen, 12/09/2009 10:41: I know (all of us know), but John pointed out that TIFF is useful also for Wikisource. :-) Nemo

Charlotte Webb schrieb: I couldn't think of a good reason for wanting that. Direct access to the full TIFF, yes - but you have that by clicking through the description page to the file. That will trigger the browser's native rendering, just as with svg. I expect that for the things for wich you want native tiff support, you would want to have full resolution anyway. -- daniel

Hoi, The objectivehere is NOT to have PNG but to support TIFF. This is what gets us credibility with our partners. This is what gives us the provenance that we care about representing material as it has been given to us. In this urging the use of PNG in stead of TIFF is counter productive. Thanks, GerardM 2009/9/12 peter green <plugwash(a)p10link.net>

Daniel Kinzler wrote: Process? Tools? It would just be making a 'bigupload' right for people to bypass file size restrictions (or have a extremely high one). Then give it to sysops or a new group. The only thing is not to get those users uploading giantic files when storage nodes are getting out of space. It could even be automated so bigupload right would only be effective if there's at least X or X% free space on disk. Of course we would also need an interface able at least to continue interrupted uploads, to make it really useful. I did a proposal years ago based on a FTP upload interface. Maybe you are referring to something similar. Please keep me posted. Upload from URL and Firefogg should alleviate the issue, though.

On Sat, Sep 12, 2009 at 6:52 PM, Liam Wyatt <liamwyatt(a)gmail.com> wrote: Wrong. TIFF is a container format. The contents in a TIFF file can be compressed or uncompressed, losslessly or lossy. PNG/MNG is a container format. It can also have compressed or uncompressed, losslessly or lossy. DJVU and PDF can also contain compressed or uncompressed chunks, losslessly or lossy. TIFF support is good for future negotiations because it means that we don't need to argue with them about which file formats are better, or concern ourselves with the feasibility of transcoding large collections. -- John Vandenberg

On Sun, Sep 13, 2009 at 4:33 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: My point is that we *can* _losslessly_ transcode TIFF files to PNG/MNG. Provenance requires that we know where the original digitised copy is (an identifier), but we don't need to have a copy of the original TIFF if we have an PNG with the same quality. TIFF support means we don't need to worry about transcoding, or have fights about TIFF vs PNG vs PDF/A. That will be good, as it is a hurdle with working GLAMs, but it is not preventing high quality images or working with GLAMs, as transcoding is not a difficult process. The main problem at the moment is the upload limit. -- John Vandenberg

On Sun, Sep 13, 2009 at 7:57 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: We are not an archive. If an archive collapses, they should take care of the items in their positions, gifting them to someone else who can take them. If they don't, they are a very poor archive. -- John Vandenberg

On Sun, Sep 13, 2009 at 8:26 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: If they do not have proper archival practices (i.e. redundancy/tape backup), we should tell them about Internet Archive. It is insular to think we need to be the solution for problems we are not well prepared to solve. -- John Vandenberg

Platonides schrieb: Tell me if I'm wrong, but as far as I know, the file size is limited by PHP, nto by MediaWiki. And it has to be: if we would admit huge files to be uploaded before they are finally rejected by MediaWiki, this would already be an attack vector - because, afaik, PHP got the dumb idea of buffering uploads in RAM. So, to kill the server, just upload a 5GB file. If this worked, that would be cool. But as I said, afaik it's not possible, for technical reasons. That would be helpful. ALso helpful would be the ability to upload archive files containing multiple images. If we have a way to deal with uploading big files, this would become feasible. A relatively simple way would be to allow big files to be uploaded via FTP or any other protocol, to "dumb storage", and then transfer and import them server side. I'd propose a ticket system for this: people with a special right can generate a ticket good for uploading a one file, for instance. But it's just an idea so far. -- daniel

Daniel Kinzler schrieb: Really? It makes sense for text POSTs but it's not very smart for files... I was thinking on a FTP server where you log in with your wiki credentials and get to a private temporary folder. You can view pending files, delete, rename, append and create new ones (you can't read them though, to avoid being used as a sharing service). You are given a quota so you could upload a few large files or many small ones. Files get deleted after X time untouched. When you go to the page name it would have on the wiki there's a message reminding you of a pending upload an inviting you to finish it, where you get the normal upload fields. After transferring, the file gets public and you are returned the file size quota. Having a specific protocol for uploads also allow to store them directly on the storage nodes, instead of writing them via nfs from the apaches.

John Vandenberg, 13/09/2009 01:18: That's obvious, and [scanned] texts are more valuable than images, but precisely for this reason it's more difficult to manage them. We can relatively easily upload a bunch of images, tag and categorize them, use them in galleries and Wikipedia+Wikiquote articles, correct errors etc. Thus we are focusing on images "donations" which can give an immediate result. But what could we do with a bunch of scanned texts? (The only partnership here was the one of WM-FR with ENVT, if I remember correctly)? See http://strategy.wikimedia.org/wiki/Proposal:Make_Wikisource_scale I don't think that here the problem is file format: large transcoding is feasibile, see Internet Archive, where you can put in a huge PDF and download a wonderful DjVu: http://www.archive.org/details/VocabolarioAccademiciCruscaEd3Vol3 (they don't use TIFF, I suppose because it's disk space-demanding and they have already JPEG images), although they use non free commercial software. Nemo

Michael Dale schrieb: On a related note... have you looked at the AtomPub spec for uploading? I dodn't look too closely, but it seems worth considering. -- daniel

Michael Dale wrote: Not really an addition since I already mentioned them ;) Are the "1 MB POST chunks" just rfc2616 chunked transfer-coding applied to a POST body, or is it a custom protocol using several POSTs? There's a upload.txt file on docs/ but it's not any helpful.

Hello, Platonides wrote: Internet Archive has such a system, so it might worth asking them rather than reinventing hot water. http://www.archive.org/services/contrib-submit.php (for simpler cases), or http://www.us.archive.org/contrib_submit.php (for more complex ones) (Adding files to an existing item might make this a "more complex" case, requiring use of replacing=1 or update_mode=1.) Information on use of http://www.archive.org/services/contrib-submit.php is available at: http://www.archive.org/help/contrib-advanced.php and information on use of http://www.us.archive.org/contrib_submit.php is available at: http://www.us.archive.org/contrib_submit.php?help=1 Yann -- http://www.non-violence.org/ | Site collaboratif sur la non-violence http://www.forget-me.net/ | Alternatives sur le Net http://fr.wikisource.org/ | Bibliothèque libre http://wikilivres.info | Documents libres