Fix seams in Trestle #21

Open
agoode opened this Issue Sep 16, 2010 · 5 comments

Comments

Projects
None yet
3 participants
@agoode
Member

agoode commented Sep 16, 2010

_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 has been minimized.

Show comment
Hide comment
@agoode

agoode Sep 16, 2010

Member

_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.

Member

agoode commented Sep 16, 2010

_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

This comment has been minimized.

Show comment
Hide comment
@ihnorton

ihnorton Sep 16, 2011

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.

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

This comment has been minimized.

Show comment
Hide comment
@agoode

agoode Sep 16, 2011

Member

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!

Member

agoode commented Sep 16, 2011

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

This comment has been minimized.

Show comment
Hide comment
@ihnorton

ihnorton Sep 21, 2011

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!

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!

@ghost ghost assigned bgilbert Aug 15, 2013

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Aug 31, 2013

Member

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.

Member

bgilbert commented Aug 31, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment