Digilib
Digilib will probably be used for image handling within the eSciDoc infrastructure and some of the envisioned solutions. 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 (https://uio.dev.java.net/) 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¶m2=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?