We have added support for OME-TIFF to our WiscScan acquisition application. By default, WiscScan writes the OME-TIFF format, preserving all relevant metadata as OME-XML in the headers of the recorded TIFF files. There are four types of parameters that WiscScan saves:

1. Hardware characteristics – The system administrator specifies parameters that describe the acquisition hardware and other nonvarying but workstation-specific settings.
2. User settings – Each experimenter using the system has a separate profile, which includes information about the experimenter himself as well as his default acquisition preferences.
3. Experimental parameters – Much of the metadata is implicit within WiscScan, such as image resolution, color channel assignments, brightness and contrast settings, and other information known to the program itself.
4. Additional information – For each data series collected, a dialog box appears prompting the user for any additional relevant information about the run (things that might otherwise end up in a handwritten lab book). We have striven to keep the number of such questions to a minimum.

WiscScan user interface + OME-XML fragment

The WiscScan user interface shows the results of image acquisition. The browser window in the bottom left quadrant of the screen displays a portion of the OME-XML block associated with the image.

For various reasons, acquisition can sometimes fail in the middle of a run. WiscScan takes several precautionary measures to ensure the maximal amount of data is preserved should such a failure occur. As the hardware acquires image planes one by one, WiscScan stores them on disk as single-page TIFF files. For 3D timelapse data, these single-page TIFFs are then compiled into a single multi-page TIFF representing the entire dataset. For 4D data (a time series of image stacks), the single-page TIFFs are compiled into a series of multi-page TIFF files, one per timepoint.

Since some metadata parameters may not be known until the middle of acquisition (e.g., one of our workstations allows the user to utilize an ablation laser during acquisition, and we record the coordinates of the laser each time it is used), the OME-XML block cannot be written to the TIFF files until acquisition is complete. Each time the metadata accumulates, we save a snapshot of the latest OME-XML block to a temporary XML file on disk (similar to the single-plane TIFF files). When the acquisition process is complete, WiscScan includes the final OME-XML block when writing the final TIFF files in the completed data series.

For generating LSIDs, each workstation keeps an internal ID count and issues the LSIDs as "urn:lsid:loci.wisc.edu:*:X" where * is the type of element (e.g., Image, Pixels, etc.), and X is a string consisting of workstation name plus internal incremental ID. Each time acquisition begins, the count is incremented, resulting in a unique Image and Pixels LSID for every dataset on every workstation. This scheme works with OME, guaranteeing that should an OME-TIFF dataset be imported into a database multiple times, its pixels will still be stored only once within the system.

Some of our metadata fields are not part of the standard OME-XML schema. Fortunately, we can extend the schema using new semantic types. For example, here is a possible semantic type definition (STD) for ablation laser coordinates:

<?xml version="1.0" encoding="UTF-8"?> <OME xmlns="http://www.openmicroscopy.org/XMLschemas/OME/FC/ome.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:AML="http://www.openmicroscopy.org/XMLschemas/AnalysisModule/RC1/AnalysisModule.xsd" xmlns:STD="http://www.openmicroscopy.org/XMLschemas/STD/RC2/STD.xsd" xsi:schemaLocation="http://www.openmicroscopy.org/XMLschemas/OME/FC/ome.xsd http://www.openmicroscopy.org/XMLschemas/OME/FC/ome.xsd http://www.openmicroscopy.org/XMLschemas/AnalysisModule/RC1/AnalysisModule.xsd http://www.openmicroscopy.org/XMLschemas/AnalysisModule/RC1/AnalysisModule.xsd http://www.openmicroscopy.org/XMLschemas/STD/RC2/STD.xsd http://www.openmicroscopy.org/XMLschemas/STD/RC2/STD.xsd"> <STD:SemanticTypeDefinitions xmlns="http://www.openmicroscopy.org/XMLschemas/STD/RC2/STD.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openmicroscopy.org/XMLschemas/STD/RC2/STD.xsd"> <SemanticType Name="LaserCoordinates" AppliesTo="I"> <Description>Coordinates of a laser</Description> <!--<LaserCoordinates Type="Ablation" TheX="257" TheY="312" TheZ="1" TheT="6"/>--> <Element Name="Type" DBLocation="LOCI.LASER_TYPE" DataType="string"> <Description>Type of laser being recorded</Description> </Element> <Element Name="TheX" DBLocation="LOCI.LASER_X" DataType="integer"> <Description>X coordinate value</Description> </Element> <Element Name="TheY" DBLocation="LOCI.LASER_Y" DataType="integer"> <Description>Y coordinate value</Description> </Element> <Element Name="TheZ" DBLocation="LOCI.LASER_Z" DataType="integer"> <Description>Z dimensional position</Description> </Element> <Element Name="TheT" DBLocation="LOCI.LASER_T" DataType="integer"> <Description>T dimensional position</Description> </Element> </SemanticType> </STD:SemanticTypeDefinitions> </OME>

Such definitions need only be imported into the database once. It is even feasible to embed these definitions within the same OME-XML block whenever they are used, to ensure that OME-TIFF files can be successfully imported into any OME database "out of the box."

Once WiscScan has acquired a dataset, it uploads it to our FTP server, and notifies the OME server that a new dataset is waiting to be imported. The OME server imports the dataset, then notifies the user via email that the dataset is imported and ready for use. The OME web interface provides a mechanism for retrieving the original files as OME-TIFF, or exporting them to pure OME-XML. In addition, the user may choose to circumvent the OME server entirely and access the OME-TIFF files directly from the FTP server, if desired.