From ca6600159d844c8a1650aa8e7d5821f082cfd26d Mon Sep 17 00:00:00 2001 From: Benjamin Gilbert Date: Tue, 26 May 2026 19:17:18 -0500 Subject: [PATCH 1/5] docs/properties: openslide.comment is optional Signed-off-by: Benjamin Gilbert --- docs/properties/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/properties/index.md b/docs/properties/index.md index 1b04956..a277e48 100644 --- a/docs/properties/index.md +++ b/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. From 48485ba68a906eceb8e9e3ccf8d69b4563ca20f4 Mon Sep 17 00:00:00 2001 From: Benjamin Gilbert Date: Tue, 26 May 2026 19:20:08 -0500 Subject: [PATCH 2/5] formats/aperio: update detection rules for label and macro images The ImageDescription text turns out to be incidental but the subfile type appears to be reliable. Signed-off-by: Benjamin Gilbert --- formats/aperio/index.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/formats/aperio/index.md b/formats/aperio/index.md index 6ff74ac..9b39d3b 100644 --- a/formats/aperio/index.md +++ b/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 From 1a04e0c05526076649aa6fe40b92bbfd458e79bc Mon Sep 17 00:00:00 2001 From: Benjamin Gilbert Date: Wed, 27 May 2026 20:15:35 -0500 Subject: [PATCH 3/5] formats/hamamatsu: document JPEG dimension mismatch with NDPI TIFF level See: https://github.com/openslide/openslide/pull/729 Signed-off-by: Benjamin Gilbert --- formats/hamamatsu/index.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/formats/hamamatsu/index.md b/formats/hamamatsu/index.md index 90df00f..bc802f9 100644 --- a/formats/hamamatsu/index.md +++ b/formats/hamamatsu/index.md @@ -193,6 +193,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 From 88dd0c6916e74a775fda95747c2dfda050d65f02 Mon Sep 17 00:00:00 2001 From: Benjamin Gilbert Date: Fri, 29 May 2026 23:37:09 -0500 Subject: [PATCH 4/5] formats/hamamatsu: NDPI ASCII values are always stored out-of-line See: https://github.com/openslide/openslide/pull/735 Signed-off-by: Benjamin Gilbert --- formats/hamamatsu/index.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/formats/hamamatsu/index.md b/formats/hamamatsu/index.md index bc802f9..17d8bbd 100644 --- a/formats/hamamatsu/index.md +++ b/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 @@ -205,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. @@ -249,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) From ba0abcfbaddd2be8f64e24893abefee891c76163 Mon Sep 17 00:00:00 2001 From: Benjamin Gilbert Date: Wed, 27 May 2026 23:17:59 -0500 Subject: [PATCH 5/5] docs/testsuite: update syntax for NULL vendor or missing property Signed-off-by: Benjamin Gilbert --- docs/testsuite/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/testsuite/index.md b/docs/testsuite/index.md index beb5264..70801f8 100644 --- a/docs/testsuite/index.md +++ b/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