Fix seams in Trestle

[agoode]

_Imported from Trac. This issue originally by _agoode* at 2009-12-11T20:04:16Z.*

Currently, we just layer over the tiles with overlaps in Trestle. But the vendor's software appears to do better.

[agoode]

_This comment originally by _agoode* at 2010-01-14T21:21:09Z.*

Aha! There are some auxiliary files that end in ".tif-0b", ".tif-1b", ".tif-2b". These are as-yet undecoded but the file sizes are proportional (factor 4x) and the Trestle viewer shows seams when they are removed.

[ihnorton]

Hi, just came across openslide via this issue as I tried to figure out the seams problem. have you managed to parse the auxiliary files?

btw, I'm excited to have found openslide - looks really useful.

[agoode]

I think Jan Harkes figured out some of the format. But I forget where it was documented, if anywhere. It would be great if you could help out with this. Glad you enjoy OpenSlide!

[ihnorton]

It looks like openslide-vendor-trestle.c has it covered. There is an EXIF tag called trestle.OverlapsXY which specifies the total pixel overlap in both axes. The total pixels are helpfully divisible by this number! Stitched images based on this and using openslide-write-png look good - same slight stitch imperfactions I see in the trestle viewer. Still no idea what is actually in those tif-0/1/2b metadata files. Thanks!

[bgilbert]

The files *.tif-Nb contain an array of structures, one for each tile in level N, in row-major order. Struct members are little-endian. The struct contents seem to be:

struct tile_info {
  int32_t xneighbor_offset_x;
  int32_t xneighbor_offset_y;
  uint32_t xneighbor_confidence_x;
  uint32_t xneighbor_confidence_y;

  int32_t yneighbor_offset_x;
  int32_t yneighbor_offset_y;
  uint32_t yneighbor_confidence_x;
  uint32_t yneighbor_confidence_y;
};

A good alignment along a row of tiles can be produced by computing tile coordinates as:

x[col][row] = x[col - 1][row] + tile_width - standard_overlap_x -
              info[col][row].xneighbor_offset_x;
y[col][row] = y[col - 1][row] - info[col][row].xneighbor_offset_y;

Likewise, along a column of tiles:

x[col][row] = x[col][row - 1] - info[col][row].yneighbor_offset_x;
y[col][row] = y[col][row - 1] + tile_height - standard_overlap_y -
              info[col][row].yneighbor_offset_y;

But the tile coordinates produced by these two calculations can be significantly different. To use the position data effectively, it appears we would need to use the confidence values (if that is what they are) to calculate globally-optimal tile placement.

---

As in MIRAX, photos are split into multiple tiles (4 x 4). Unlike in MIRAX, the standard overlaps are applied to all tiles from a single photo, though there are no individualized overlaps within a photo. So, within a given photo:

• xneighbor_offset_* is zero for all but the first tile in a row, and yneighbor_offset_* is zero for all but the first tile in a column.
• The first tile in every row has the same xneighbor_offset_*, and the first tile in every column has the same yneighbor_offset_*.

Also unlike MIRAX, levels which combine multiple photos into each tile have no overlaps. This explains why there are only overlaps for the first three levels.