Small docs updates

docs/properties/index.md

@@ -32,7 +32,7 @@ This property is not always present.
 This property is not always present.
 
 `openslide.comment`
-: A free-form text comment.
+: A free-form text comment. This property is not always present.
 
 `openslide.icc-size`
 : The size of the slide's ICC profile, if any.

docs/testsuite/index.md

@@ -132,7 +132,7 @@ returns.
 
 If `openslide_detect_vendor()` should return a different result than for the
 original slide (e.g., if OpenSlide falls back to `generic-tiff`), change
-`vendor` to the new string or `null` for NULL.
+`vendor` to the new string or `~` for NULL.
 
 If the test should only be run if particular OpenSlide dependencies are
 available, set `requires` to a list of feature flags.  Currently the
@@ -172,7 +172,7 @@ success: false
 error: ^Tile size not consistent$
 
 # The string that should be returned by openslide_detect_vendor(),
-# or null.
+# or ~ for NULL.
 vendor: hamamatsu
 
 # True if this is the "vanilla" (unmodified) test case for this slide.
@@ -196,7 +196,7 @@ regions:
   - [1000, 1000, 2, 1, 1]
 
 # Optional map of property values to check against the properties returned
-# by OpenSlide.
+# by OpenSlide.  If ~ is specified, the property must be absent.
 properties:
   openslide.vendor: hamamatsu
 

formats/aperio/index.md

@@ -35,6 +35,7 @@ Tag                 | Description                    |
 --------------------|--------------------------------|
 `ImageDescription`|Stores some important key-value pairs and other information, see below|
 `Compression`|May be 33003 or 33005, which represent specific kinds of JPEG 2000 compression, see below|
+`NewSubfileType`|1 for the label associated image, 9 for the macro associated image|
 
 
 ## Extra data stored in `ImageDescription`
@@ -47,11 +48,6 @@ equals-delimited. These key-values are stored as properties starting
 with "`aperio.`". Currently, OpenSlide does not use any of the
 information present in these key-value fields.
 
-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.
-
 
 ## TIFF Image Directory Organization
 
@@ -95,11 +91,15 @@ image.
 
 ## Associated Images
 
+There are up to three stripped images: a thumbnail image, which is
+always the second image in the file; and label and macro images at the
+end of the file, with subfile types 1 and 9 respectively.
+
 `label`
-: optional, the name "label" is given in `ImageDescription`
+: optional, non-tiled image with subfile type 1
 
 `macro`
-: optional, the name "macro" is given in `ImageDescription`
+: optional, non-tiled image with subfile type 9
 
 `thumbnail`
 : the second image in the file

formats/hamamatsu/index.md

@@ -181,7 +181,8 @@ 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.
+not stored in sorted order, and ASCII values are always stored out-of-line
+even when TIFF would store them inline.
 
 NDPI stores an image pyramid in TIFF directory entries.  In some files, the
 lower-resolution pyramid levels contain no restart markers.  The macro
@@ -193,6 +194,10 @@ 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.
 
+Conversely, on some pyramid levels without restart markers, the TIFF
+`ImageWidth` and `ImageHeight` may not match the JPEG dimensions due to
+inconsistent rounding.
+
 NDPI is based on the classic TIFF format, which does not support files
 larger than 4 GB.  However, NDPI files can be larger than 4 GB.  NDPI
 handles this by storing the high-order bits of file offsets beyond the ends
@@ -201,7 +206,8 @@ header and at the end of each directory) at the ends of their parent data
 structures, so NDPI simply extends these values to 64-bit quantities.  The
 high-order bits of directory entry Value Offsets are stored in an array
 immediately after the end of each TIFF directory, 4 bytes per directory
-entry.  Values that TIFF would normally store inline in the Value Offset are
+entry.  Values that would normally be stored inline in the Value Offset
+(not ASCII, as mentioned above) are
 still stored inline, even if the high 32 bits are non-zero (e.g.
 `StripOffsets` and `StripByteCounts`, which always have a Count of 1 in
 NDPI), and other values are still stored out-of-line.
@@ -245,7 +251,7 @@ Tag          | Description      |
 65456|Unknown, have seen 101|
 65457|Unknown, always 0?|
 65458|Unknown, always 0?|
-65459|Unknown, have seen ASCII "`RGB`" stored out-of-line even though TIFF says it should be stored inline|
+65459|Unknown, have seen ASCII "`JPEG`", "`Native RGB`", and "`RGB`"|
 
 
 ## Optimisation File (only for VMS)