New #graphics developments for #MediaWiki

There are two significant developments, one does improve the use of graphics on mobile phones, the other suggests an alternative to the Djatoka software.

I learned from Hampton that improved graphics are now available on the Mobile. A picture fills the screen completely and, it is then up to the user if he wants even higher resolution.

What Daniel Schwen announced is really interesting, let me quote his mail..

Hey,
inspired by the Djakota postig I whipped up a little wrapper around IIP [1] and VIPS [2]. It is basically the same think as Djakota, but as a compiled fast-cgi program (rather than Java).

A couple of examples:
http://toolserver.org/~dschwen/iip/wip.php?f=LC-39_Observation_gantry_pano.jpg
http://toolserver.org/~dschwen/iip/wip.php?f=Chicago.jpg
http://toolserver.org/~dschwen/iip/wip.php?f=Seattle_7.jpg

The examples use a flash viewer, but you can append &flash=no to the urls to get a Javascript viewer.

It should work to replace the names with arbitrary images on commons, but new images will have to be processed into a pyramidal tiled tiff image (with jpg compression) first. That takes time, about a minute. After that the image is cached and the viewer appears immediately. Be warned, there is no visual feedback that anything is happening while the image is processed. So be patient and try a reload after waiting a minute or so.

I'll write a gadget to integrate this into commons (the gadget will only appear on images with a certain minimum size).

Best,
Dschwen

[1] http://iipimage.sourceforge.net/
[2] http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS

The important thing is that new exciting functionality becomes available. Many of the issues that have been solved with Djatoka may find their way into this approach.. Particularly caching is important maybe even pre-processing; you do not want to have the servers prepare a view at the peak of traffic.

If this is not enough, the discussion on Commons-l is discussing what can be done to give this approach more functionality..
Thanks,
GerardM

#Djatoka to focus in on a scanned #newspaper

When you make an archive of newspapers digitally available, it can involve two things: scanning the paper and optical character recognition (OCR) of the text. Scanning is already a big job, performing a quality OCR is an even bigger job and often prohibitively expensive.

A scanned newspaper page consists of multiple articles, their start can be relatively easy be recognised and, with a bit of programming these anchor points to the text can be recognised automatically. This would make the digital navigation of a scanned paper a lot easier.

When an article is identified as relevant by a user, it can be named. This allows for easy referencing. An OCR process can run on the text of the article and, the user can be asked to proofread the result. In this way the article gains usability as a resource.

An important part of such a workflow is that the underlying scanned newspaper is an essential part of the resource; not only does it provide the source material, it provides provenance when people can return to the original material and verify the veracity of what is digitally available.
Thanks,
GerardM

Indonesian story cloth there for you to enjoy

When Durova started her work on the Indonesian story cloth for the Tropenmuseum, we knew that we could not show it in all its glory on Commons. It is just too big. In real life it is 15 meters long, the TIFF is 992,4 MB.

Converting it to PNG would reduce its size. JPG compression would make it even smaller but the image would lose much of its appeal if it is to be reduced to less then 100 MB. At this size it would still be unmanageably big.

Djatoka in action

Enter Djatoka, this open source application provides you with the ability to view incredibly big files in a manageable way. I am really grateful to the Los Alamos National Laboratory for hosting the story cloth for us in Djatoka.

Have a look and, enjoy.
Thanks,
GerardM

Commons and mobile phones

In order to move the process for a strategy for the Wikimedia Foundation forward, there are the so called "strategic office planning hours". People discuss issues, progress.

We talked about the progress for mobile phone support and, it was said that Commons would be the obvious next candidate for mobile phone support. There are several issues that need to be addressed.

• traffic to and from mobiles is expensive
• there is no standardisation in screen size for mobile phones
• our current strategy of downloading the WHOLE picture to a mobile does not work

From this it is obvious that you want to send a picture that is optimised for a particular make of mobile phone and, when a user wants more detail then that, to zoom in and pan right, left up or down downloading the needed image data as required.

The Djatoka software provides such functionality. It is open source software and, as such it allows for great support for mobile phones. It would not only enable the use of Commons for the mobile phone, it would also improve the support of pictures for mobile Wikipedia.
Thanks,
      GerardM

Djatoka with Open Layers

Some of the pictures at Commons are huge. They take forever to load and they start loading at the top, typically not the most exciting part of a picture. It makes more sense to initially load a low resolution picture and download the higher resolution bits as and when required. This gives the average user a much more responsive experience. In this demonstration of the Djatoka software, you will find many pictures by Ansel Adams of the Japanese-American internment at Manzanar. The scaling of the pictures is done by Djatoka in combination with OpenLayers..

Thanks,

GerardM

How to present big files.

On Meta we proposed a project for the digital restoration of images. These images are typically public domain and they are often made available from a friendly archive. In the workflow of a restoration, there are several moments when a change is made that cannot be undone. When you work on restorations in a Wiki way, you have to save the work before such a change because this allows others to improve on them.

Images that are being restored may not be compressed because this introduces distortions that negate the restoration work. Once a restoration is completed, it may be compressed for use in Commons. For a normal illustration in a Wikipedia article compression is normal.

When you look at a really big picture, it can take quite some time before it is available to you; it slowly build from top to bottom. It is like watching paint dry. It makes more sense to start with an outline of the image and drill down for more details. Djatoka is open source software written by the Los Alamos National Laboratory that does exactly that. When I read its specifications, it makes me feel really entheausiastic. Have a look at this ox for instance.

So the next question is how do we make this functionality part of MediaWiki.
Thanks,
GerardM