Color-/Lineshifts under Windows?

[Adam Goode]

On 08/07/2010 04:25 PM, Hauke Heibel wrote:
> I've spend some more time on the problem and tried to understand the
> MIRAX format a little bit better and looked in detail at the method
> _openslide_try_mirax.
> 
> There are some things which are not totally clear to me and it would
> be great, if you could help me out. On the CMU-1 data set, the 9th
> level - the level I am always working on for debugging purposes - has
> a width of 213 pixels and a height of 431 pixels. The tile size is
> according to the slidedat file 340 by 256 and I would expect
> tiles_across to be 1 and tiles_down to be 2 but they are 88 and 244.
> This means in the loop where you are loading tiles and storing them in
> the user's buffer, you load >21k tiles - ok, they are cashed but this
> seems to be overkill. Is this intended? I think even the corresponding
> data file Data0015 consists of exactly two jpegs which would support
> my assumption.
> 

This is a weird part of MIRAX. (There are about 10 other weird parts of
MIRAX.) Let me try to explain it.

When the hardware collects images, it does so with some overlap. This is
reasonable so that edges aren't missed. It stores the tiles as JPEG
images, but with overlaps. The overlap isn't exactly the same every
time. This is so the acquisition can go faster: instead of lining the
camera up precisely, the position is stored or computed precisely.

The software stores a position file so that the images can be
reassembled at viewing time. It does this instead of post-processing the
images once. So the burden is on the viewer to line things up.

So far, this is ok.

When it comes time to downsample the images, things get bizarre. To
downsample, MIRAX concatenates 4 tiles together into 1 new JPEG tile.
This is fine, except that it does this without stitching together the
overlaps. So within a JPEG tile, you'll get overlaps. You can't treat
the JPEG file as an atomic unit, instead you have to cut parts out of it
and draw it just as you would the full sized tiles.

Getting weird, but still doable. We just have to find the correct pixel
to start on to read what we want.

Unfortunately, there are a few problems. First, the tiles cross the JPEG
MCU boundaries (typically 8x8 or 16x16) so you get JPEG artifacts that
spill across discontiguous tiles: annoying, but not fatal.

Second, after each concatenation/downsample, the overlap size reduces by
half. This is ok, until the overlap goes below 1 pixel. At this point,
the stored images on disk have blended edges between discontiguous
tiles: single pixels have data from 2 unrelated tiles.

And we have to do things with subpixel precision, which leads to
difficulties that we see here, and bugs like insufficient coverage which
manifests as spots on corners of tiles.


> Another thing I do not quite understand is still the tile_advance_x
> and tile_advance_y - I am now pretty sure, that a wrong tile_advance_*
> value could potentially lead to those patterns we are seeing and I
> would have expected that the tile advance values would always be
> integral values because tiles should be shifted pixel-wise.
> 

The patterns come about because of insufficient coverage. Basically, we
are not painting enough tile edges because we have such little data to
read from. This may have been hidden better before, since I was
compositing with a white color. Now, I expose alpha so that the
background shows through.


> Yet another one is the variable subtiles_per_jpeg_tile - why does it
> differ from subtiles_per_position?
> 

I forget the details of which variables do what. Part of the issue was
that I needed to incrementally generalize the reader to accept more and
more variations of MIRAX, based on discovered meanings of lines in
Slidedat.ini. It is way more complicated that I would like, but I'm
afraid as complicated as necessary. I would love for somebody to tell me
I'm doing it all wrong and replace the code with something much shorter. :)


> I know, that it may be asked too much to explain these things since
> you have spend so much time on figuring it all out by yourself but as
> I were understanding a bit more, I could help better in debugging and
> for the future plans, where we want to support fluorescence it might
> also be helpful.
> 

I would love to be able to explain this better, and I wish I could
better document it. It is just difficult to articulate such a
complicated format... so much so that I continually wonder if I am
missing some simple solution.

> Regards,
> - Hauke
> 
> p.s. I had to resend the last two e-mails -- forgot to hit the reply
> all button :)
> 

Adam

-------------- 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/20100809/f7272b90/attachment.bin