MRXS 2.2 progress

[Benjamin Gilbert]

On 11/02/2012 11:25 AM, Agelos Pappas wrote:
> 174231 is a multiple of 9 and I quickly thought of the 9-byte record
> pattern of *VIMSLIDE_POSITION_BUFFER.default* nonhierarchical section.
> This produces at most 19,359 records (174231 / 9) which I believe is
> unlikely to be similar to VIMSLIDE_POSITION_BUFFER.

Nice work!  Your CSV looks *exactly* like VIMSLIDE_POSITION_BUFFER.

It's not surprising that the record count is constant, because each 
slide is scanned using the same number of camera positions.  In the case 
of Mirax2.2-1.mrxs, the Slidedat IMAGENUMBER_{X,Y} specify 324 x 956 
tiles in level 0.  Divide by CameraImageDivisionsPerSide and we get 81 x 
239 = 19,359 camera positions.

> The single
> byte in every record appears to only have 0 or 1 as a value.
> Furthermore, whenever it equals 0, the two integers are always zero two.
> Whenever it is 1, the integers have values in them.

For camera positions that don't actually contain meaningful pixels, the 
JPEGs are omitted from the file and the X/Y position values are set to 
zero.  (We call these "inactive" positions.)

In fact, you seem to have discovered the meaning of the first byte: it's 
1 if the camera position is active or 0 otherwise.  I've checked all of 
the MIRAX 1.9 slides I have access to, and have not found a single 
exception.  (See <https://github.com/openslide/openslide/commit/61475c> 
for the reason we didn't notice this earlier.)

MIRAX 1.8 is a little different: the coordinates are always present and 
the flag byte is always 0.  But we don't support 1.8 right now anyway.

> Moreover, the
> integers never contain negative values, even though I read them as
> signed integers.

Negative values do occur, but they are rare.

--Benjamin Gilbert