Digilib

From MPDLMediaWiki
Jump to: navigation, search

Digilib is an web based client/server technology for viewing and working with images. This open source software was jointly developed by the Max-Planck-Institute for the History of Science (MPI WG), the University of Bern and others. DigilibWeb Based Server Technology for Viewing and Working with Images will probably be used for image handling within the eSciDocEnhanced Scientific Documentation infrastructure and some of the envisioned solutions.


Current Functionalities

Following functionalities are provided by DigilibWeb Based Server Technology for Viewing and Working with Images:

  • Zooming functionality (zooming in, zooming out, framing of a zoom area, switching back to see the whole picture, left, right, up and down navigation within the zoomed in picture)
  • Setting of maximal 10 marks per picture, which will be transfered to the UMLUnified Modeling Language (this marks will be saved in the form of coordinates, not pixels)
  • "Original Size" functionality: The user has to measure his monitor. On this basis, the original size of the picture content will be displayed. This enables an impression of the real size of the photographed object.
  • "Look up Table" functionality: The colors of the pictures can be changed to make the content more precisely. This is related to the "Negativ" functionality.
  • A user interface for the creation of structural markups for a picture (e.g the linking from a special point in one picture to another picture). This functionality was used for the Einstein Exhibition. The navigational arrows represent links between different pictures.
  • Data formats: Currently, tiff, png and jpg will be supported by DigilibWeb Based Server Technology for Viewing and Working with Images. For high resolution pictures, jpg works best.
  • Several frontends (layout) are available.

Following functionalities are planned for the development of DigilibWeb Based Server Technology for Viewing and Working with Images (by MPIMax-Planck-Institut WGWork Group):

  • A thumbnail next to the picture, which shows an overview of the picture
  • A "zoom ruler" like the one in Google Maps
  • A measuring unit within the picture
  • Persistent marks
  • Rework of the layout (frontend)

Requirements for eSciDocEnhanced Scientific Documentation Solutions

This section describes the requirements to DigilibWeb Based Server Technology for Viewing and Working with Images resulting from the functional specifications of the eSciDocEnhanced Scientific Documentation solutions.

Faces

General Information

  • Every picture (2052) exists in three formats (thumbnail, web resolution, original resolution).
  • The pictures are in a DigilibWeb Based Server Technology for Viewing and Working with Images compatible format (jpg), therefore no conversion is needed.

Requirements

  • Zooming in, zooming out, switching back to see the whole picture
  • Left, right, up and down navigation within a zoomed picture


ViRR: Virtueller Raum Reichsrecht

Requirements

  • Zooming in, zooming out, switching back to see the whole picture
  • Left, right, up and down navigation within a zoomed picture
  • "View negative" functionality
  • Dynamic creation of a "identification stamp" (Herkunftsnachweis) on all pictures in the "detailed view" (also after zooming)

Technical Details (FIZFachinformationszentrum Karlsruhe)

This section covers technical aspects of DigilibWeb Based Server Technology for Viewing and Working with Images.

In general, DigilibWeb Based Server Technology for Viewing and Working with Images can be seen as a combination of server-based business logic (image manipulation) and browser-based UI components. The idea is to integrate the server-based part of the software as intermediate service within the eSciDocEnhanced Scientific Documentation infrastructure.


Current Status

Frontend

The user interface is to integrate in the application (PubManPublication Management/Faces). I haven't tested this part. The current functionality is browser based and so I expecting minimal changes.

Backend

DigilibWeb Based Server Technology for Viewing and Working with Images's integration in the eSciDocEnhanced Scientific Documentation architecture could be realized as FedoraFlexible Extensible Digital Object Repository Architecture Disseminator. Disseminators are Webservices with access to a HTTPHyperText Transfer Protocol stream instead of DigilibWeb Based Server Technology for Viewing and Working with Images's direct file access. DigilibWeb Based Server Technology for Viewing and Working with Images is to alter to operate with HTTPHyperText Transfer Protocol streams.

The direct file access is, with the used Java Advanced Imaging APIApplication Programming Interface (JAI), easy to replace against a network access method. These methods produce a BufferedImage, which may lead to higher memory requirements. It is to probe if the buffered images method influences the rendering speed dramatically.

Currently operate DigilibWeb Based Server Technology for Viewing and Working with Images's image transformations with random files access. This is, without special functions or libraries, not directly given via HTTPHyperText Transfer Protocol streams. If random file access on HTTPHyperText Transfer Protocol stream is a requirement for fast image transformation than could the unified IO library bring speed up. For non-complex image transformations, like scaling and clipping on standard sized images (5 MiB), is this not necessary.

Huge images should be stored in TIFFTagged Image File Format format (with tile structure) to ensure memory saving and fast processing. Which eSciDocEnhanced Scientific Documentation part is responsible that the image processing could be done on tiled, tiff-formated images? For Faces should it be simple to ingest the 200 images in the corresponding format. For other eSciDocEnhanced Scientific Documentation-Solutions an automatic image format conversion might be possible (where the original is kept). How can we ensure that additionally image formats are only stored if image transformation is really needed (otherwise we waste the storage needless)? Which types of one image should be stored in repository: original image, thumbnail, tiled-tiff?

Open: Parameter transport from Solution through Framework to DigilibWeb Based Server Technology for Viewing and Working with Images. Caching.

Storage of Parameter and Annotation

DigilibWeb Based Server Technology for Viewing and Working with Images parameters are part of the URLUniform Resource Locator. The consequence is that these parameter are still part of the framework based URLUniform Resource Locator ( e.g. http://escidoc/ir/item/<itemId>/content/<contentId>?param1=value1&param2=value2 ).

The annotations and transformation parameter are handled not as eSciDocEnhanced Scientific Documentation dataset. Should DigilibWeb Based Server Technology for Viewing and Working with Images parameters be stored in the properties or metadata of binary content? What would be the best way to hold different annotations for one image?

Interests in further development

  • Special interest group (SIG)?
  • known interested institutes/organisations:
    • KHIKunsthistorisches Institut, Rom Florenz
    • BBAWBerlin-Brandenburgische Akademie der Wissenschaften
    • DTADeutsches Textarchiv
    • Bibliotheca Hertziana