[med-svn] r15851 - trunk/packages/openslide/trunk/debian
Mathieu Malaterre
malat at moszumanska.debian.org
Sun Jan 26 08:30:43 UTC 2014
Author: malat
Date: 2014-01-26 08:30:43 +0000 (Sun, 26 Jan 2014)
New Revision: 15851
Added:
trunk/packages/openslide/trunk/debian/openslide-formats.3
trunk/packages/openslide/trunk/debian/openslide-formats.3.xml
Removed:
trunk/packages/openslide/trunk/debian/openslide-quickhash1sum.1
trunk/packages/openslide/trunk/debian/openslide-quickhash1sum.1.in
trunk/packages/openslide/trunk/debian/openslide-show-properties.1
trunk/packages/openslide/trunk/debian/openslide-show-properties.1.xml
trunk/packages/openslide/trunk/debian/openslide-write-png.1
trunk/packages/openslide/trunk/debian/openslide-write-png.1.in
Modified:
trunk/packages/openslide/trunk/debian/changelog
trunk/packages/openslide/trunk/debian/control
trunk/packages/openslide/trunk/debian/libopenslide-dev.install
trunk/packages/openslide/trunk/debian/openslide-tools.manpages
trunk/packages/openslide/trunk/debian/rules
Log:
Cleanup doc
Modified: trunk/packages/openslide/trunk/debian/changelog
===================================================================
--- trunk/packages/openslide/trunk/debian/changelog 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/changelog 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,3 +1,10 @@
+openslide (3.4.0-1) unstable; urgency=low
+
+ * New upstream, Closes: #735382, #732273, #734375
+ * Move openslide supported file format doc to openslide-formats.3
+
+ -- Mathieu Malaterre <malat at debian.org> Sun, 26 Jan 2014 09:26:02 +0100
+
openslide (3.3.3-1) unstable; urgency=low
* New upstream: adds minor compatibility improvements for Aperio JP2K
Modified: trunk/packages/openslide/trunk/debian/control
===================================================================
--- trunk/packages/openslide/trunk/debian/control 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/control 2014-01-26 08:30:43 UTC (rev 15851)
@@ -4,11 +4,11 @@
Maintainer: Debian Med Packaging Team <debian-med-packaging at lists.alioth.debian.org>
Uploaders: Mathieu Malaterre <malat at debian.org>
Build-Depends: debhelper (>= 9),
- libjpeg-dev, libopenjpeg-dev, zlib1g-dev, libtiff5-dev, libgtk2.0-dev, libxml2-dev
-Standards-Version: 3.9.3
+ libjpeg-dev, libopenjpeg-dev, zlib1g-dev, libtiff-dev, libgtk2.0-dev, libxml2-dev
+Standards-Version: 3.9.5
Homepage: http://openslide.org
Vcs-Browser: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/openslide/trunk/
-Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/openslide/trunk/
+Vcs-Svn: svn://anonscm.debian.org/debian-med/trunk/packages/openslide/trunk/
Package: libopenslide0
Architecture: any
@@ -28,11 +28,13 @@
particular resolution.
.
This library currently supports:
- -Trestle (.tif)
- -Hamamatsu (.vms, .vmu)
- -Aperio (.svs, .tif)
- -MIRAX (.mrxs)
- -Generic tiled TIFF (.tif)
+ - Aperio (.svs, .tif)
+ - Hamamatsu (.vms, .vmu, .ndpi)
+ - Leica (.scn)
+ - MIRAX (.mrxs)
+ - Sakura (.svslide)
+ - Trestle (.tif)
+ - Generic tiled TIFF (.tif)
.
This package contains the libraries needed to run OpenSlide applications.
@@ -55,11 +57,13 @@
particular resolution.
.
This library currently supports:
- -Trestle (.tif)
- -Hamamatsu (.vms, .vmu)
- -Aperio (.svs, .tif)
- -MIRAX (.mrxs)
- -Generic tiled TIFF (.tif)
+ - Aperio (.svs, .tif)
+ - Hamamatsu (.vms, .vmu, .ndpi)
+ - Leica (.scn)
+ - MIRAX (.mrxs)
+ - Sakura (.svslide)
+ - Trestle (.tif)
+ - Generic tiled TIFF (.tif)
.
This package contains development files needed to build OpenSlide applications.
@@ -82,10 +86,12 @@
particular resolution.
.
This library currently supports:
- -Trestle (.tif)
- -Hamamatsu (.vms, .vmu)
- -Aperio (.svs, .tif)
- -MIRAX (.mrxs)
- -Generic tiled TIFF (.tif)
+ - Aperio (.svs, .tif)
+ - Hamamatsu (.vms, .vmu, .ndpi)
+ - Leica (.scn)
+ - MIRAX (.mrxs)
+ - Sakura (.svslide)
+ - Trestle (.tif)
+ - Generic tiled TIFF (.tif)
.
This package contains command line tools for file manipulation.
Modified: trunk/packages/openslide/trunk/debian/libopenslide-dev.install
===================================================================
--- trunk/packages/openslide/trunk/debian/libopenslide-dev.install 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/libopenslide-dev.install 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,3 +1,4 @@
usr/lib/*/libopenslide.so
usr/include/openslide/*.h
usr/lib/*/pkgconfig/*.pc
+debian/openslide.3
Added: trunk/packages/openslide/trunk/debian/openslide-formats.3
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-formats.3 (rev 0)
+++ trunk/packages/openslide/trunk/debian/openslide-formats.3 2014-01-26 08:30:43 UTC (rev 15851)
@@ -0,0 +1,2336 @@
+'\" t
+.\" Title: OPENSLIDE-FORMATS
+.\" Author: [see the "AUTHORS" section]
+.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
+.\" Date: 01/26/2014
+.\" Manual: File Formats
+.\" Source: OpenSlide 3.4.0
+.\" Language: English
+.\"
+.TH "OPENSLIDE\-FORMATS" "3" "01/26/2014" "OpenSlide 3\&.4\&.0" "File Formats"
+.\" -----------------------------------------------------------------
+.\" * Define some portability stuff
+.\" -----------------------------------------------------------------
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.\" http://bugs.debian.org/507673
+.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\" -----------------------------------------------------------------
+.\" * set default formatting
+.\" -----------------------------------------------------------------
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.\" -----------------------------------------------------------------
+.\" * MAIN CONTENT STARTS HERE *
+.\" -----------------------------------------------------------------
+.SH "NAME"
+openslide-formats \- Reference supported formats
+.SH "DESCRIPTION"
+.SH "LIST OF KNOWN PROPERTIES"
+.SS "Properties generated by OpenSlide"
+.PP
+openslide\&.background\-color
+.RS 4
+The background color of the slide, given as an RGB hex triplet\&. This property is not always present\&.
+.RE
+.PP
+openslide\&.bounds\-height
+.RS 4
+The height of the rectangle bounding the non\-empty region of the slide\&. This property is not always present\&.
+.RE
+.PP
+openslide\&.bounds\-width
+.RS 4
+The width of the rectangle bounding the non\-empty region of the slide\&. This property is not always present\&.
+.RE
+.PP
+openslide\&.bounds\-x
+.RS 4
+The X coordinate of the rectangle bounding the non\-empty region of the slide\&. This property is not always present\&.
+.RE
+.PP
+openslide\&.bounds\-y
+.RS 4
+The Y coordinate of the rectangle bounding the non\-empty region of the slide\&. This property is not always present\&.
+.RE
+.PP
+openslide\&.comment
+.RS 4
+A free\-form text comment\&.
+.RE
+.PP
+openslide\&.mpp\-x
+.RS 4
+Microns per pixel in the X dimension of level 0\&. May not be present or accurate\&.
+.RE
+.PP
+openslide\&.mpp\-y
+.RS 4
+Microns per pixel in the Y dimension of level 0\&. May not be present or accurate\&.
+.RE
+.PP
+openslide\&.objective\-power
+.RS 4
+Magnification power of the objective\&. Often inaccurate; sometimes missing\&.
+.RE
+.PP
+openslide\&.quickhash\-1
+.RS 4
+A non\-cryptographic hash of a subset of the slide data\&. It can be used to uniquely identify a particular virtual slide, but cannot be used to detect file corruption or modification\&.
+.RE
+.PP
+openslide\&.vendor
+.RS 4
+The name of the vendor backend\&.
+.RE
+.SS "Properties for TIFF\-based formats"
+.PP
+tiff\&.Artist
+.RS 4
+The contents of the TIFF Artist tag\&.
+.RE
+.PP
+tiff\&.Copyright
+.RS 4
+The contents of the TIFF Copyright tag\&.
+.RE
+.PP
+tiff\&.DateTime
+.RS 4
+The contents of the TIFF DateTime tag\&.
+.RE
+.PP
+tiff\&.DocumentName
+.RS 4
+The contents of the TIFF DocumentName tag\&.
+.RE
+.PP
+tiff\&.HostComputer
+.RS 4
+The contents of the TIFF HostComputer tag\&.
+.RE
+.PP
+tiff\&.ImageDescription
+.RS 4
+The contents of the TIFF ImageDescripton tag\&.
+.RE
+.PP
+tiff\&.Make
+.RS 4
+The contents of the TIFF Make tag\&.
+.RE
+.PP
+tiff\&.Model
+.RS 4
+The contents of the TIFF Model tag\&.
+.RE
+.PP
+tiff\&.ResolutionUnit
+.RS 4
+The contents of the TIFF ResolutionUnit tag\&.
+.RE
+.PP
+tiff\&.Software
+.RS 4
+The contents of the TIFF Software tag\&.
+.RE
+.PP
+tiff\&.XPosition
+.RS 4
+The contents of the TIFF XPosition tag\&.
+.RE
+.PP
+tiff\&.XResolution
+.RS 4
+The contents of the TIFF XResolution tag\&.
+.RE
+.PP
+tiff\&.YPosition
+.RS 4
+The contents of the TIFF YPosition tag\&.
+.RE
+.PP
+tiff\&.YResolution
+.RS 4
+The contents of the TIFF YResolution tag\&.
+.RE
+.SS "Vendor\-specific properties"
+.PP
+A list of vendor\-specific properties can be found on the pages for each vendor format, linked from
+\m[blue]\fBSupported Virtual Slide Formats\fR\m[]\&\s-2\u[1]\d\s+2\&.
+.SH "TRESTLE FORMAT"
+.PP
+Format
+.RS 4
+single\-file pyramidal tiled TIFF, with non\-standard metadata and overlaps; additional files contain more metadata and detailed overlap info
+.RE
+.PP
+File extensions
+.RS 4
+
+\&.tif
+.RE
+.PP
+OpenSlide vendor backend
+.RS 4
+
+trestle
+.RE
+.SS "Detection"
+.PP
+Trestle slides are stored in single\-file TIFF format\&. OpenSlide will detect a file as Trestle if:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+The file is TIFF\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The TIFF
+Software
+tag starts with
+MedScan\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+The
+ImageDescription
+tag is present\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+All images are tiled\&.
+.RE
+.SS "Relevant TIFF tags"
+.TS
+allbox tab(:);
+lB lB.
+T{
+Tag
+T}:T{
+Description
+T}
+.T&
+l l
+l l
+l l.
+T{
+ImageDescription
+T}:T{
+Stores some important key\-value pairs, see below
+T}
+T{
+Software
+T}:T{
+Starts with \(rqMedScan\(rq
+T}
+T{
+XResolution, YResolution
+T}:T{
+Seems to store microns\-per\-pixel (MPP), which may or may not take into account the correct objective power\&. Note that this is inverted from standard TIFF, which stores pixels\-per\-unit, not units\-per\-pixel\&.
+T}
+.TE
+.sp 1
+.SS "Extra data stored in ImageDescription"
+.PP
+The
+ImageDescription
+tag contains semicolon\-delimited key\-value pairs\&. A key\-value pair is equals\-delimited\&. We use the
+OverlapsXY
+and
+Background Color
+keys from the
+ImageDescription, and ignore the rest\&. All of these values are stored as properties starting with \(rqtrestle\&.\(rq\&.
+.TS
+allbox tab(:);
+lB lB.
+T{
+Key
+T}:T{
+Description
+T}
+.T&
+l l
+l l
+l l
+l l
+l l.
+T{
+Background Color
+T}:T{
+Hex\-encoded background color info, assumed to be in the format RRGGBB\&.
+T}
+T{
+White Balance
+T}:T{
+Hex\-encoded white balance
+T}
+T{
+Objective Power
+T}:T{
+Reported objective power, often incorrect\&.
+T}
+T{
+JPEG Quality
+T}:T{
+The JPEG quality value\&.
+T}
+T{
+OverlapsXY
+T}:T{
+Overlaps, see below\&.
+T}
+.TE
+.sp 1
+.SS "TIFF Image Directory Organization"
+.PP
+The first image in the TIFF file is the full\-resolution image\&. The subsequent images are assumed to be decreasingly sized reduced\-resolution images\&.
+.SS "Overlaps"
+.PP
+The
+OverlapsXY
+pseudo\-field encodes a list of tile overlap values as ASCII\&.
+.PP
+Example: \(rq64 64 32 32 16 16\(rq (note the initial space)\&.
+.PP
+These values represent the standard overlaps between adjacent tiles in X and Y, in pixels\&. This example encodes 3 levels worth of overlaps\&. Further overlaps are assumed to have the value 0\&.
+.PP
+Individual tile overlaps may differ from the standard overlaps\&. These individual overlaps are recorded in
+\&.tif\-Nb
+files adjacent to the
+\&.tif
+file, where
+N
+is the level number\&. OpenSlide does not read these files, though they have been partially decoded; see
+\m[blue]\fBissue 21\fR\m[]\&\s-2\u[2]\d\s+2
+for details\&.
+.SS "Associated Images"
+.PP
+macro
+.RS 4
+the image with a filename extension of \(rq\&.Full\(rq (optional)
+.RE
+.SS "Known Properties"
+.PP
+All data encoded in the
+ImageDescription
+TIFF field is represented as properties prefixed with \(rqtrestle\&.\(rq\&.
+.PP
+openslide\&.mpp\-x
+.RS 4
+copy of
+tiff\&.XResolution
+(note that this is a totally non\-standard use of this TIFF tag)
+.RE
+.PP
+openslide\&.mpp\-y
+.RS 4
+copy of
+tiff\&.YResolution
+(note that this is a totally non\-standard use of this TIFF tag)
+.RE
+.PP
+openslide\&.objective\-power
+.RS 4
+normalized
+trestle\&.Objective Power
+.RE
+.SS "Test Data"
+.PP
+
+\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Trestle/\fR\m[]
+.SH "HAMAMATSU FORMAT"
+.PP
+Format
+.RS 4
+multi\-file JPEG/NGR with proprietary metadata and index file formats, and single\-file TIFF\-like format with proprietary metadata
+.RE
+.PP
+File extensions
+.RS 4
+\&.vms,
+\&.vmu,
+\&.ndpi
+.RE
+.PP
+OpenSlide vendor backend
+.RS 4
+
+hamamatsu
+.RE
+.SS "Detection"
+.PP
+OpenSlide will detect a file as Hamamatsu if:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+The file given is a INI\-style text file\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+It has a
+[Virtual Microscope Specimen]
+(VMS) or
+[Uncompressed Virtual Microscope Specimen]
+(VMU) group\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+If VMS, there are at least 1 row and 1 column of JPEG images (NoJpegColumns
+and
+NoJpegRows)\&.
+.RE
+.PP
+or if:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+The file has a TIFF directory structure\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The
+Software
+tag starts with
+NDP\&.scan\&.
+.RE
+.SS "Overview"
+.PP
+The Hamamatsu format has three variants\&. VMS and VMU consist of an index file, 2 or more image files, and (in the case of VMS) an \(lqoptimisation\(rq file\&. NDPI consists of a single TIFF\-like file with some custom TIFF tags\&. VMS and NDPI contain JPEG images; VMU contains NGR images (a custom uncompressed format)\&.
+.PP
+Multiple focal planes are ignored, only focal plane 0 is read\&.
+.PP
+JPEG does not allow for files larger than 65535 pixels on a side\&. In VMS, multiple JPEG files are used to encode large images\&. To avoid having many files, VMS uses close to maximum size (65K by 65K) JPEG files\&. NDPI, instead, stuffs large levels into a single JPEG and sets the overflowed width/height fields to 0\&.
+.PP
+Unfortunately, JPEG provides very poor support for random\-access decoding of parts of a file\&. To get around this, JPEG restart markers are placed at regular intervals, and these offsets are specified in the optimisation file (in VMS) or in a TIFF tag (in NDPI)\&. With restart markers identified, OpenSlide can treat JPEG as a tiled format, where the height is the height of an MCU row, and the width is the number of MCUs per row divided by the restart marker interval times the width of an MCU\&. (This often leads to oddly\-shaped and inefficient tiles of 4096x8, for example\&.)
+.PP
+Unfortunately, the VMS optimisation file does not give the location of every restart marker, only the ones found at the beginning of an MCU row\&. It also seems that the file ends early, and does not give the location of the restart marker at the last MCU row of the last image file\&.
+.PP
+Thus, the optimisation file can only be taken as a hint, and cannot be trusted\&. The entire set of JPEG files must be scanned for restart markers in order to facilitate random access\&. OpenSlide does this lazily as needed, and also in a background thread that runs only when OpenSlide is otherwise idle\&.
+.PP
+The VMS map file is a lower\-resolution version of the other images, and can be used to make a 2\-level JPEG pyramid\&. JPEG also allows for lower\-resolution decoding, so further pyramid levels are synthesized from each JPEG file\&.
+.SS "VMS File"
+.PP
+The
+\&.vms
+file is the main index file for the VMS format\&. It is a Windows INI\-style key\-value pair file, with sections\&. Only keys in the
+Virtual Microscope Specimen
+group are read by OpenSlide\&.
+.PP
+Here are known keys from the file:
+.TS
+allbox tab(:);
+lB lB.
+T{
+Key
+T}:T{
+Description
+T}
+.T&
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l.
+T{
+NoLayers
+T}:T{
+Number of layers, currently must be 1 to be accepted
+T}
+T{
+NoJpegColumns
+T}:T{
+Number of JPEG files across, given in ImageFile attributes
+T}
+T{
+NoJpegRows
+T}:T{
+Number of JPEG files down, given in ImageFile attributes
+T}
+T{
+ImageFile
+T}:T{
+Semantically equivalent to ImageFile(0,0,0), though not specified that way\&. The image in position (0,0,0) of the set of images
+T}
+T{
+ImageFile(x,y)
+T}:T{
+Semantically equivalent to ImageFile(0,x,y), though not specified that way\&. The image in position (0,x,y) of the set of images
+T}
+T{
+ImageFile(z,x,y)
+T}:T{
+Where x and y are non\-negative integers\&. Both x and y cannot be 0\&. z is a positive integer\&. These are the images that make up the virtual slide, as a concatenation of JPEG images\&. x and y specify the location of each JPEG, z specifies the focal plane
+T}
+T{
+MapFile
+T}:T{
+A lower\-resolution version of all the ImageFiles
+T}
+T{
+OptimisationFile
+T}:T{
+File specifying some of the restart marker offsets in each ImageFile
+T}
+T{
+AuthCode
+T}:T{
+Unknown
+T}
+T{
+SourceLens
+T}:T{
+Apparently the magnification
+T}
+T{
+PhysicalWidth
+T}:T{
+Width of the slide in some unit?
+T}
+T{
+PhysicalHeight
+T}:T{
+Height of the slide in some unit?
+T}
+T{
+LayerSpacing
+T}:T{
+Unknown
+T}
+T{
+MacroImage
+T}:T{
+Image file for the \(lqmacro\(rq associated image
+T}
+T{
+PhysicalMacroWidth
+T}:T{
+Unknown
+T}
+T{
+PhysicalMacroHeight
+T}:T{
+Unknown
+T}
+T{
+XOffsetFromSlideCentre
+T}:T{
+Unknown
+T}
+T{
+YOffsetFromSlideCentre
+T}:T{
+Unknown
+T}
+.TE
+.sp 1
+.SS "VMU File"
+.PP
+The
+\&.vmu
+file is the main index file for the VMU format\&. Only keys in the
+Uncompressed Virtual Microscope Specimen
+group are read by OpenSlide\&.
+.PP
+Here are known keys from the file:
+.TS
+allbox tab(:);
+lB lB.
+T{
+Key
+T}:T{
+Description
+T}
+.T&
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l.
+T{
+NoLayers
+T}:T{
+(see VMS above)
+T}
+T{
+ImageFile
+T}:T{
+(see VMS above)
+T}
+T{
+ImageFile(x,y)
+T}:T{
+(see VMS above)
+T}
+T{
+ImageFile(z,x,y)
+T}:T{
+(see VMS above)
+T}
+T{
+MapFile
+T}:T{
+(see VMS above)
+T}
+T{
+MapScale
+T}:T{
+Seems to be the downsample factor of the map
+T}
+T{
+AuthCode
+T}:T{
+(see VMS above)
+T}
+T{
+SourceLens
+T}:T{
+(see VMS above)
+T}
+T{
+PixelWidth
+T}:T{
+Width of the image in pixels
+T}
+T{
+PixelHeight
+T}:T{
+Height of the image in pixels
+T}
+T{
+PhysicalWidth
+T}:T{
+(see VMS above)
+T}
+T{
+PhysicalHeight
+T}:T{
+(see VMS above)
+T}
+T{
+LayerSpacing
+T}:T{
+(see VMS above)
+T}
+T{
+LayerOffset
+T}:T{
+Unknown
+T}
+T{
+MacroImage
+T}:T{
+(see VMS above)
+T}
+T{
+PhysicalMacroWidth
+T}:T{
+(see VMS above)
+T}
+T{
+PhysicalMacroHeight
+T}:T{
+(see VMS above)
+T}
+T{
+XOffsetFromSlideCentre
+T}:T{
+(see VMS above)
+T}
+T{
+YOffsetFromSlideCentre
+T}:T{
+(see VMS above)
+T}
+T{
+Reference
+T}:T{
+Unknown
+T}
+T{
+BitsPerPixel
+T}:T{
+Bits per pixel, currently expected to be 36
+T}
+T{
+PixelOrder
+T}:T{
+Currently expected to be RGB
+T}
+T{
+Creator
+T}:T{
+String describing the software creating this image
+T}
+T{
+IlluminationMode
+T}:T{
+Unknown
+T}
+T{
+ExposureMultiplier
+T}:T{
+Unknown, possibly the multiplier used to scale to 15 bits?
+T}
+T{
+GainRed
+T}:T{
+Unknown
+T}
+T{
+GainGreen
+T}:T{
+Unknown
+T}
+T{
+GainBlue
+T}:T{
+Unknown
+T}
+T{
+FocalPlaneTolerance
+T}:T{
+Unknown
+T}
+T{
+NMP
+T}:T{
+Unknown
+T}
+T{
+MacroIllumination
+T}:T{
+Unknown
+T}
+T{
+FocusOffset
+T}:T{
+Unknown
+T}
+T{
+RefocusInterval
+T}:T{
+Unknown
+T}
+T{
+CubeName
+T}:T{
+Unknown
+T}
+T{
+HardwareModel
+T}:T{
+Name of the hardware
+T}
+T{
+HardwareSerial
+T}:T{
+Serial number of the hardware
+T}
+T{
+NoFocusPoints
+T}:T{
+Unknown
+T}
+T{
+FocusPoint0X
+T}:T{
+Unknown
+T}
+T{
+FocusPoint0Y
+T}:T{
+Unknown
+T}
+T{
+FocusPoint0Z
+T}:T{
+Unknown
+T}
+T{
+FocusPoint1X
+T}:T{
+Unknown
+T}
+T{
+FocusPoint1Y
+T}:T{
+Unknown
+T}
+T{
+FocusPoint1Z
+T}:T{
+Unknown
+T}
+T{
+FocusPoint2X
+T}:T{
+Unknown
+T}
+T{
+FocusPoint2Y
+T}:T{
+Unknown
+T}
+T{
+FocusPoint2Z
+T}:T{
+Unknown
+T}
+T{
+FocusPoint3X
+T}:T{
+Unknown
+T}
+T{
+FocusPoint3Y
+T}:T{
+Unknown
+T}
+T{
+FocusPoint3Z
+T}:T{
+Unknown
+T}
+T{
+NoBlobPoints
+T}:T{
+Unknown
+T}
+T{
+BlobPoint0Blob
+T}:T{
+Unknown
+T}
+T{
+BlobPoint0FocusPoint
+T}:T{
+Unknown
+T}
+T{
+BlobPoint1Blob
+T}:T{
+Unknown
+T}
+T{
+BlobPoint1FocusPoint
+T}:T{
+Unknown
+T}
+T{
+BlobPoint2Blob
+T}:T{
+Unknown
+T}
+T{
+BlobPoint2FocusPoint
+T}:T{
+Unknown
+T}
+T{
+BlobPoint3Blob
+T}:T{
+Unknown
+T}
+T{
+BlobPoint3FocusPoint
+T}:T{
+Unknown
+T}
+T{
+BlobMapWidth
+T}:T{
+Unknown
+T}
+T{
+BlobMapHeight
+T}:T{
+Unknown
+T}
+.TE
+.sp 1
+.SS "NDPI File"
+.PP
+NDPI uses a TIFF\-like structure, but libtiff cannot read the headers of an NDPI file\&. This is because NDPI specifies the
+RowsPerStrip
+as the height of the file, and after doing out the multiplication, this typically overflows libtiff and it refuses to open the file\&. Also, the TIFF tags are not stored in sorted order\&.
+.PP
+NDPI stores an image pyramid in TIFF directory entries\&. In some files, the lower\-resolution pyramid levels contain no restart markers\&. The macro image, and sometimes an active\-region map, seems to come last\&.
+.PP
+JPEG files in NDPI are not necessarily valid\&. If
+ImageWidth
+or
+ImageHeight
+exceeds the JPEG limit of 65535, then the width or height as stored in the JPEG file is 0\&. libjpeg will refuse to read the header of such a file, so the JPEG data stream must be altered when fed into libjpeg\&.
+.PP
+Here are the observed TIFF tags:
+.TS
+allbox tab(:);
+lB lB.
+T{
+Tag
+T}:T{
+Description
+T}
+.T&
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l
+l l.
+T{
+ImageWidth
+T}:T{
+Width of the image
+T}
+T{
+ImageHeight
+T}:T{
+Height of the image
+T}
+T{
+Make
+T}:T{
+\(lqHamamatsu\(rq
+T}
+T{
+Model
+T}:T{
+\(lqNanoZoomer\(rq or \(lqC9600\-12\(rq, etc
+T}
+T{
+XResolution
+T}:T{
+Seemingly correct X resolution, when interpreted with ResolutionUnit
+T}
+T{
+YResolution
+T}:T{
+Seemingly correct Y resolution, when interpreted with ResolutionUnit
+T}
+T{
+ResolutionUnit
+T}:T{
+Seemingly correct resolution unit
+T}
+T{
+Software
+T}:T{
+\(lqNDP\&.scan\(rq, sometimes with a version number
+T}
+T{
+StripOffsets
+T}:T{
+The offset of the JPEG file for this layer
+T}
+T{
+StripByteCounts
+T}:T{
+The length of the JPEG file for this layer
+T}
+T{
+65420
+T}:T{
+Unknown, always 1?
+T}
+T{
+65421
+T}:T{
+SourceLens, correctly downsampled for each entry\&. \-1 for macro image, \-2 for a map of non\-empty regions\&.
+T}
+T{
+65422
+T}:T{
+XOffsetFromSlideCentre
+T}
+T{
+65423
+T}:T{
+YOffsetFromSlideCentre
+T}
+T{
+65424
+T}:T{
+Seemingly the Z offset from the center focal plane, in some unit
+T}
+T{
+65425
+T}:T{
+Unknown, always 0?
+T}
+T{
+65426
+T}:T{
+Optimisation entries, as above
+T}
+T{
+65427
+T}:T{
+Reference
+T}
+T{
+65428
+T}:T{
+Unknown, AuthCode?
+T}
+T{
+65433
+T}:T{
+Unknown, I have seen 1500 in this tag
+T}
+T{
+65439
+T}:T{
+Unknown, perhaps some polygon ROI?
+T}
+T{
+65440
+T}:T{
+Unknown, I have seen this: <0 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 1 9 1 10 1 11 1 12 1 13 1 14 1 15 1 16 1 17>
+T}
+T{
+65441
+T}:T{
+Unknown, always 0?
+T}
+T{
+65442
+T}:T{
+Scanner serial number
+T}
+T{
+65443
+T}:T{
+Unknown, have seen 0 or 16
+T}
+T{
+65444
+T}:T{
+Unknown, always 80?
+T}
+T{
+65445
+T}:T{
+Unknown, have seen 0, 2, 10
+T}
+T{
+65446
+T}:T{
+Unknown, always 0?
+T}
+T{
+65449
+T}:T{
+ASCII metadata block, key=value pairs, not always present
+T}
+T{
+65455
+T}:T{
+Unknown, have seen 13
+T}
+T{
+65456
+T}:T{
+Unknown, have seen 101
+T}
+T{
+65457
+T}:T{
+Unknown, always 0?
+T}
+T{
+65458
+T}:T{
+Unknown, always 0?
+T}
+.TE
+.sp 1
+.SS "Optimisation File (only for VMS)"
+.PP
+The optimisation file contains a list of 32\- (or 64\- or 320\- ?) bit little endian values, giving the file offset into an MCU row, each offset starts at a 40\-byte alignment, and the last row (of the entire file, not each image) seems to be missing\&. The offsets are all packed into 1 file, even with multiple images\&. The order of images is left\-to\-right, top\-to\-bottom\&.
+.SS "Map File (only for VMS/VMU)"
+.PP
+The VMS map file is a standard JPEG file\&. Its restart markers (if any) are not included in the optimisation file\&. The VMU map file is in NGR format\&. This file can be used to provide a lower\-resolution view of the slide\&.
+.SS "Image Files (only for VMS/VMU)"
+.PP
+These files are given by the VMS/VMU
+ImageFile
+keys\&. They are assumed to have a height which is a multiple of the MCU height\&. They are assumed to have a width which is a multiple of MCUs per row divided by the restart interval\&.
+.PP
+For VMS, these files are in JPEG, for VMU they are in NGR format\&.
+.SS "NGR Format"
+.PP
+The NGR file contains uncompressed 16\-bit RGB data, with a small header\&. The files we have encountered start with
+GN, two more bytes, and then width, height, and column width in little endian 32\-bit format\&. The column width must divide evenly into the width\&. Column width is important, since NGR files are generated in columns, where the first column comes first in the file, followed by subsequent files\&. Columns are painted left\-to\-right\&.
+.PP
+At offset 24 is another 32\-bit integer which gives the offset in the file to the start of the image data\&. The image data we have encountered is in 16\-bit little endian format\&.
+.SS "Associated Images"
+.PP
+macro
+.RS 4
+the image file given by the
+MacroImage
+value in the VMS/VMU file, or
+SourceLens
+of \-1 in NDPI
+.RE
+.SS "Known Properties"
+.PP
+All key\-value data stored in the VMS/VMU file, and known tags from the NDPI file, are encoded as properties prefixed with \(rqhamamatsu\&.\(rq\&.
+.PP
+openslide\&.mpp\-x
+.RS 4
+for NDPI, calculated as
+10000/tiff\&.XResolution, if
+tiff\&.ResolutionUnit
+is
+centimeter
+.RE
+.PP
+openslide\&.mpp\-y
+.RS 4
+for NDPI, calculated as
+10000/tiff\&.YResolution, if
+tiff\&.ResolutionUnit
+is
+centimeter
+.RE
+.PP
+openslide\&.objective\-power
+.RS 4
+normalized
+hamamatsu\&.SourceLens
+.RE
+.SS "Test Data"
+.PP
+NDPI format
+.RS 4
+
+\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Hamamatsu/\fR\m[]
+.RE
+.PP
+VMS format
+.RS 4
+
+\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Hamamatsu\-vms/\fR\m[]
+.RE
+.SH "APERIO FORMAT"
+.PP
+Format
+.RS 4
+single\-file pyramidal tiled TIFF, with non\-standard metadata and compression
+.RE
+.PP
+File extensions
+.RS 4
+\&.svs,
+\&.tif
+.RE
+.PP
+OpenSlide vendor backend
+.RS 4
+
+aperio
+.RE
+.SS "Vendor Documentation"
+.PP
+
+\m[blue]\fBhttp://www\&.aperio\&.com/documents/api/Aperio_Digital_Slides_and_Third\-party_data_interchange\&.pdf\fR\m[]
+.SS "Detection"
+.PP
+Aperio slides are stored in single\-file TIFF format\&. OpenSlide will detect a file as Aperio if:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+The file is TIFF\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The initial image is tiled\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+The
+ImageDescription
+tag starts with
+Aperio\&.
+.RE
+.SS "Relevant TIFF tags"
+.TS
+allbox tab(:);
+lB lB.
+T{
+Tag
+T}:T{
+Description
+T}
+.T&
+l l
+l l.
+T{
+ImageDescription
+T}:T{
+Stores some important key\-value pairs and other information, see below
+T}
+T{
+Compression
+T}:T{
+May be 33003 or 33005, which represent specific kinds of JPEG 2000 compression, see below
+T}
+.TE
+.sp 1
+.SS "Extra data stored in ImageDescription"
+.PP
+For tiled images, the
+ImageDescription
+tag contains some dimensional downsample information as well as what look like offsets\&. Additionally, vertical line\-delimited key\-value pairs are stored, in at least the full\-resolution image\&. A key\-value pair is equals\-delimited\&. These key\-values are stored as properties starting with \(rqaperio\&.\(rq\&. Currently, OpenSlide does not use any of the information present in these key\-value fields\&.
+.PP
+For stripped images, the
+ImageDescription
+tag may contain a name, followed by a carriage return\&. This is used for naming the associated images\&. The second image in the file does not have a name, though it is an associated image\&.
+.SS "TIFF Image Directory Organization"
+.PP
+\m[blue]\fBhttp://www\&.aperio\&.com/documents/api/Aperio_Digital_Slides_and_Third\-party_data_interchange\&.pdf\fR\m[]
+page 14:
+.PP
+The first image in an SVS file is always the baseline image (full resolution)\&. This image is always tiled, usually with a tile size of 240x240 pixels\&. The second image is always a thumbnail, typically with dimensions of about 1024x768 pixels\&. Unlike the other slide images, the thumbnail image is always stripped\&. Following the thumbnail there may be one or more intermediate \(lqpyramid\(rq images\&. These are always compressed with the same type of compression as the baseline image, and have a tiled organization with the same tile size\&.
+.PP
+Optionally at the end of an SVS file there may be a slide label image, which is a low resolution picture taken of the slide\(cqs label, and/or a macro camera image, which is a low resolution picture taken of the entire slide\&. The label and macro images are always stripped\&.
+.SS "JPEG 2000 (compression types 33003 or 33005)"
+.PP
+Some Aperio files use compression type 33003 or 33005\&. Images using this compression need to be decoded as a JPEG 2000 codestream\&. For 33003: YCbCr format, possibly with a chroma subsampling of 4:2:2\&. For 33005: RGB format\&. Note that the TIFF file may not encode the colorspace or subsampling parameters in the
+PhotometricInterpretation
+field, nor the
+YCbCrSubsampling
+field, even though the TIFF standard seems to require this\&. The correct subsampling can be found in the JPEG 2000 codestream\&.
+.SS "Associated Images"
+.PP
+thumbnail
+.RS 4
+the second image in the file
+.RE
+.PP
+label
+.RS 4
+optional, the name \(lqlabel\(rq is given in
+ImageDescription
+.RE
+.PP
+macro
+.RS 4
+optional, the name \(lqmacro\(rq is given in
+ImageDescription
+.RE
+.SS "Known Properties"
+.PP
+All key\-value data encoded in the
+ImageDescription
+TIFF field is represented as properties prefixed with \(rqaperio\&.\(rq\&.
+.PP
+openslide\&.mpp\-x
+.RS 4
+normalized
+aperio\&.MPP
+.RE
+.PP
+openslide\&.mpp\-y
+.RS 4
+normalized
+aperio\&.MPP
+.RE
+.PP
+openslide\&.objective\-power
+.RS 4
+normalized
+aperio\&.AppMag
+.RE
+.SS "Test Data"
+.PP
+
+\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Aperio/\fR\m[]
+.SH "MIRAX FORMAT"
+.PP
+Format
+.RS 4
+multi\-file with very complicated proprietary metadata and indexes
+.RE
+.PP
+File extensions
+.RS 4
+
+\&.mrxs
+.RE
+.PP
+OpenSlide vendor backend
+.RS 4
+
+mirax
+.RE
+.SS "Detection"
+.PP
+OpenSlide will detect a file as MIRAX if:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+The file is not a TIFF\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The filename ends with
+\&.mrxs\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+A directory exists in the same location as the file, with the same name as the file minus the extension\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 4.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 4." 4.2
+.\}
+A file named
+Slidedat\&.ini
+exists in the directory\&.
+.RE
+.SS "Overview"
+.PP
+MIRAX can store slides in JPEG, PNG, or BMP formats\&. Because JPEG does not allow for large images, and JPEG and PNG provide very poor support for random\-access decoding of part of an image, multiple images are needed to encode a slide\&. To avoid having many individual files, MIRAX packs these images into a small number of data files\&. The index file provides offsets into the data files for each required piece of data\&.
+.PP
+The camera on MIRAX scanners takes overlapping photos and records the position of each one\&. Each photo is then split into multiple images which do not overlap\&. Overlaps only occur between images that come from different photos\&.
+.PP
+To generate level
+n + 1, each image from level
+n
+is downsampled by 2 and then concatenated into a new image, 4 old images per new image (2 x 2)\&. This process is repeated for each level, irrespective of image overlaps\&. Therefore, at sufficiently high levels, a single image can contain one or more embedded overlaps of non\-integral width\&.
+.SS "Index File"
+.PP
+The index file starts with a five\-character ASCII version string, followed by the
+SLIDE_ID
+from the slidedat file\&. The rest of the file consists of 32\-bit little\-endian integers (unaligned), which can be data values or pointers to byte offsets within the index file\&.
+.PP
+The first two integers point to offset tables for the hierarchical and nonhierarchical roots, respectively\&. These tables contain one record for each
+VAL
+in the
+HIERARCHICAL
+slidedat section\&. For example, the record for
+NONHIER_1_VAL_2
+would be stored at
+nonhier_root + 4 * (NONHIER_0_COUNT + 2)\&.
+.PP
+Each record is a pointer to a linked list of data pages\&. The first two values in a data page are the number of data items in the page and a pointer to the next page\&. The first page always has 0 data items, and the last page has a 0 next pointer\&.
+.PP
+There is one hierarchical record for each zoom level\&. The record contains data items consisting of an image index, offset and length within a file, and a file number\&. The file number can be converted to a data file name via the
+DATAFILE
+slidedat section\&. The image index is equal to
+image_y * GENERAL\&.IMAGENUMBER_X + image_x\&. Image coordinates which are not multiples of the zoom level\(cqs downsample factor are omitted\&.
+.PP
+Nonhierarchical records refer to associated images and additional metadata\&. Nonhierarchical data items consist of three zero values followed by an offset, length, and file number as in hierarchical records\&.
+.SS "Data Files"
+.PP
+A data file begins with a header containing a five\-character ASCII version string, the
+SLIDE_ID
+from the slidedat file, the file number encoded into three ASCII characters, and 256 bytes of padding\&. The remainder of the file contains packed data referenced by the index file\&.
+.SS "Slide Position File"
+.PP
+The slide position file is referenced by the
+VIMSLIDE_POSITION_BUFFER\&.default
+nonhierarchical section\&. It contains one entry for each camera position (not each image position) in row\-major order\&. Each entry is nine bytes: a flag byte, the
+X
+pixel coordinate of the photo (4 bytes, little\-endian, may be negative), and the
+Y
+coordinate (4 bytes, little\-endian, may be negative)\&. In slides with
+CURRENT_SLIDE_VERSION
+≥ 1\&.9, the flag byte is 1 if the slide file contains images for this camera position, 0 otherwise\&. In older slides, the flag byte is always 0\&.
+.PP
+In slides with
+CURRENT_SLIDE_VERSION
+≥ 2\&.2, the slide position file is compressed with DEFLATE and referenced by the
+StitchingIntensityLayer\&.StitchingIntensityLevel
+nonhierarchical section\&.
+.SS "Associated Images"
+.PP
+thumbnail
+.RS 4
+the image named \(rqScanDataLayer_SlidePreview\(rq in
+Slidedat\&.ini
+(optional)
+.RE
+.PP
+label
+.RS 4
+the image named \(rqScanDataLayer_SlideBarcode\(rq in
+Slidedat\&.ini
+(optional)
+.RE
+.PP
+macro
+.RS 4
+the image named \(rqScanDataLayer_SlideThumbnail\(rq in
+Slidedat\&.ini
+(optional)
+.RE
+.SS "Known Properties"
+.PP
+All key\-value data stored in the
+Slidedat\&.ini
+file are encoded as properties prefixed with \(rqmirax\&.\(rq\&.
+.PP
+openslide\&.mpp\-x
+.RS 4
+normalized
+MICROMETER_PER_PIXEL_X
+from the Slidedat section corresponding to level 0 (typically
+mirax\&.LAYER_0_LEVEL_0_SECTION\&.MICROMETER_PER_PIXEL_X)
+.RE
+.PP
+openslide\&.mpp\-y
+.RS 4
+normalized
+MICROMETER_PER_PIXEL_Y
+from the Slidedat section corresponding to level 0 (typically
+mirax\&.LAYER_0_LEVEL_0_SECTION\&.MICROMETER_PER_PIXEL_Y)
+.RE
+.PP
+openslide\&.objective\-power
+.RS 4
+normalized
+mirax\&.GENERAL\&.OBJECTIVE_MAGNIFICATION
+.RE
+.SS "See Also"
+.PP
+\m[blue]\fBIntroduction to MIRAX/MRXS\fR\m[]\&\s-2\u[3]\d\s+2\&. Note that our terminology has changed since that document was written; where it says \(lqtile\(rq, substitute \(lqimage\(rq, and where it says \(lqsubtile\(rq, substitute \(lqtile\(rq\&.
+.SS "Test Data"
+.PP
+
+\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Mirax/\fR\m[]
+.SH "SAKURA FORMAT"
+.PP
+Format
+.RS 4
+SQLite database containing pyramid tiles and metadata
+.RE
+.PP
+File extensions
+.RS 4
+
+\&.svslide
+.RE
+.PP
+OpenSlide vendor backend
+.RS 4
+
+sakura
+.RE
+.SS "Detection"
+.PP
+OpenSlide will detect a file as Sakura if:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+The file is a SQLite database\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The
+DataManagerSQLiteConfigXPO
+table contains exactly one row, and its
+TableName
+field refers to a unique table\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+The unique table contains a row with
+id = "++MagicBytes"
+and
+data = "SVGigaPixelImage"\&.
+.RE
+.SS "File Organization"
+.PP
+Sakura slides are SQLite 3 database files written by the eXpress Persistent Objects ORM\&. Tables contain slide metadata, associated images, and JPEG tiles\&. Tiles are addressed as
+(downsample, level\-0 X coordinate, level\-0 Y coordinate, color channel), with separate grayscale JPEGs for each color channel\&. Despite the generality of the address format, tiles appear to be organized in a regular grid, with power\-of\-two level downsamples and without overlapping tiles\&. The structure of the file allows scans to be sparse, but it is not clear if this is actually done\&.
+.SS "SQL Tables"
+.PP
+Some irrelevant tables and columns have been omitted from the summary below\&.
+DataManagerSQLiteConfigXPO.PP
+Useful only to get a reference to the unique table\&. OpenSlide requires this table to contain exactly one row\&.
+.TS
+allbox tab(:);
+lB lB lB.
+T{
+Column
+T}:T{
+Type
+T}:T{
+Description
+T}
+.T&
+l l l.
+T{
+TableName
+T}:T{
+text
+T}:T{
+Name of the unique table, described below
+T}
+.TE
+.sp 1
+SVSlideDataXPO.PP
+High\-level metadata about a slide\&. OpenSlide assumes this table will contain exactly one row\&.
+.TS
+allbox tab(:);
+lB lB lB.
+T{
+Column
+T}:T{
+Type
+T}:T{
+Description
+T}
+.T&
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l.
+T{
+OID
+T}:T{
+integer
+T}:T{
+Primary key
+T}
+T{
+m_labelScan
+T}:T{
+integer
+T}:T{
+Foreign key to label associated image in SVScannedImageDataXPO
+T}
+T{
+m_overviewScan
+T}:T{
+integer
+T}:T{
+Foreign key to macro associated image in SVScannedImageDataXPO
+T}
+T{
+SlideId
+T}:T{
+text
+T}:T{
+UUID
+T}
+T{
+Date
+T}:T{
+text
+T}:T{
+File creation date?
+T}
+T{
+Description
+T}:T{
+text
+T}:T{
+Descriptive text?
+T}
+T{
+Creator
+T}:T{
+text
+T}:T{
+Author?
+T}
+T{
+DiagnosisCode
+T}:T{
+text
+T}:T{
+Unknown, have seen \(lq0\(rq
+T}
+T{
+HRScanCount
+T}:T{
+integer
+T}:T{
+Presumably the number of corresponding rows in SVHRScanDataXPO
+T}
+T{
+Keywords
+T}:T{
+text
+T}:T{
+Descriptive text?
+T}
+T{
+TotalDataSizeBytes
+T}:T{
+integer
+T}:T{
+Presumably the sum of TotalDataSizeBytes in corresponding SVHRScanDataXPO rows
+T}
+.TE
+.sp 1
+SVHRScanDataXPO.PP
+A single high\-resolution scan of a slide from
+SVSlideDataXPO\&. OpenSlide assumes this table will contain exactly one row\&.
+.TS
+allbox tab(:);
+lB lB lB.
+T{
+Column
+T}:T{
+Type
+T}:T{
+Description
+T}
+.T&
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l.
+T{
+OID
+T}:T{
+integer
+T}:T{
+Primary key
+T}
+T{
+ParentSlide
+T}:T{
+integer
+T}:T{
+Foreign key to SVSlideDataXPO
+T}
+T{
+ScanId
+T}:T{
+text
+T}:T{
+UUID
+T}
+T{
+Date
+T}:T{
+text
+T}:T{
+Scan date?
+T}
+T{
+Description
+T}:T{
+text
+T}:T{
+Descriptive text?
+T}
+T{
+Name
+T}:T{
+text
+T}:T{
+Scan name?
+T}
+T{
+PosOnSlideMm
+T}:T{
+blob
+T}:T{
+16 bytes of binary
+T}
+T{
+ResolutionMmPerPix
+T}:T{
+real
+T}:T{
+Millimeters per pixel
+T}
+T{
+NominalLensMagnification
+T}:T{
+real
+T}:T{
+Objective power
+T}
+T{
+ThumbnailImage
+T}:T{
+blob
+T}:T{
+thumbnail associated image data
+T}
+T{
+TotalDataSizeBytes
+T}:T{
+integer
+T}:T{
+Same as TOTAL_SIZE blob in unique table
+T}
+T{
+FocussingMethod
+T}:T{
+integer
+T}:T{
+Unknown; have seen \(lq1\(rq
+T}
+T{
+FocusStack
+T}:T{
+blob
+T}:T{
+8 bytes; have seen all zeros
+T}
+.TE
+.sp 1
+SVScannedImageDataXPO.PP
+Contains associated images other than the
+thumbnail\&.
+.TS
+allbox tab(:);
+lB lB lB.
+T{
+Column
+T}:T{
+Type
+T}:T{
+Description
+T}
+.T&
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l
+l l l.
+T{
+OID
+T}:T{
+integer
+T}:T{
+Primary key
+T}
+T{
+Id
+T}:T{
+text
+T}:T{
+UUID
+T}
+T{
+PosOnSlideMm
+T}:T{
+blob
+T}:T{
+16 bytes of binary
+T}
+T{
+ScanCenterPosMm
+T}:T{
+blob
+T}:T{
+16 bytes of binary
+T}
+T{
+ResolutionMmPerPix
+T}:T{
+real
+T}:T{
+Millimeters per pixel
+T}
+T{
+Image
+T}:T{
+blob
+T}:T{
+JPEG image data
+T}
+T{
+ThumbnailImage
+T}:T{
+blob
+T}:T{
+Low\-resolution JPEG thumbnail
+T}
+.TE
+.sp 1
+tile.PP
+This table is most naturally used to map tile coordinates to tile IDs, but is not suitable for individual lookups because it has no useful indexes\&.
+.TS
+allbox tab(:);
+lB lB lB.
+T{
+Column
+T}:T{
+Type
+T}:T{
+Description
+T}
+.T&
+l l l
+l l l
+l l l
+l l l
+l l l.
+T{
+TILEID
+T}:T{
+text
+T}:T{
+Foreign key to unique table
+T}
+T{
+PYRAMIDLEVEL
+T}:T{
+integer
+T}:T{
+Downsample of the pyramid level
+T}
+T{
+COLUMNINDEX
+T}:T{
+integer
+T}:T{
+Level\-0 X coordinate of the top\-left corner of the tile
+T}
+T{
+ROWINDEX
+T}:T{
+integer
+T}:T{
+Level\-0 Y coordinate of the top\-left corner of the tile
+T}
+T{
+COLORINDEX
+T}:T{
+integer
+T}:T{
+0 for red, 1 for green, 2 for blue
+T}
+.TE
+.sp 1
+Unique table
+.PP
+This is the table named by
+DataManagerSQLiteConfigXPO\&.TableName\&. It contains named blobs including the JPEG tile data\&.
+.TS
+allbox tab(:);
+lB lB lB.
+T{
+Column
+T}:T{
+Type
+T}:T{
+Description
+T}
+.T&
+l l l
+l l l
+l l l.
+T{
+id
+T}:T{
+text
+T}:T{
+Primary key
+T}
+T{
+size
+T}:T{
+integer
+T}:T{
+Length of data field
+T}
+T{
+data
+T}:T{
+blob
+T}:T{
+Data item
+T}
+.TE
+.sp 1
+.PP
+This table stores a variety of blob types\&. IDs for image tiles appear to be mechanically generated from the tile coordinates, but OpenSlide does not construct them directly\&. Instead, it uses the
+tile
+table to obtain IDs for each tile\&.
+.TS
+allbox tab(:);
+lB lB.
+T{
+id
+T}:T{
+Description
+T}
+.T&
+l l
+l l
+l l
+l l
+l l
+l l.
+T{
+++MagicBytes
+T}:T{
+SVGigaPixelImage
+T}
+T{
+++VersionBytes
+T}:T{
+Format version, e\&.g\&. 1\&.0\&.0
+T}
+T{
+Header
+T}:T{
+A small binary structure\&. The first 12 bytes are little\-endian 32\-bit integers: tile size in pixels, image width in pixels, image height in pixels\&.
+T}
+T{
+TOTAL_SIZE
+T}:T{
+The data field is empty\&. The size field is the sum of all other size fields except ++MagicBytes and ++VersionBytes\&.
+T}
+T{
+T;2048|4096;4;2;0
+T}:T{
+Image tile with downsample 4, X coordinate 2048, Y coordinate 4096, channel 2 (blue)
+T}
+T{
+T;2048|4096;4;2;0#
+T}:T{
+MD5 hash of the T;2048|4096;4;2;0 image tile
+T}
+.TE
+.sp 1
+.SS "Associated Images"
+.PP
+label
+.RS 4
+SVScannedImageDataXPO\&.Image
+corresponding to
+SVSlideDataXPO\&.m_labelScan
+.RE
+.PP
+macro
+.RS 4
+SVScannedImageDataXPO\&.Image
+corresponding to
+SVSlideDataXPO\&.m_overviewScan
+.RE
+.PP
+thumbnail
+.RS 4
+
+SVHRScanDataXPO\&.ThumbnailImage
+.RE
+.SS "Known Properties"
+.PP
+sakura\&.Creator
+.RS 4
+
+SVSlideDataXPO\&.Creator
+.RE
+.PP
+sakura\&.Date
+.RS 4
+
+SVSlideDataXPO\&.Date
+.RE
+.PP
+sakura\&.Description
+.RS 4
+
+SVSlideDataXPO\&.Description
+.RE
+.PP
+sakura\&.DiagnosisCode
+.RS 4
+
+SVSlideDataXPO\&.DiagnosisCode
+.RE
+.PP
+sakura\&.FocussingMethod
+.RS 4
+
+SVHRScanDataXPO\&.FocussingMethod
+.RE
+.PP
+sakura\&.Keywords
+.RS 4
+
+SVSlideDataXPO\&.Keywords
+.RE
+.PP
+sakura\&.NominalLensMagnification
+.RS 4
+
+SVHRScanDataXPO\&.NominalLensMagnification
+.RE
+.PP
+sakura\&.ResolutionMmPerPix
+.RS 4
+
+SVHRScanDataXPO\&.ResolutionMmPerPix
+.RE
+.PP
+sakura\&.ScanId
+.RS 4
+
+SVHRScanDataXPO\&.ScanId
+.RE
+.PP
+sakura\&.SlideId
+.RS 4
+
+SVSlideDataXPO\&.SlideId
+.RE
+.PP
+openslide\&.mpp\-x
+.RS 4
+calculated as
+1000 * sakura\&.ResolutionMmPerPix
+.RE
+.PP
+openslide\&.mpp\-y
+.RS 4
+calculated as
+1000 * sakura\&.ResolutionMmPerPix
+.RE
+.PP
+openslide\&.objective\-power
+.RS 4
+normalized
+sakura\&.NominalLensMagnification
+.RE
+.SS "Test Data"
+.PP
+No public data available\&. Contact the
+\m[blue]\fBmailing list\fR\m[]\&\s-2\u[4]\d\s+2
+if you have some\&.
+.SH "GENERIC TILED TIFF FORMAT"
+.PP
+Format
+.RS 4
+single\-file pyramidal tiled TIFF
+.RE
+.PP
+File extensions
+.RS 4
+
+\&.tif
+.RE
+.PP
+OpenSlide vendor backend
+.RS 4
+
+generic\-tiff
+.RE
+.SS "Detection"
+.PP
+OpenSlide will detect a file as generic TIFF if:
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 1.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 1." 4.2
+.\}
+No other detections succeed\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 2.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 2." 4.2
+.\}
+The file is TIFF\&.
+.RE
+.sp
+.RS 4
+.ie n \{\
+\h'-04' 3.\h'+01'\c
+.\}
+.el \{\
+.sp -1
+.IP " 3." 4.2
+.\}
+The initial image is tiled\&.
+.RE
+.SS "TIFF Image Directory Organization"
+.PP
+The first image in the TIFF file is the full\-resolution image\&. Any other tiled images in the file with the \(lqreduced resolution\(rq bit set are assumed to be reduced\-resolution versions of the original\&.
+.SS "Associated Images"
+.PP
+None\&.
+.SS "Known Properties"
+.PP
+Many TIFF tags are encoded as properties starting with \(rqtiff\&.\(rq\&.
+.SH "AUTHORS"
+.PP
+The Carnegie Mellon School of Computer Science\&.
+.PP
+This manual page was written by Mathieu Malaterre <malat at debian\&.org> for the Debian GNU/Linux system (but may be used by others)\&.
+.SH "NOTES"
+.IP " 1." 4
+Supported Virtual Slide Formats
+.RS 4
+\%http://openslide.org/formats/
+.RE
+.IP " 2." 4
+issue 21
+.RS 4
+\%http://openslide.orghttps://github.com/openslide/openslide/issues/21#issuecomment-23615583
+.RE
+.IP " 3." 4
+Introduction to MIRAX/MRXS
+.RS 4
+\%http://lists.andrew.cmu.edu/pipermail/openslide-users/2012-July/000373.html
+.RE
+.IP " 4." 4
+mailing list
+.RS 4
+\%http://lists.andrew.cmu.edu/mailman/listinfo/openslide-users/
+.RE
Copied: trunk/packages/openslide/trunk/debian/openslide-formats.3.xml (from rev 15850, trunk/packages/openslide/trunk/debian/openslide-show-properties.1.xml)
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-formats.3.xml (rev 0)
+++ trunk/packages/openslide/trunk/debian/openslide-formats.3.xml 2014-01-26 08:30:43 UTC (rev 15851)
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="utf-8"?>
+<?xml-stylesheet type="text/xsl" href="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" ?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<refentry id="openslide-formats">
+ <refmeta>
+ <refentrytitle>OPENSLIDE-FORMATS</refentrytitle>
+ <manvolnum>3</manvolnum>
+ <refmiscinfo class="source">OpenSlide</refmiscinfo>
+ <refmiscinfo class="version">VER_FULL</refmiscinfo>
+ <refmiscinfo class="manual">File Formats</refmiscinfo>
+ </refmeta>
+ <refnamediv>
+ <refname>openslide-formats</refname>
+ <refpurpose>Reference supported formats</refpurpose>
+ </refnamediv>
+ <refsection id="description">
+ <title>DESCRIPTION</title>
+ </refsection>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../ListofKnownProperties.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../Trestleformat.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../Hamamatsuformat.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../Aperioformat.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../MIRAXformat.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../Sakuraformat.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../GenerictiledTIFFformat.xml"/>
+ <refsect1 id="authors">
+ <title>AUTHORS</title>
+ <para>The Carnegie Mellon School of Computer Science.</para>
+ <para>This manual page was written by Mathieu Malaterre
+<malat at debian.org> for the Debian GNU/Linux system (but may be used by others).</para>
+ </refsect1>
+</refentry>
Deleted: trunk/packages/openslide/trunk/debian/openslide-quickhash1sum.1
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-quickhash1sum.1 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/openslide-quickhash1sum.1 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,26 +0,0 @@
-.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.38.2.
-.TH OPENSLIDE-QUICKHASH1SUM "1" "April 2013" "openslide-quickhash1sum 3.3.3" "User Commands"
-.SH NAME
-Print OpenSlide quickhash-1 (256-bit) checksums
-.SH DESCRIPTION
-.SS "Usage:"
-.IP
-openslide\-quickhash1sum [OPTION...] FILE...
-.PP
-Print OpenSlide quickhash\-1 (256\-bit) checksums.
-.SS "Help Options:"
-.TP
-\fB\-h\fR, \fB\-\-help\fR
-Show help options
-.SS "Application Options:"
-.TP
-\fB\-\-version\fR
-Show version
-.SH AUTHOR
-The Carnegie Mellon School of Computer Science.
-
-This manual page was written by Mathieu Malaterre <malat at debian.org> for
-the Debian GNU/Linux system, but may be used by others.
-.SH "SEE ALSO"
-.IR openslide-write-png(1),
-.IR openslide-show-properties(1)
Deleted: trunk/packages/openslide/trunk/debian/openslide-quickhash1sum.1.in
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-quickhash1sum.1.in 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/openslide-quickhash1sum.1.in 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,12 +0,0 @@
-[NAME]
-Print OpenSlide quickhash-1 (256-bit) checksums
-
-[SEE ALSO]
-.IR openslide-write-png(1),
-.IR openslide-show-properties(1)
-
-[AUTHOR]
-The Carnegie Mellon School of Computer Science.
-
-This manual page was written by Mathieu Malaterre <malat at debian.org> for
-the Debian GNU/Linux system, but may be used by others.
Deleted: trunk/packages/openslide/trunk/debian/openslide-show-properties.1
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-show-properties.1 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/openslide-show-properties.1 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,1929 +0,0 @@
-'\" t
-.\" Title: OPENSLIDE-SHOW-PROPERTIES
-.\" Author: [see the "AUTHORS" section]
-.\" Generator: DocBook XSL Stylesheets v1.75.2 <http://docbook.sf.net/>
-.\" Date: 04/17/2013
-.\" Manual: Users Commands
-.\" Source: OpenSlide 3.3.3
-.\" Language: English
-.\"
-.TH "OPENSLIDE\-SHOW\-PRO" "1" "04/17/2013" "OpenSlide 3\&.3\&.3" "Users Commands"
-.\" -----------------------------------------------------------------
-.\" * Define some portability stuff
-.\" -----------------------------------------------------------------
-.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.\" http://bugs.debian.org/507673
-.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
-.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.ie \n(.g .ds Aq \(aq
-.el .ds Aq '
-.\" -----------------------------------------------------------------
-.\" * set default formatting
-.\" -----------------------------------------------------------------
-.\" disable hyphenation
-.nh
-.\" disable justification (adjust text to left margin only)
-.ad l
-.\" -----------------------------------------------------------------
-.\" * MAIN CONTENT STARTS HERE *
-.\" -----------------------------------------------------------------
-.SH "NAME"
-openslide-show-properties \- Print OpenSlide properties
-.SH "SYNOPSIS"
-.HP \w'\fBopenslide\-show\-properties\fR\ 'u
-\fBopenslide\-show\-properties\fR \fIinfile\fR
-.br
-
-.SH "DESCRIPTION"
-.PP
-Print OpenSlide properties\&.
-.SH "LIST OF KNOWN PROPERTIES"
-.SS "Properties generated by OpenSlide"
-.PP
-openslide\&.background\-color
-.RS 4
-The background color of the slide, given as an RGB hex triplet\&. This property is not always present\&.
-.RE
-.PP
-openslide\&.comment
-.RS 4
-A free\-form text comment\&.
-.RE
-.PP
-openslide\&.mpp\-x
-.RS 4
-Microns per pixel in the X dimension of level 0\&. May not be present or accurate\&.
-.RE
-.PP
-openslide\&.mpp\-y
-.RS 4
-Microns per pixel in the Y dimension of level 0\&. May not be present or accurate\&.
-.RE
-.PP
-openslide\&.objective\-power
-.RS 4
-Magnification power of the objective\&. Often inaccurate; sometimes missing\&.
-.RE
-.PP
-openslide\&.quickhash\-1
-.RS 4
-A non\-cryptographic hash of a subset of the slide data\&. It can be used to uniquely identify a particular virtual slide, but cannot be used to detect file corruption or modification\&.
-.RE
-.PP
-openslide\&.vendor
-.RS 4
-The name of the vendor backend\&.
-.RE
-.SS "Properties from the JPEG backend"
-.PP
-No properties defined\&.
-.SS "Properties from the TIFF backend"
-.PP
-tiff\&.Artist
-.RS 4
-The contents of the TIFF Artist tag\&.
-.RE
-.PP
-tiff\&.Copyright
-.RS 4
-The contents of the TIFF Copyright tag\&.
-.RE
-.PP
-tiff\&.DateTime
-.RS 4
-The contents of the TIFF DateTime tag\&.
-.RE
-.PP
-tiff\&.DocumentName
-.RS 4
-The contents of the TIFF DocumentName tag\&.
-.RE
-.PP
-tiff\&.HostComputer
-.RS 4
-The contents of the TIFF HostComputer tag\&.
-.RE
-.PP
-tiff\&.ImageDescription
-.RS 4
-The contents of the TIFF ImageDescripton tag\&.
-.RE
-.PP
-tiff\&.Make
-.RS 4
-The contents of the TIFF Make tag\&.
-.RE
-.PP
-tiff\&.Model
-.RS 4
-The contents of the TIFF Model tag\&.
-.RE
-.PP
-tiff\&.ResolutionUnit
-.RS 4
-The contents of the TIFF ResolutionUnit tag\&.
-.RE
-.PP
-tiff\&.Software
-.RS 4
-The contents of the TIFF Software tag\&.
-.RE
-.PP
-tiff\&.XPosition
-.RS 4
-The contents of the TIFF XPosition tag\&.
-.RE
-.PP
-tiff\&.XResolution
-.RS 4
-The contents of the TIFF XResolution tag\&.
-.RE
-.PP
-tiff\&.YPosition
-.RS 4
-The contents of the TIFF YPosition tag\&.
-.RE
-.PP
-tiff\&.YResolution
-.RS 4
-The contents of the TIFF YResolution tag\&.
-.RE
-.SS "Vendor\-specific properties"
-.PP
-A list of vendor\-specific properties can be found on the pages for each vendor format, linked from
-\m[blue]\fBSupported Virtual Slide Formats\fR\m[]\&\s-2\u[1]\d\s+2\&.
-.SH "TRESTLE FORMAT"
-.PP
-Format
-.RS 4
-single\-file pyramidal tiled TIFF, with non\-standard metadata and overlaps; additional files can contain more metadata and detailed overlap info
-.RE
-.PP
-File extensions
-.RS 4
-
-\&.tif
-.RE
-.PP
-OpenSlide vendor backend
-.RS 4
-
-trestle
-.RE
-.PP
-OpenSlide ops backend
-.RS 4
-
-tiff
-.RE
-.SS "Detection"
-.PP
-Trestle slides are stored in single\-file TIFF format\&. OpenSlide will detect a file as Trestle if:
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 1.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 1." 4.2
-.\}
-The file is TIFF\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 2.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 2." 4.2
-.\}
-The TIFF
-Software
-tag starts with \(rqMedScan\(rq\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 3.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 3." 4.2
-.\}
-The
-ImageDescription
-tag is present\&.
-.RE
-.SS "Relevant TIFF tags"
-.TS
-allbox tab(:);
-lB lB.
-T{
-Tag
-T}:T{
-Description
-T}
-.T&
-l l
-l l
-l l.
-T{
-ImageDescription
-T}:T{
-Stores some important key\-value pairs, see below
-T}
-T{
-Software
-T}:T{
-Starts with \(rqMedScan\(rq
-T}
-T{
-XResolution, YResolution
-T}:T{
-Seems to store microns\-per\-pixel (MPP), which may or may not take into account the correct objective power\&. Note that this is inverted from standard TIFF, which stores pixels\-per\-unit, not units\-per\-pixel\&.
-T}
-.TE
-.sp 1
-.SS "Extra data stored in ImageDescription"
-.PP
-The
-ImageDescription
-tag contains semicolon\-delimited key\-value pairs\&. A key\-value pair is equals\-delimited\&. We use the
-OverlapsXY
-and
-Background Color
-keys from the
-ImageDescription, and ignore the rest\&. All of these values are stored as properties starting with \(rqtrestle\&.\(rq\&.
-.TS
-allbox tab(:);
-lB lB.
-T{
-Key
-T}:T{
-Description
-T}
-.T&
-l l
-l l
-l l
-l l
-l l.
-T{
-Background Color
-T}:T{
-Hex\-encoded background color info, assumed to be in the format RRGGBB\&.
-T}
-T{
-White Balance
-T}:T{
-Hex\-encoded white balance
-T}
-T{
-Objective Power
-T}:T{
-Reported objective power, often incorrect\&.
-T}
-T{
-JPEG Quality
-T}:T{
-The JPEG quality value\&.
-T}
-T{
-OverlapsXY
-T}:T{
-Overlaps, see below\&.
-T}
-.TE
-.sp 1
-.SS "TIFF Image Directory Organization"
-.PP
-The first image in the TIFF file is the full\-resolution image\&. The subsequent images are assumed to be decreasingly sized reduced\-resolution images\&.
-.SS "Overlaps"
-.PP
-The
-OverlapsXY
-pseudo\-field encodes a list of tile overlap values as ASCII\&.
-.PP
-Example: \(rq64 64 32 32 16 16\(rq (note the initial space)\&.
-.PP
-These values are assumed to represent the amount of overlap between adjacent tiles in pixels, in both X and Y\&. This example encodes 3 levels worth of overlaps\&. Further overlaps are assumed to have the value 0\&.
-.SS "Associated Images"
-.PP
-macro
-.RS 4
-the image with a filename extension of \(rq\&.Full\(rq (optional)
-.RE
-.SS "Known Properties"
-.PP
-All data encoded in the
-ImageDescription
-TIFF field is represented as properties prefixed with \(rqtrestle\&.\(rq\&.
-.PP
-openslide\&.mpp\-x
-.RS 4
-copy of
-tiff\&.XResolution
-(note that this is a totally non\-standard use of this TIFF tag)
-.RE
-.PP
-openslide\&.mpp\-y
-.RS 4
-copy of
-tiff\&.YResolution
-(note that this is a totally non\-standard use of this TIFF tag)
-.RE
-.PP
-openslide\&.objective\-power
-.RS 4
-normalized
-trestle\&.Objective Power
-.RE
-.SS "Test Data"
-.PP
-
-\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Trestle/\fR\m[]
-.SH "HAMAMATSU FORMAT"
-.PP
-Format
-.RS 4
-multi\-file JPEG/NGR with proprietary metadata and index file formats
-.RE
-.PP
-File extensions
-.RS 4
-\&.vms,
-\&.vmu
-.RE
-.PP
-OpenSlide vendor backend
-.RS 4
-
-hamamatsu
-.RE
-.PP
-OpenSlide ops backend
-.RS 4
-jpeg
-for
-\&.vms,
-ngr
-for
-\&.vmu
-.RE
-.SS "Detection"
-.PP
-OpenSlide will detect a file as Hamamatsu if:
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 1.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 1." 4.2
-.\}
-The file given is a INI\-style text file\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 2.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 2." 4.2
-.\}
-It has a
-[Virtual Microscope Specimen]
-(VMS) or
-[Uncompressed Virtual Microscope Specimen]
-(VMU) group\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 3.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 3." 4.2
-.\}
-The file specifies a positive number of layer (NoLayers>=1)\&. Currently, only one of these focal plane layers is read\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 4.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 4." 4.2
-.\}
-If VMS, there are at least 1 row and 1 column of JPEG images (NoJpegColumns
-and
-NoJpegRows)\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 5.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 5." 4.2
-.\}
-The mapfile given by
-MapFile
-is a valid readable file in the same directory as the VMS file\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 6.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 6." 4.2
-.\}
-The files given by the various
-ImageFile
-lines do not exceed the number of rows and columns as specified above\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 7.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 7." 4.2
-.\}
-The mapfile and image files are all valid JPEG files or all valid NGR files\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 8.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 8." 4.2
-.\}
-The restart interval in each JPEG file is zero, or evenly divides into the number of MCUs per row\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 9.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 9." 4.2
-.\}
-The image files (except the map file) all have the same \(lqtile\(rq sizes (see below)\&.
-.RE
-.SS "Overview"
-.PP
-The Hamamatsu format consists of an index file (VMS or VMU), 2 or more image files, and (in the case of VMS) an \(lqoptimisation\(rq file\&.
-.PP
-Multiple focal planes are ignored, only focal plane 0 is read\&.
-.PP
-Because JPEG does not allow for large files, multiple JPEG files are needed to encode large images\&. To avoid having many files, the Hamamatsu format uses close to maximum size (65K by 65K) JPEG files\&.
-.PP
-Unfortunately, (unlike TIFF) JPEG provides very poor support for random\-access decoding of parts of a file\&. To get around this, JPEG restart markers are placed at regular intervals, and these offsets are specified in the optimisation file\&. With restart markers identified, OpenSlide can treat JPEG as a tiled format, where the height is the height of an MCU row, and the width is the number of MCUs per row divided by the restart marker interval times the width of an MCU\&. (This often leads to oddly\-shaped and inefficient tiles of 8x2048, for example\&.)
-.PP
-Unfortunately, the optimisation file does not give the location of every restart marker, only the ones found at the beginning of an MCU row\&. It also seems that the file ends early, and does not give the location of the restart marker at the last MCU row of the last image file\&.
-.PP
-Thus, the optimisation file can only be taken as a hint, and cannot be trusted\&. The entire set of JPEG files must be scanned for restart markers in order to facilitate random access\&. OpenSlide does this lazily as needed, and also in a background thread that runs only when OpenSlide is otherwise idle\&.
-.PP
-The map file is a lower\-resolution version of the other images, and can be used to make a 2\-level JPEG pyramid\&. JPEG also allows for lower\-resolution decoding, so further pyramid levels are synthesized from each JPEG file\&.
-.SS "VMS File"
-.PP
-The
-\&.vms
-file is the main index file for the VMS format\&. It is a Windows INI\-style key\-value pair file, with sections\&. Only keys in the
-Virtual Microscope Specimen
-group are read by OpenSlide\&.
-.PP
-Here are known keys from the file:
-.TS
-allbox tab(:);
-lB lB.
-T{
-Key
-T}:T{
-Description
-T}
-.T&
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l.
-T{
-NoLayers
-T}:T{
-Number of layers, currently must be 1 to be accepted
-T}
-T{
-NoJpegColumns
-T}:T{
-Number of JPEG files across, given in ImageFile attributes
-T}
-T{
-NoJpegRows
-T}:T{
-Number of JPEG files down, given in ImageFile attributes
-T}
-T{
-ImageFile
-T}:T{
-Semantically equivalent to ImageFile(0,0,0), though not specified that way\&. The image in position (0,0,0) of the set of images
-T}
-T{
-ImageFile(x,y)
-T}:T{
-Semantically equivalent to ImageFile(0,x,y), though not specified that way\&. The image in position (0,x,y) of the set of images
-T}
-T{
-ImageFile(z,x,y)
-T}:T{
-Where x and y are non\-negative integers\&. Both x and y cannot be 0\&. z is a positive integer\&. These are the images that make up the virtual slide, as a concatenation of JPEG images\&. x and y specify the location of each JPEG, z specifies the focal plane
-T}
-T{
-MapFile
-T}:T{
-A lower\-resolution version of all the ImageFiles
-T}
-T{
-OptimisationFile
-T}:T{
-File specifying some of the restart marker offsets in each ImageFile
-T}
-T{
-AuthCode
-T}:T{
-Unknown
-T}
-T{
-SourceLens
-T}:T{
-Apparently the magnification
-T}
-T{
-PhysicalWidth
-T}:T{
-Width of the slide in some unit?
-T}
-T{
-PhysicalHeight
-T}:T{
-Height of the slide in some unit?
-T}
-T{
-LayerSpacing
-T}:T{
-Unknown
-T}
-T{
-MacroImage
-T}:T{
-Image file for the \(lqmacro\(rq associated image
-T}
-T{
-PhysicalMacroWidth
-T}:T{
-Unknown
-T}
-T{
-PhysicalMacroHeight
-T}:T{
-Unknown
-T}
-T{
-XOffsetFromSlideCentre
-T}:T{
-Unknown
-T}
-T{
-YOffsetFromSlideCentre
-T}:T{
-Unknown
-T}
-.TE
-.sp 1
-.SS "VMU File"
-.PP
-The
-\&.vmu
-file is the main index file for the VMU format\&. Only keys in the
-Uncompressed Virtual Microscope Specimen
-group are read by OpenSlide\&.
-.PP
-Here are known keys from the file:
-.TS
-allbox tab(:);
-lB lB.
-T{
-Key
-T}:T{
-Description
-T}
-.T&
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l.
-T{
-NoLayers
-T}:T{
-(see VMS above)
-T}
-T{
-ImageFile
-T}:T{
-(see VMS above)
-T}
-T{
-ImageFile(x,y)
-T}:T{
-(see VMS above)
-T}
-T{
-ImageFile(z,x,y)
-T}:T{
-(see VMS above)
-T}
-T{
-MapFile
-T}:T{
-(see VMS above)
-T}
-T{
-MapScale
-T}:T{
-Seems to be the downsample factor of the map
-T}
-T{
-AuthCode
-T}:T{
-(see VMS above)
-T}
-T{
-SourceLens
-T}:T{
-(see VMS above)
-T}
-T{
-PixelWidth
-T}:T{
-Width of the image in pixels
-T}
-T{
-PixelHeight
-T}:T{
-Height of the image in pixels
-T}
-T{
-PhysicalWidth
-T}:T{
-(see VMS above)
-T}
-T{
-PhysicalHeight
-T}:T{
-(see VMS above)
-T}
-T{
-LayerSpacing
-T}:T{
-(see VMS above)
-T}
-T{
-LayerOffset
-T}:T{
-Unknown
-T}
-T{
-MacroImage
-T}:T{
-(see VMS above)
-T}
-T{
-PhysicalMacroWidth
-T}:T{
-(see VMS above)
-T}
-T{
-PhysicalMacroHeight
-T}:T{
-(see VMS above)
-T}
-T{
-XOffsetFromSlideCentre
-T}:T{
-(see VMS above)
-T}
-T{
-YOffsetFromSlideCentre
-T}:T{
-(see VMS above)
-T}
-T{
-Reference
-T}:T{
-Unknown
-T}
-T{
-BitsPerPixel
-T}:T{
-Bits per pixel, currently expected to be 36
-T}
-T{
-PixelOrder
-T}:T{
-Currently expected to be RGB
-T}
-T{
-Creator
-T}:T{
-String describing the software creating this image
-T}
-T{
-IlluminationMode
-T}:T{
-Unknown
-T}
-T{
-ExposureMultiplier
-T}:T{
-Unknown, possibly the multiplier used to scale to 15 bits?
-T}
-T{
-GainRed
-T}:T{
-Unknown
-T}
-T{
-GainGreen
-T}:T{
-Unknown
-T}
-T{
-GainBlue
-T}:T{
-Unknown
-T}
-T{
-FocalPlaneTolerance
-T}:T{
-Unknown
-T}
-T{
-NMP
-T}:T{
-Unknown
-T}
-T{
-MacroIllumination
-T}:T{
-Unknown
-T}
-T{
-FocusOffset
-T}:T{
-Unknown
-T}
-T{
-RefocusInterval
-T}:T{
-Unknown
-T}
-T{
-CubeName
-T}:T{
-Unknown
-T}
-T{
-HardwareModel
-T}:T{
-Name of the hardware
-T}
-T{
-HardwareSerial
-T}:T{
-Serial number of the hardware
-T}
-T{
-NoFocusPoints
-T}:T{
-Unknown
-T}
-T{
-FocusPoint0X
-T}:T{
-Unknown
-T}
-T{
-FocusPoint0Y
-T}:T{
-Unknown
-T}
-T{
-FocusPoint0Z
-T}:T{
-Unknown
-T}
-T{
-FocusPoint1X
-T}:T{
-Unknown
-T}
-T{
-FocusPoint1Y
-T}:T{
-Unknown
-T}
-T{
-FocusPoint1Z
-T}:T{
-Unknown
-T}
-T{
-FocusPoint2X
-T}:T{
-Unknown
-T}
-T{
-FocusPoint2Y
-T}:T{
-Unknown
-T}
-T{
-FocusPoint2Z
-T}:T{
-Unknown
-T}
-T{
-FocusPoint3X
-T}:T{
-Unknown
-T}
-T{
-FocusPoint3Y
-T}:T{
-Unknown
-T}
-T{
-FocusPoint3Z
-T}:T{
-Unknown
-T}
-T{
-NoBlobPoints
-T}:T{
-Unknown
-T}
-T{
-BlobPoint0Blob
-T}:T{
-Unknown
-T}
-T{
-BlobPoint0FocusPoint
-T}:T{
-Unknown
-T}
-T{
-BlobPoint1Blob
-T}:T{
-Unknown
-T}
-T{
-BlobPoint1FocusPoint
-T}:T{
-Unknown
-T}
-T{
-BlobPoint2Blob
-T}:T{
-Unknown
-T}
-T{
-BlobPoint2FocusPoint
-T}:T{
-Unknown
-T}
-T{
-BlobPoint3Blob
-T}:T{
-Unknown
-T}
-T{
-BlobPoint3FocusPoint
-T}:T{
-Unknown
-T}
-T{
-BlobMapWidth
-T}:T{
-Unknown
-T}
-T{
-BlobMapHeight
-T}:T{
-Unknown
-T}
-.TE
-.sp 1
-.SS "Optimisation File (only for VMS)"
-.PP
-The optimisation file contains a list of 32\- (or 64\- or 320\- ?) bit little endian values, giving the file offset into an MCU row, each offset starts at a 40\-byte alignment, and the last row (of the entire file, not each image) seems to be missing\&. The offsets are all packed into 1 file, even with multiple images\&. The order of images is left\-to\-right, top\-to\-bottom\&.
-.SS "Map File"
-.PP
-The VMS map file is a standard JPEG file\&. Its restart markers (if any) are not included in the optimisation file\&. The VMU map file is in NGR format\&. This file can be used to provide a lower\-resolution view of the slide\&.
-.SS "Image Files"
-.PP
-These files are given by the various
-ImageFile
-keys\&. They are assumed to have a height which is a multiple of the MCU height\&. They are assumed to have a width which is a multiple of MCUs per row divided by the restart interval\&.
-.PP
-For VMS, these files are in JPEG, for VMU they are in NGR format\&.
-.SS "NGR Format"
-.PP
-The NGR file contains uncompressed 16\-bit RGB data, with a small header\&. The files we have encountered start with
-GN, two more bytes, and then width, height, and column width in little endian 32\-bit format\&. The column width must divide evenly into the width\&. Column width is important, since NGR files are generated in columns, where the first column comes first in the file, followed by subsequent files\&. Columns are painted left\-to\-right\&.
-.PP
-At offset 24 is another 32\-bit integer which gives the offset in the file to the start of the image data\&. The image data we have encountered is in 16\-bit little endian format\&.
-.SS "Associated Images"
-.PP
-macro
-.RS 4
-the image file given by the
-MacroImage
-value in the VMS/VMU file
-.RE
-.SS "Known Properties"
-.PP
-All key\-value data stored in the VMS/VMU file are encoded as properties prefixed with \(rqhamamatsu\&.\(rq\&.
-.PP
-openslide\&.objective\-power
-.RS 4
-normalized
-hamamatsu\&.SourceLens
-.RE
-.SS "Test Data"
-.PP
-\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Hamamatsu/\fR\m[]
-(ndpi format, wrapped vms format, currently not readable by OpenSlide)
-.PP
-\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Hamamatsu\-vms/\fR\m[]
-(vms format)
-.SS "Preliminary NDPI Notes"
-.PP
-NDPI is basically VMS stuffed into a broken TIFF file\&. libtiff cannot read the headers of a TIFF file, because NDPI specifies the
-RowsPerStrip
-as the height of the file, and after doing out the multiplication, this typically overflows libtiff and it refuses to open the file\&. Also, the TIFF tags are not stored in sorted order (sometimes, they may have fixed this in later versions)\&.
-.PP
-Unlike the VMS format, the NDPI is stored in a pyramid format as TIFF directory entries\&. The macro image seems to come last\&.
-.PP
-If one just reads the TIFF tags directly, perhaps using
-tiffdump, one will find:
-.TS
-allbox tab(:);
-lB lB.
-T{
-Tag
-T}:T{
-Description
-T}
-.T&
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l
-l l.
-T{
-ImageWidth
-T}:T{
-Width of the image
-T}
-T{
-ImageHeight
-T}:T{
-Height of the image
-T}
-T{
-Make
-T}:T{
-\(lqHamamatsu\(rq
-T}
-T{
-Model
-T}:T{
-\(lqNanoZoomer\(rq or \(lqC9600\-12\(rq, etc
-T}
-T{
-XResolution
-T}:T{
-Seemingly correct X resolution, when interpreted with ResolutionUnit
-T}
-T{
-YResolution
-T}:T{
-Seemingly correct Y resolution, when interpreted with ResolutionUnit
-T}
-T{
-ResolutionUnit
-T}:T{
-Seemingly correct resolution unit
-T}
-T{
-Software
-T}:T{
-\(lqNDP\&.scan\(rq, sometimes with a version number
-T}
-T{
-StripOffsets
-T}:T{
-The offset of the JPEG file for this layer
-T}
-T{
-StripByteCounts
-T}:T{
-The length of the JPEG file for this layer
-T}
-T{
-65420
-T}:T{
-Unknown, always 1?
-T}
-T{
-65421
-T}:T{
-Magnification? SourceLens from VMS? Seems correctly downsampled for each entry\&. (\-1 for macro image, \-2 for some sort of mask?)
-T}
-T{
-65422
-T}:T{
-XOffsetFromSlideCentre
-T}
-T{
-65423
-T}:T{
-YOffsetFromSlideCentre
-T}
-T{
-65424
-T}:T{
-Unknown, always 0?
-T}
-T{
-65425
-T}:T{
-Unknown, always 0?
-T}
-T{
-65426
-T}:T{
-Optimisation entries, as above
-T}
-T{
-65427
-T}:T{
-Unknown, possibly slide identifier
-T}
-T{
-65428
-T}:T{
-Unknown, AuthCode?
-T}
-T{
-65433
-T}:T{
-Unknown, I have seen 1500 in this tag
-T}
-T{
-65439
-T}:T{
-Unknown, perhaps some polygon ROI?
-T}
-T{
-65440
-T}:T{
-Unknown, I have seen this: <0 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 1 9 1 10 1 11 1 12 1 13 1 14 1 15 1 16 1 17>
-T}
-T{
-65441
-T}:T{
-Unknown, always 0?
-T}
-T{
-65442
-T}:T{
-Seems to be Model
-T}
-T{
-65443
-T}:T{
-Unknown, always 0?
-T}
-T{
-65444
-T}:T{
-Unknown, always 80?
-T}
-T{
-65445
-T}:T{
-Unknown, have seen 0 or 2
-T}
-T{
-65446
-T}:T{
-Unknown, always 0?
-T}
-T{
-65449
-T}:T{
-ASCII metadata block, not always present
-T}
-.TE
-.sp 1
-.PP
-Unlike in VMS, JPEG files in NDPI are not necessarily valid\&. If
-ImageWidth
-or
-ImageHeight
-exceeds the JPEG limit of 65535, then the width or height as stored in the JPEG file is 0\&. JPEG files are not split into validly\-sized files like in VMS\&. libjpeg will refuse to read the header of such a file, so the JPEG data stream must be altered when fed into libjpeg\&. Since a random access source manager is already required to read VMS JPEG files, this change is not too bad\&.
-.SH "APERIO FORMAT"
-.PP
-Format
-.RS 4
-single\-file pyramidal tiled TIFF, with non\-standard metadata and compression
-.RE
-.PP
-File extensions
-.RS 4
-\&.svs,
-\&.tif
-.RE
-.PP
-OpenSlide vendor backend
-.RS 4
-
-aperio
-.RE
-.PP
-OpenSlide ops backend
-.RS 4
-
-tiff
-.RE
-.SS "Vendor Documentation"
-.PP
-
-\m[blue]\fBhttp://www\&.aperio\&.com/documents/api/Aperio_Digital_Slides_and_Third\-party_data_interchange\&.pdf\fR\m[]
-.SS "Detection"
-.PP
-Aperio slides are stored in single\-file TIFF format\&. OpenSlide will detect a file as Aperio if:
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 1.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 1." 4.2
-.\}
-The file is TIFF\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 2.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 2." 4.2
-.\}
-The
-ImageDescription
-tag starts with
-Aperio\&.
-.RE
-.SS "Relevant TIFF tags"
-.TS
-allbox tab(:);
-lB lB.
-T{
-Tag
-T}:T{
-Description
-T}
-.T&
-l l
-l l.
-T{
-ImageDescription
-T}:T{
-Stores some important key\-value pairs and other information, see below
-T}
-T{
-Compression
-T}:T{
-May be 33003 or 33005, which represent specific kinds of JPEG 2000 compression, see below
-T}
-.TE
-.sp 1
-.SS "Extra data stored in ImageDescription"
-.PP
-For tiled images, the
-ImageDescription
-tag contains some dimensional downsample information as well as what look like offsets\&. Additionally, vertical line\-delimited key\-value pairs are stored, in at least the full\-resolution image\&. A key\-value pair is equals\-delimited\&. These key\-values are stored as properties starting with \(rqaperio\&.\(rq\&. Currently, OpenSlide does not use any of the information present in these key\-value fields\&.
-.PP
-For stripped images, the
-ImageDescription
-tag may contain a name, followed by a carriage return\&. This is used for naming the associated images\&. The second image in the file does not have a name, though it is an associated image\&.
-.SS "TIFF Image Directory Organization"
-.PP
-\m[blue]\fBhttp://www\&.aperio\&.com/documents/api/Aperio_Digital_Slides_and_Third\-party_data_interchange\&.pdf\fR\m[]
-page 14:
-.PP
-The first image in an SVS file is always the baseline image (full resolution)\&. This image is always tiled, usually with a tile size of 240x240 pixels\&. The second image is always a thumbnail, typically with dimensions of about 1024x768 pixels\&. Unlike the other slide images, the thumbnail image is always stripped\&. Following the thumbnail there may be one or more intermediate \(lqpyramid\(rq images\&. These are always compressed with the same type of compression as the baseline image, and have a tiled organization with the same tile size\&.
-.PP
-Optionally at the end of an SVS file there may be a slide label image, which is a low resolution picture taken of the slide\(cqs label, and/or a macro camera image, which is a low resolution picture taken of the entire slide\&. The label and macro images are always stripped\&.
-.SS "JPEG 2000 (compression types 33003 or 33005)"
-.PP
-Some Aperio files use compression type 33003 or 33005\&. Images using this compression need to be decoded as a JPEG 2000 codestream\&. For 33003: YCbCr format, possibly with a chroma subsampling of 4:2:2\&. For 33005: RGB format\&. Note that the TIFF file may not encode the colorspace or subsampling parameters in the
-PhotometricInterpretation
-field, nor the
-YCbCrSubsampling
-field, even though the TIFF standard seems to require this\&. The correct subsampling can be found in the JPEG 2000 codestream\&.
-.SS "Associated Images"
-.PP
-thumbnail
-.RS 4
-the second image in the file
-.RE
-.PP
-label
-.RS 4
-optional, the name \(lqlabel\(rq is given in
-ImageDescription
-.RE
-.PP
-macro
-.RS 4
-optional, the name \(lqmacro\(rq is given in
-ImageDescription
-.RE
-.SS "Known Properties"
-.PP
-All key\-value data encoded in the
-ImageDescription
-TIFF field is represented as properties prefixed with \(rqaperio\&.\(rq\&.
-.PP
-openslide\&.mpp\-x
-.RS 4
-normalized
-aperio\&.MPP
-.RE
-.PP
-openslide\&.mpp\-y
-.RS 4
-normalized
-aperio\&.MPP
-.RE
-.PP
-openslide\&.objective\-power
-.RS 4
-normalized
-aperio\&.AppMag
-.RE
-.SS "Test Data"
-.PP
-
-\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Aperio/\fR\m[]
-.SH "MIRAX FORMAT"
-.PP
-Format
-.RS 4
-multi\-file JPEG with very complicated proprietary metadata and indexes
-.RE
-.PP
-File extensions
-.RS 4
-
-\&.mrxs
-.RE
-.PP
-OpenSlide vendor backend
-.RS 4
-
-mirax
-.RE
-.PP
-OpenSlide ops backend
-.RS 4
-
-jpeg
-.RE
-.SS "Detection"
-.PP
-
-\fBNote: MIRAX is incredibly complicated\&. These detection steps are probably not complete\&.\fR
-.PP
-OpenSlide will detect a file as MIRAX if:
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 1.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 1." 4.2
-.\}
-The file ends with
-\&.mrxs\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 2.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 2." 4.2
-.\}
-A directory exists in the same location as the file, with the same name as the file minus the extension\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 3.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 3." 4.2
-.\}
-A file named
-Slidedat\&.ini
-exists in the directory\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 4.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 4." 4.2
-.\}
-The slidedat file is readable as a Windows INI\-style file\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 5.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 5." 4.2
-.\}
-The slidedat file has a
-[GENERAL]
-section with the following keys:
-SLIDE_VERSION,
-SLIDE_ID,
-IMAGENUMBER_X,
-IMAGENUMBER_Y\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 6.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 6." 4.2
-.\}
-The slidedat file has a
-[HIERARCHICAL]
-section with the following keys:
-HIER_COUNT,
-NONHIER_COUNT,
-INDEXFILE\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 7.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 7." 4.2
-.\}
-A key exists in the
-[HIERARCHICAL]
-section with the value of
-Slide zoom level\&. The key matches this printf\-style template:
-HIER_%d_NAME\&. The
-%d
-is bound to the variable
-zoom_level\&. Currently,
-zoom_level
-must be 0\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 8.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 8." 4.2
-.\}
-The
-[HIERARCHICAL]
-section has a key with the name
-HIER_%d_COUNT
-where
-%d
-is the value of
-zoom_level
-in the previous step\&. The value must be an integer, interpreted as
-zoom_count\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 9.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 9." 4.2
-.\}
-Setting
-x
-to
-zoom_level
-and
-y
-from 0 to
-zoom_count, the
-[HIERARCHICAL]
-section has a key with the name
-HIER_x_VAL_y_SECTION\&. Let
-section_names[]
-be an array of length zoom_count, holding the values for each key\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'10.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "10." 4.2
-.\}
-The
-[DATAFILE]
-section must exist, with the following keys:
-FILE_COUNT\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'11.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "11." 4.2
-.\}
-There are
-FILE_COUNT
-keys in the
-[DATAFILE]
-section with the following names:
-FILE_%d, where
-%d
-goes from 0 to
-FILE_COUNT\-1\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'12.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "12." 4.2
-.\}
-For each value in
-section_names, a group must exist with that name\&. Each group must contain the keys:
-OVERLAP_X,
-OVERLAP_Y,
-IMAGE_FILL_COLOR_BGR,
-DIGITIZER_WIDTH,
-DIGITIZER_HEIGHT,
-IMAGE_CONCAT_FACTOR\&. The overlap values must be parseable as doubles, the rest as integers\&. The key
-IMAGE_FORMAT
-must exist, with the value
-JPEG\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'13.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "13." 4.2
-.\}
-The
-[HIERARCHICAL]
-section has a key with the name
-NONHIER_%d_NAME
-(%d
-is an integer) and with the value
-Scan data layer\&. Bind
-%d
-to the variable
-scan_nonhier_offset\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'14.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "14." 4.2
-.\}
-The
-[HIERARCHICAL]
-section has a key with the name
-NONHIER_%d_VAL_%d
-where the first
-%d
-is the value of
-scan_nonhier_offset\&. The key has a value of
-ScanDataLayer_SlideThumbnail\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'15.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "15." 4.2
-.\}
-The
-[HIERARCHICAL]
-section has a key with the name
-NONHIER_%d_VAL_%d
-where the first
-%d
-is the value of
-scan_nonhier_offset\&. The key has a value of
-ScanDataLayer_SlideBarcode\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'16.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "16." 4.2
-.\}
-The
-[HIERARCHICAL]
-section has a key with the name
-NONHIER_%d_VAL_%d
-where the first
-%d
-is the value of
-scan_nonhier_offset\&. The key has a value of
-ScanDataLayer_SlidePreview\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'17.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "17." 4.2
-.\}
-The value of the
-INDEXFILE
-key above is the name of a readable file\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'18.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP "18." 4.2
-.\}
-The index file is of a valid format, and all data referred to by it is valid (see below)\&.
-.RE
-.SS "Overview"
-.PP
-Because JPEG does not allow for large files, multiple JPEG files are needed to encode large images\&.
-.PP
-Unfortunately, (unlike TIFF) JPEG provides very poor support for random\-access decoding of parts of a file\&. To avoid having many individual files, MIRAX packs JPEG files into a small number of data files\&. The index file provides offsets into the data files for each required piece of data\&.
-.PP
-The camera on MIRAX scanners takes overlapping photos and records the position of each one\&. Each photo is then split into multiple JPEG tiles which do not overlap\&. Overlaps only occur between tiles that come from different photos\&.
-.PP
-To generate level
-n + 1, each JPEG tile from level
-n
-is downsampled by 2 and then concatenated into a new JPEG tile, 4 old tiles per new JPEG tile (2 x 2)\&. This process is repeated for each level, irrespective of tile overlaps\&. Therefore, at sufficiently high levels, a single tile can contain one or more embedded overlaps of non\-integral width\&.
-.SS "Index File"
-.PP
-The index file starts with a five\-character ASCII version string, followed by the
-SLIDE_ID
-from the slidedat file\&. The rest of the file consists of 32\-bit little\-endian integers (unaligned), which can be data values or pointers to byte offsets within the index file\&.
-.PP
-The first two integers point to offset tables for the hierarchical and nonhierarchical roots, respectively\&. These tables contain one record for each
-VAL
-in the
-HIERARCHICAL
-slidedat section\&. For example, the record for
-NONHIER_1_VAL_2
-would be stored at
-nonhier_root + 4 * (NONHIER_0_COUNT + 2)\&.
-.PP
-Each record is a pointer to a linked list of data pages\&. The first two values in a data page are the number of data items in the page and a pointer to the next page\&. The first page always has 0 data items, and the last page has a 0 next pointer\&.
-.PP
-There is one hierarchical record for each zoom level\&. The record contains data items consisting of a tile index, offset and length within a file, and a file number\&. The file number can be converted to a data file name via the
-DATAFILE
-slidedat section\&. The tile index is equal to
-tile_y * GENERAL\&.IMAGENUMBER_X + tile_x\&. Tile coordinates which are not multiples of the zoom level\(cqs downsample factor are omitted\&.
-.PP
-Nonhierarchical records refer to associated images and additional metadata\&. Nonhierarchical data items consist of three zero values followed by an offset, length, and file number as in hierarchical records\&.
-.SS "Data Files"
-.PP
-A data file begins with a header containing a five\-character ASCII version string, the
-SLIDE_ID
-from the slidedat file, the file number encoded into three ASCII characters, and 256 bytes of padding\&. The remainder of the file contains packed data referenced by the index file\&.
-.SS "Slide Position File"
-.PP
-The slide position file is referenced by the
-VIMSLIDE_POSITION_BUFFER\&.default
-nonhierarchical section\&. It contains one entry for each camera position (not each tile position) in row\-major order\&. Each entry is nine bytes: a flag byte, the
-X
-pixel coordinate of the photo (4 bytes, little\-endian, may be negative), and the
-Y
-coordinate (4 bytes, little\-endian, may be negative)\&. In slides with
-CURRENT_SLIDE_VERSION
-≥ 1\&.9, the flag byte is 1 if the slide file contains tiles for this camera position, 0 otherwise\&. In older slides, the flag byte is always 0\&.
-.PP
-In slides with
-CURRENT_SLIDE_VERSION
-≥ 2\&.2, the slide position file is compressed with DEFLATE and referenced by the
-StitchingIntensityLayer\&.StitchingIntensityLevel
-nonhierarchical section\&.
-.SS "Associated Images"
-.PP
-thumbnail
-.RS 4
-the image named \(rqScanDataLayer_SlidePreview\(rq in
-Slidedat\&.ini
-(optional)
-.RE
-.PP
-label
-.RS 4
-the image named \(rqScanDataLayer_SlideBarcode\(rq in
-Slidedat\&.ini
-(optional)
-.RE
-.PP
-macro
-.RS 4
-the image named \(rqScanDataLayer_SlideThumbnail\(rq in
-Slidedat\&.ini
-(optional)
-.RE
-.SS "Known Properties"
-.PP
-All key\-value data stored in the
-Slidedat\&.ini
-file are encoded as properties prefixed with \(rqmirax\&.\(rq\&.
-.PP
-openslide\&.mpp\-x
-.RS 4
-normalized
-MICROMETER_PER_PIXEL_X
-from the Slidedat section corresponding to level 0 (typically
-mirax\&.LAYER_0_LEVEL_0_SECTION\&.MICROMETER_PER_PIXEL_X)
-.RE
-.PP
-openslide\&.mpp\-y
-.RS 4
-normalized
-MICROMETER_PER_PIXEL_Y
-from the Slidedat section corresponding to level 0 (typically
-mirax\&.LAYER_0_LEVEL_0_SECTION\&.MICROMETER_PER_PIXEL_Y)
-.RE
-.PP
-openslide\&.objective\-power
-.RS 4
-normalized
-mirax\&.GENERAL\&.OBJECTIVE_MAGNIFICATION
-.RE
-.SS "See Also"
-.PP
-
-\m[blue]\fBIntroduction to MIRAX/MRXS\fR\m[]\&\s-2\u[2]\d\s+2
-.SS "Test Data"
-.PP
-
-\m[blue]\fBhttp://openslide\&.cs\&.cmu\&.edu/download/openslide\-testdata/Mirax/\fR\m[]
-.SH "GENERIC TILED TIFF FORMAT"
-.PP
-Format
-.RS 4
-single\-file pyramidal tiled TIFF
-.RE
-.PP
-File extensions
-.RS 4
-
-\&.tif
-.RE
-.PP
-OpenSlide vendor backend
-.RS 4
-
-generic\-tiff
-.RE
-.PP
-OpenSlide ops backend
-.RS 4
-
-tiff
-.RE
-.SS "Detection"
-.PP
-OpenSlide will detect a file as generic TIFF if:
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 1.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 1." 4.2
-.\}
-No other detections succeed\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 2.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 2." 4.2
-.\}
-The file is TIFF\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04' 3.\h'+01'\c
-.\}
-.el \{\
-.sp -1
-.IP " 3." 4.2
-.\}
-The initial image is tiled\&.
-.RE
-.SS "TIFF Image Directory Organization"
-.PP
-The first image in the TIFF file is the full\-resolution image\&. Any other tiled images in the file with the \(lqreduced resolution\(rq bit set are assumed to be reduced\-resolution versions of the original\&.
-.SS "Associated Images"
-.PP
-None\&.
-.SS "Known Properties"
-.PP
-Many TIFF tags are encoded as properties starting with \(rqtiff\&.\(rq\&.
-.SH "AUTHORS"
-.PP
-The Carnegie Mellon School of Computer Science\&.
-.PP
-This manual page was written by Mathieu Malaterre <malat at debian\&.org> for the Debian GNU/Linux system (but may be used by others)\&.
-.SH "NOTES"
-.IP " 1." 4
-Supported Virtual Slide Formats
-.RS 4
-\%http://openslide.org/formats/
-.RE
-.IP " 2." 4
-Introduction to MIRAX/MRXS
-.RS 4
-\%http://lists.andrew.cmu.edu/pipermail/openslide-users/2012-July/000373.html
-.RE
Deleted: trunk/packages/openslide/trunk/debian/openslide-show-properties.1.xml
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-show-properties.1.xml 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/openslide-show-properties.1.xml 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,41 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<?xml-stylesheet type="text/xsl" href="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" ?>
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
-<refentry id="openslideshowproperties1">
- <refmeta>
- <refentrytitle>OPENSLIDE-SHOW-PROPERTIES</refentrytitle>
- <manvolnum>1</manvolnum>
- <refmiscinfo class="source">OpenSlide</refmiscinfo>
- <refmiscinfo class="version">VER_FULL</refmiscinfo>
- <refmiscinfo class="manual">Users Commands</refmiscinfo>
- </refmeta>
- <refnamediv>
- <refname>openslide-show-properties</refname>
- <refpurpose>Print OpenSlide properties</refpurpose>
- </refnamediv>
- <refsynopsisdiv id="synopsis">
- <cmdsynopsis>
- <command>openslide-show-properties</command>
- <arg choice="plain">
- <replaceable>infile</replaceable>
- </arg>
- <sbr/>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsection id="description">
- <title>DESCRIPTION</title>
- <para>Print OpenSlide properties.</para>
- </refsection>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../ListofKnownProperties.xml"/>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../Trestleformat.xml"/>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../Hamamatsuformat.xml"/>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../Aperioformat.xml"/>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../MIRAXformat.xml"/>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../GenerictiledTIFFformat.xml"/>
- <refsect1 id="authors">
- <title>AUTHORS</title>
- <para>The Carnegie Mellon School of Computer Science.</para>
- <para>This manual page was written by Mathieu Malaterre
-<malat at debian.org> for the Debian GNU/Linux system (but may be used by others).</para>
- </refsect1>
-</refentry>
Modified: trunk/packages/openslide/trunk/debian/openslide-tools.manpages
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-tools.manpages 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/openslide-tools.manpages 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,3 +1,3 @@
-debian/openslide-write-png.1
-debian/openslide-quickhash1sum.1
-debian/openslide-show-properties.1
+tools/openslide-write-png.1
+tools/openslide-quickhash1sum.1
+tools/openslide-show-properties.1
Deleted: trunk/packages/openslide/trunk/debian/openslide-write-png.1
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-write-png.1 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/openslide-write-png.1 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,26 +0,0 @@
-.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.38.2.
-.TH OPENSLIDE-WRITE-PNG "1" "April 2013" "openslide-write-png 3.3.3" "User Commands"
-.SH NAME
-Write a fragment of a virtual slide to a PNG
-.SH DESCRIPTION
-.SS "Usage:"
-.IP
-openslide\-write\-png [OPTION...] slide x y level width height output.png
-.PP
-Write a region of a virtual slide to a PNG.
-.SS "Help Options:"
-.TP
-\fB\-h\fR, \fB\-\-help\fR
-Show help options
-.SS "Application Options:"
-.TP
-\fB\-\-version\fR
-Show version
-.SH AUTHOR
-The Carnegie Mellon School of Computer Science.
-
-This manual page was written by Mathieu Malaterre <malat at debian.org> for
-the Debian GNU/Linux system, but may be used by others.
-.SH "SEE ALSO"
-.IR openslide-quickhash1sum(1),
-.IR openslide-show-properties(1)
Deleted: trunk/packages/openslide/trunk/debian/openslide-write-png.1.in
===================================================================
--- trunk/packages/openslide/trunk/debian/openslide-write-png.1.in 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/openslide-write-png.1.in 2014-01-26 08:30:43 UTC (rev 15851)
@@ -1,12 +0,0 @@
-[NAME]
-Write a fragment of a virtual slide to a PNG
-
-[SEE ALSO]
-.IR openslide-quickhash1sum(1),
-.IR openslide-show-properties(1)
-
-[AUTHOR]
-The Carnegie Mellon School of Computer Science.
-
-This manual page was written by Mathieu Malaterre <malat at debian.org> for
-the Debian GNU/Linux system, but may be used by others.
Modified: trunk/packages/openslide/trunk/debian/rules
===================================================================
--- trunk/packages/openslide/trunk/debian/rules 2014-01-24 16:46:11 UTC (rev 15850)
+++ trunk/packages/openslide/trunk/debian/rules 2014-01-26 08:30:43 UTC (rev 15851)
@@ -22,6 +22,8 @@
wget -O $@ http://openslide.org/formats/hamamatsu/
Aperioformat.html:
wget -O $@ http://openslide.org/formats/aperio/
+Sakuraformat.html:
+ wget -O $@ http://openslide.org/formats/sakura/
MIRAXformat.html:
wget -O $@ http://openslide.org/formats/mirax/
GenerictiledTIFFformat.html:
@@ -33,15 +35,15 @@
xmllint --nonet --output $@ --format $<.dummy.xml
rm $<.dummy.xml
-debian/openslide-show-properties.1 : ListofKnownProperties.xml Trestleformat.xml Hamamatsuformat.xml Aperioformat.xml MIRAXformat.xml GenerictiledTIFFformat.xml debian/openslide-show-properties.1.xml
- (cd debian && sed -e 's at VER_FULL@$(VER_FULL)@g' openslide-show-properties.1.xml > openslide.tmp.xml)
+debian/openslide-formats.3 : ListofKnownProperties.xml Trestleformat.xml Hamamatsuformat.xml Aperioformat.xml Sakuraformat.xml MIRAXformat.xml GenerictiledTIFFformat.xml debian/openslide-formats.3.xml
+ (cd debian && sed -e 's at VER_FULL@$(VER_FULL)@g' openslide-formats.3.xml > openslide.tmp.xml)
(cd debian && xsltproc --xinclude openslide.tmp.xml)
# DO NOT USE for now
-debian/openslide-quickhash1sum.1: debian/openslide-quickhash1sum.1.in
- help2man --include=$< --output=$@ \
- --no-info `basename $@ .1` --version-string=$(VER_FULL) --no-discard-stderr
-
-debian/openslide-write-png.1: debian/openslide-write-png.1.in
- help2man --include=$< --output=$@ \
- --no-info `basename $@ .1` --version-string=$(VER_FULL) --no-discard-stderr
+#debian/openslide-quickhash1sum.1: debian/openslide-quickhash1sum.1.in
+# help2man --include=$< --output=$@ \
+# --no-info `basename $@ .1` --version-string=$(VER_FULL) --no-discard-stderr
+#
+#debian/openslide-write-png.1: debian/openslide-write-png.1.in
+# help2man --include=$< --output=$@ \
+# --no-info `basename $@ .1` --version-string=$(VER_FULL) --no-discard-stderr
More information about the debian-med-commit
mailing list