Meeting: May 1, 2017
Currently, DRS only supports the RGB color space for JPEG2000 images. Some Harvard repositories are using other valid color spaces, such as YCC, so they have to then transform/retrofit the image for deposit into DRS. DRS needs to support more than just RGB.
From the perspective of someone not already familiar with delivery technologies, it can be difficult to understand the differentiation between sequenced objects (texts, atlases, etc.) and still images. Librarians report that PDS and IDS are often conflated. JT: Resulting question being: what advantage is there to using a different interface for IDS and PDS when Mirador (current PDS) can be used for still images?
PDS offers a PDF download. IDS should also provide a save/download option. Ideally, the interface for save/download should provide information that allows the user to make an informed decision about whether to initiate a download and the available options. For example, Universal Viewer has a menu that displays all available versions of an image for download, including the file format and file size. File quality or resolution would also help users select the appropriate file.
DRS and delivery systems need to support right to left scripts. For PDS objects, that includes sequencing in the other direction. For IDS, if we display metadata and that metadata is in an RTL language, it should display properly. Randy seemed to believe that this would require a change to the DRS data model that would indicate RTL/LTR.
Repositories have different policies regarding the download of full resolution images, even when those images are not restricted. Some repositories want all requests for those files to go through the DIG. For other repositories, the occasional requests are easier to handle on a case by case basis – often fulfilling requests locally. Those repositories may wish to make all or some unrestricted full resolution images available for download by the end user so that the repository does not need to mediate. There appeared to be agreement on the idea that all unrestricted content should be assigned a single policy and that each repository should be able to change that setting for its images based on their local policies. For example, we may decide that all unrestricted images are by default downloadable, but the Law Library should be able to mark some or all of its unrestricted images as NOT downloadable.
The Map Collection receives many requests for high resolution versions of images from its collection. The requests are often for a part of an image rather than the entire image. Frequently, the requests are for embedding that portion of the image, so being able to specify part of an image and then embed that elsewhere would help Maps.
IDS needs to provide rights information (I think the implication was also that the information needs to be human readable). Library of Congress handles this well. Found these two examples:
Image format can be an issue for download, because many users cannot open a JP2 or even a TIFF. Repositories are having to send out instructions or they save the image as a JPEG before sending it to the requester. If IDS provides downloading, it should include a format that can be opened without special software.
IDS should allow users to compare images by placing them side by side or tiling them.
Another issue with the distinction between PDS and IDS is that it isn’t always evident which is the best content model for the digitized item, especially for sequenced images of items that are only two or three pages. The Map Collection has images with multiple sheets and images that are then stitched together. If using PDS, the Map Collection has to impose an order to the individual images that may not be useful to the researcher. If IDS can display multiple images simultaneously, the user should be able to organize and order the images as needed.
When printing an image from IDS, the citation should be appended as it is in PDS. Note: PDS has a repository and local identifier, not a citation. Which is preferable?
In DRS2, the image files are part of the larger context of a still image object content model. The new IDS should take advantage of the additional features potentially made possible through the relationship of the image file and its object, especially the existence of descriptive metadata.
Configurable display of metadata would be desirable. The image delivery API syntax should allow the repository to choose which fields to display and or not. If it is flexible enough, that should address the potential problem of a metadata mismatch (where IDS displays metadata in a larger context of a system that draws on metadata sources other than DRS). Some specific settings would include whether or not to display a METS label or MODS-based label as well as some technical metadata fields.
The color profile needs to be downloaded with the image, this has been an on-going problem for the museums. After being downloaded, the images display incorrectly because the color profile isn’t available.
The scale of images is important. Providing the pixel dimensions or magnification level would provide some perspective on the original size (of the digital image or the analog object?)
Newer technologies should be supported, including smaller screen sizes, mobile, touch screens, etc. IDS should be prepared to keep pace with future developments, so that expected interaction methods are supported. Users expect certain behaviors.
Ability to associate actionable geospatial coordinates is desirable. Or, at least listing the coordinates associated with a raster image.
The Law Library is working with ALTO (XML) data for simulated highlighting of raster images.