Color-/Lineshifts under Windows?

[Hauke Heibel]

No problem. I will do it right away.

On Fri, Aug 20, 2010 at 5:16 PM, Adam Goode <agoode at andrew.cmu.edu> wrote:
> 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
>
>
>