MRXS 2.2 progress

[Agelos Pappas]

Thanks for the input, now it really makes sense! Does MRXS 1.9 have a 
StitchingIntensityLayer as well? Because we've seen seams in 1.9 files 
as well.
Now I guess "all I have to do", is code this back in 
openslide-vendor-mirax.c, right?
I'd like your help on how to approach this, if it's possible.

Regards
Pappas Agelos

On 2/11/2012 10:02 μμ, Benjamin Gilbert wrote:
> 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
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2221 / Virus Database: 2441/5369 - Release Date: 11/02/12
>
>