Color-/Lineshifts under Windows?

[Hauke Heibel]

Hi Adam,

we finished digesting the last e-mail. Marco and me have verified and
understood all your findings regarding how tiles are stored in JPEGs
and the information regarding overlaps.

I did not continue looking into the tables nor into the slide
positions but I wrote a Matlab script where I tried out several ways
of stitching together the two level 9 pyramid JPEGs and the results
look good. I compared the Matlab reconstruction against SlideAC's
reconstruction and against OpenSlide's reconstruction. IMHO, the goal
should be to get as close as possible to SlideAC's result.

Just to be clear what I am talking about, I see a tile as an atomic
unit. JPEGs can, as you mentioned before consist of multiple tiles.

For the following example, I will assume that on level 0 each JPEG is
split into 4 images. That means on pyramid level 3, we see for the
first time a JPEG containing more than one tile. More general the
number of slides can be computed as (this not completely general
because it depends on the number of image divisions):

num_tiles_per_dim = 2^(pyramid_level-2);

As an example, on level 9 each JPEG consists of 128-by-128 tiles.

As you said before, the question is which pixels to extract from each
JPEG when the tile dimensions are on a sub-pixel level and where to
paint them. On level 9 the problem is that the tiles dimensions are no
more integral values.

tile_width_px = DIGITIZER_WIDTH / num_tiles_per_dim; // ~= 2.56 ...
tile_height_px = DIGITIZER_HEIGHT / num_tiles_per_dim; // = 2

The overlap is also non integral (note, we really do have files with
different overlap settings in each dimension)

overlap_x = OVERLAP_X / 2^pyramid_level
overlap_y = OVERLAP_Y / 2^pyramid_level

First, the sub-pixel tile dimensions are only important for computing
the input and output index locations. The tile size, as it should be
extracted from the JPEG turns out to be optimal when ceil'ing these
values. On the CMU-1 dataset that means width = 3 pixels and height =
2 pixels.

For the input and output index computations, it is seems best to round
and to perform the rounding as late as possible. It is probably best
and saves time to look into the reconstruct.m file which I attached.
The variables tile_off_x and tile_off_y are the C compatible pixel
offsets within each JPEG and accordingly, img_off_x and img_off_y are
the offsets in the output image. There I am making a small mistake, I
am only considering the vertical offset caused by other JPEGs but the
computation is identical.

The next step will probably be to go back to the C source and to find
out where and how these computations are made and to fix them.

Regards,
Hauke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: level9.zip
Type: application/zip
Size: 48760 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20100811/bf345a60/attachment-0001.zip