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. Digilib will probably be used for image handling within the eSciDoc infrastructure and some of the envisioned solutions.

Current Functionalities[edit]

Following functionalities are provided by Digilib:

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 UML (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 Digilib. For high resolution pictures, jpg works best.
Several frontends (layout) are available.

Following functionalities are planned for the development of Digilib (by MPI WG):

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 eSciDoc Solutions[edit]

This section describes the requirements to Digilib resulting from the functional specifications of the eSciDoc solutions.

Faces[edit]

General Information

Every picture (2052) exists in three formats (thumbnail, web resolution, original resolution).
The pictures are in a Digilib 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[edit]

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 (FIZ)[edit]

This section covers technical aspects of Digilib.

In general, Digilib 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 eSciDoc infrastructure.

Current Status[edit]

Frontend[edit]

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

Backend[edit]

Digilib's integration in the eSciDoc architecture could be realized as Fedora Disseminator. Disseminators are Webservices with access to a HTTP stream instead of Digilib's direct file access. Digilib is to alter to operate with HTTP streams.

The direct file access is, with the used Java Advanced Imaging API (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 Digilib's image transformations with random files access. This is, without special functions or libraries, not directly given via HTTP streams. If random file access on HTTP 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 TIFF format (with tile structure) to ensure memory saving and fast processing. Which eSciDoc 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 eSciDoc-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 Digilib. Caching.

Storage of Parameter and Annotation[edit]

Digilib parameters are part of the URL. The consequence is that these parameter are still part of the framework based URL ( e.g. http://escidoc/ir/item/<itemId>/content/<contentId>?param1=value1&param2=value2 ).

The annotations and transformation parameter are handled not as eSciDoc dataset. Should Digilib 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[edit]

Special interest group (SIG)?
known interested institutes/organisations:
- KHI Florenz
- BBAW
- DTA
- Bibliotheca Hertziana

Digilib

Contents