Color-/Lineshifts under Windows?

[Adam Goode]

Hi Hauke,

Do you mind adding your matlab analysis code to misc? This is where I
have been putting debugging scripts and such to help figure out formats.


Thanks,

Adam


On 08/11/2010 10:54 AM, Hauke Heibel wrote:
> 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
> 
> 
> 
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20100820/ecb939e5/attachment.bin