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 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>

peter green schrieb: We have acutally discussed this for TIFFs, it's an optional feature in the spec. I can't promise that we'll get it, but it would make sense, and shouldn't be hard to add even if it's not included in the first iteration. -- daniel

John Vandenberg, 12/09/2009 01:23: Even with DjVu, the 100 MB limit is often too low: how can TIFF be useful with multi-paged huge documents? Nemo

On Sat, Sep 12, 2009 at 8:41 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com>wrote;wrote: years yet at least :-) And, even then, TIFF files will be in the minority relative to JPG. *but* what makes supporting the TIFF format so important for the purposes of working with museums and galleries is that it demonstrates that we can do very good work (and take professional care of) their high quality images. If we can only support compressed formats then the museums and galleries can quite legitimately ask us why would we want high-res files. At that point it returns us to arguing over pixel-widths... So, not only is supporting lossless file formats good for WikiSource texts and good for image restorationists, it is also good for our future negotiations with museums and galleries. So, keep up the good work guys! -- wittylama.com/blog Peace, love & metadata

Hoi, John you are right. TIFF can be everything you describe. The question I am left with what is your point to this? Material is scanned without compression by GLAM, we get it per standard as TIFF files, we restore them. When the material is compressed, we do not restore them. We need to retain the original to demonstrate provenance. It is problematic to have files nobody can see in a standard way. This is why we need TIFF support, because otherwise we are likely find an admin who starts deleting this essential material. Thanks, GerardM 2009/9/13 John Vandenberg <jayvdb(a)gmail.com>

Hoi, Remember the archive of Cologne? It collapsed. When we have as a policy to have the exact files on Commons as provided by a GLAM, we prove provenance because our best practice is to include the material in our archive as provided by a GLAM. When we decide for all kinds of reasons to transcode it to another format we can and should when it makes sense. It makes sense as long as we keep the original. Your point that we do not need to have the original copy is wrong. Keeping the original files as a best practice and an important practice was confirmed in all the dealings I have had with many GLAMS. Thanks, GerardM 2009/9/13 John Vandenberg <jayvdb(a)gmail.com>

Hoi, The archive of Cologne was a state of the art archive in Germany. If anything it was the kind of institution that people would donate collections to because of its excellent reputation and practices. A similar story happened to an archive in Theresienstadt if I remember well. Cologne collapsed because of an accident with an underground that was dug, Theresienstadt saw its collection disappear in flames. We are not an archive. But our best efforts help safeguard against the total loss of an archive. We can be complementary to what our partners do. We should not think so insular. Thanks, GerardM 2009/9/13 John Vandenberg <jayvdb(a)gmail.com>

2009/9/13 John Vandenberg <jayvdb(a)gmail.com>om>: No indeed. However, it certainly doesn't hurt and archival copies of this stuff is certainly within our remit. (Though the Internet Archive are freer on what licenses they accept and will gleefully accept archives of just about anything.) - d.

On Sat, Sep 12, 2009 at 7:31 PM, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote: People say "archives", but do not recognise or care that archives consist primarily of *text*. -- John Vandenberg

Federico Leva (Nemo) schrieb: I don't think we'll see very many huge TIFF files. But generally, uploading very large files is possible by doing a server side import. Setting up a process for this, and perhaps some nice tools, is something I have been thinking about. perhaps we'll offer a contract for that next year :) -- daniel

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

Platonides schrieb: I didn't check for myself, but that'S what I was told when we discussed this matter with Brion and Mark at FOSDEM. And yes, it's utterly stupid. But that doesn't mean PHP won't do it. Yes, that sounds pretty nice. -- daniel

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