ArchiumFilmCreator

Aus Digitabulum
Version vom 26. August 2011, 10:41 Uhr von KlausWendel (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Arche KlausWendel2008 400.png

Inhaltsverzeichnis

The need for creating a digital master film

Archium IPM afc testframes lo.png

Since there are many different file formats, there is a need to create a kind of digital master film from this vast variety of sources. This job is done by the archiumFilmCreator (afc), a rendering tool also used within the colour microfilming workflow of the German Federal Office of Civil Protection and Disaster Assistance (BBK). It is essential for this workflow tool to handle different types of data and to be able to combine these different data types on the common media.

Therefore each image is embedded into a container with a signal-coloured border. The three-parted structure of the border prevents misconceptions in the later re-digitisation workflow. There are three container types for images, text and digital data. Inside these containers are also some dynamically adjusted spaces for customers and systems meta data, located at the top (or optional at the bottom).

The challenges of digital image preparation

The scopes for design are manifold with the archiumFilmCreator

Strictly any image preparation is a kind of image manipulation and there are two major traps to care about: resizing and digital colour management.

Resizing in images-on-film workflow

Although it is altering data, resizing is much recommended to utilize the available space on film at best. However the way resizing is done is substantial. Vector images has to be resized by changing their density to enable a nearly lossless conversion to the final raster format of master film. Raster images may be resized with interpolation or – if enlarged with an integer factor – even without interpolation. Enlarging without interpolation is very similar to recording with a larger laser spot, meaning the image is enlarged without any loss of sharpness at the edges.

However the space utilization is restricted to only a few possible size steps. Any other kind of resizing has to be done by recalculation of the image size with an interpolation algorithm.

There is a round dozen of different algorithms for different purposes, and the system operator has to be aware if he is rendering photographs or technical drawings with the need of sharp edges.

While interpolation-free resizing does not enforce the alteration of color information at all, resizing with interpolation does also affect the behavior of digital color management.

Digital colour management in images-on-film workflow

For preparation of digital images a sophisticated colour management is essential. The rendering software has to take care for any possible colourspace information and has to convert it to the common colourspace of master film. Not only different RGB colour profiles are applicable, CYMK and Lab-colourspaces are convertible as well. The operator also should keep in view the rendering intent, since there are always different objectives for reinterpreting a colour information from a different sized colourspace.

Optimum space utilization by nesting

Even scaled to twice size, most images are still much smaller than the available space per frame in pixels on film. Therefore several images can be combined by customizable nesting modes to share the available space per frame. An almost unlimited number of different nesting modes -- symmetric ordered as well as asymmetric encapsulated modes are freely customizable.

Challenges of including text?

Well, including text is indeed a challenge, since the available space depends on the size of over elements. It is a challenge to enable an automated wordwrapping at the right position and to handle this wrapping a way not to cost to much space for over elements.

Even the selection of a proper font and font size is challenging, since these factors are decisive for a later OCR-data recovery.

Text containers allow indentation but not any markup to prevent later OCR-data recovery from unresolvable obstacles.


Binary data is storable on microfilm, too - and yes, it is a real challenge

Unlike other bits-on-film procedures, we call the method used by the afc rendering tool rather "hex-on-film", since it is based on a very simple recoding of binary information to any character code – hexadecimal code by default. The data density of this method is quite poor. To improve data density three (red, green and blue) coloured text layers may be overlaid. Nevertheless with a fairly suitable font size, not more than 1 MByte of data should be applied to one 35x49mm microfilm frame. However this is enough to safe one of these countless outdated 5 1/4” and 3 1/2“ diskettes, hoarded in archives without any preservation concept. The advantage of this approach is self-explanatory: The data reconstruction may be done by many freely available open source tools, starting with a customary OCR-program. The recoding from a character map back to binary might be done in future by any “nerd” with ease, actually with block and pencil yet.

Hof.png

Besides there is no need to use only 16 latin characters. ANY UTF8 character might be used for encoding. Thus e.g. Chinese ideographs in combination with a powerful Chinese OCR might increase data density in future. The OCR-readability affects the font to be used; a font with serifs but without any ligatures and redundancy is best.

Metadata management

Independent from container type, meta data is stored in plain text with indentation but without any markup. Very similar to the text containers, the text has to be suitable for OCR and human readability as well. There are several kinds of meta data: meta data belonging to an image and meta data describing the whole project or at least spanning a group of images. The operator has to decide, where to place the text information: It might be placed separate outside a container, it might be attached to a container and it might be the content of a container itself. Any visualizable information can be processed. Simple txt-files, tables or even exif/xmp/iptc-embedded tags.

Interested? Need more information?

Please feel free to contact

archium | Historische Dokumentation
 
Dr. Klaus Wendel
Limesstrasse 24
D-73457 Essingen near Aalen / Germany
 
phone: +49/7365/328938
fax:   +49/7365/328937
eMail: kontakt (at) archium (dot) org
internet: http://www.archium.org
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Werkzeuge