Question about NDPI

[Martin Weihrauch]

Ah, cool.

So that means:

Usually, at the end of the IFDs is the offset to the next IFD and Hamamatsu places all 8 instead of 4 bytes there and *thereafter* the high bits of all value/offset start, which would mean:

You have this IFD structure then:
-------------------------------------------

2 bytes:  for count of tags
12 bytes * (count of tags): The tags themselves
8 byte:  offset of next IFD
4 bytes * (count of tags): High bits for all tags

?

Thx

Martin

-----Original Message-----
From: Benjamin Gilbert <bgilbert+openslide at cs.cmu.edu> 
Sent: Freitag, 17. Mai 2024 19:30
To: openslide-users at lists.andrew.cmu.edu
Cc: Martin Weihrauch <m.weihrauch at smartinmedia.com>
Subject: Re: Question about NDPI

On Fri, May 17, 2024 at 10:01 AM Martin Weihrauch <m.weihrauch at smartinmedia.com> wrote:
> As the value/offset tags within the IFDs are only 4 bytes in 
> Hamamatsu, I saw from OpenSlide that
> - If it is not the 1st IFD, then it compares the offset of any tag with the offset to the tag from the 1st IFD. If the offset is the same --> take this 32bit offset, else combine the high bits of the 64bit offset of the IFD in the file with the tag 32 bit offset to 64bits.

It turns out that this heuristic is incorrect.  Nicholas Trahearn found that the high bits are actually present elsewhere in the file.
I haven't dug into this yet, but you can see his work at <https://github.com/openslide/openslide/pull/602>.  I'm hoping to switch OpenSlide to the new approach soon.

Best,
--Benjamin Gilbert