<div dir="ltr">Dear Benjamin,<div><br></div><div>sorry for the late response, I wanted to test the different approaches before mailing again.</div><div><br></div><div>I have two main goals I want to achieve with the ROI information:</div><div><br></div><div>1. We have user requests to convert the .scn files into something more flexible for viewing/sharing/processing. To decrease overall file size, I would like to write a little Python UI that allows users to batch convert files to .png using only the ROIs that were acquired as individual pngs instead of a big whole slide file. In addition, I would also create a little overview image identifying the specific ROIs (already possible with OpenSlide).</div><div><br></div><div>2. Right now, it seems to be very common to only process small rectangular regions (hand-picked) to analyze tissue sections (I was looking at a few publications). However, as we already have all the data, I would like to provide a pipeline for users that allows them (me) to process everything within an ROI. </div><div><br></div><div>Considering your great suggestions, I looked at the Tiff 6.0 specs and the .scn file itself. The XML info seems to be located near the end of the file, however, reading out the tiff header and the pointer to the first IFD, I was (so far) not able to get the byte location of the xml info. I started looking into the openslide code to help identify how you obtain this info but did not have the time so far for detailed understanding. </div><div>Secondly, I wrote concept-code of a brute-force line parser to obtain ROI boundaries -> I am very confident that this will work very easily.</div><div><br></div><div>Considering your suggestions on API changes: I think that providing bounding box infos might be a good generic option that could also be of use for other formats. </div><div><br></div><div>Last but not least, I talked to our technician; we will generate a few standard slides that can be shared openly, however this will take some time as we need to obtain suitable left-over tissue first (kidney/lung/cortex/heart - something like this).</div><div><br></div><div>Thanks a lot for your help,</div><div>Niko</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 10:50 AM, Benjamin Gilbert <span dir="ltr"><<a href="mailto:bgilbert@cs.cmu.edu" target="_blank">bgilbert@cs.cmu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/07/2014 08:55 AM, Nikolay Kladt wrote:<br>
> The scn file has multiple associated images (scanned ROIs) that have<br>
> been scanned with identical resolution. How do I access individual<br>
> images or get their bounds? It seems that the properties do not show the<br>
> required information but the file format description includes multiple<br>
> images.<br>
<br>
</span>OpenSlide doesn't currently expose that information. In the long run,<br>
we will probably need to support multiple image pyramids per file (e.g.<br>
for Leica slides with ROIs scanned at different resolutions). At the<br>
moment, however, the philosophy is to merge multiple ROIs into one<br>
unified image pyramid when possible, and reject the slide otherwise.<br>
<br>
For now, your choices are to do a brute-force search for non-transparent<br>
pixels as you described, or to extract and parse the ImageDescription<br>
XML yourself as John proposed. If you try the brute-force search, you<br>
can restrict it to the region enclosed by the openslide.bounds-[xywh]<br>
properties.<br>
<br>
We could expose ROI information through the API in several ways:<br>
<br>
1. Once we get the multiple-pyramid support mentioned above, we could<br>
always expose each ROI as a separate pyramid. This doesn't help for<br>
MIRAX, whose on-disk format doesn't distinguish between ROIs.<br>
<br>
2. There's a longstanding issue<br>
(<a href="https://github.com/openslide/openslide/issues/35" target="_blank">https://github.com/openslide/openslide/issues/35</a>) proposing new API to<br>
list individual tile positions for every image tile in the slide. That<br>
assumes the information can be generalized into a consistent and useful<br>
format, which I think is probably not the case. I'm also not convinced<br>
an application should ever have to work with tile information at this<br>
level of detail.<br>
<br>
3. We could expose bounding boxes for each of the ROIs. This could be<br>
an array of x/y/w/h properties similar to openslide.bounds-[xywh],<br>
either in the leica or openslide namespaces, or perhaps a real API call.<br>
For Leica this could be okay, if verbose. The problem is MIRAX and<br>
formats like it, where ROIs are not rectangular: we could compute a<br>
bounding box but it might still contain significant blank areas.<br>
<br>
4. Provide an API call returning a bitmap image depicting non-empty<br>
slide regions. The call could allow the user to specify a "virtual<br>
tile" size and perhaps a step size, and then return a white pixel for<br>
each populated virtual tile and a black pixel for each empty one. This<br>
would produce similar results to your brute-force search, but much more<br>
efficently because OpenSlide has access to the underlying slide<br>
metadata. It should also generalize to arbitrary slide formats.<br>
<br>
e.g.:<br>
<br>
bool openslide_get_presence_bitmap(openslide_t *osr, uint8_t *out_buf,<br>
int64_t x, int64_t y,<br>
int64_t w, int64_t h,<br>
int64_t tile_w, int64_t tile_h,<br>
int64_t step_x, int64_t step_y);<br>
<br>
However, this might be hard for applications to use, and we'd have to<br>
provide a utility function to calculate the correct size for *out_buf.<br>
<br>
5. The simpler version of #4: provide an API call returning whether a<br>
particular region is non-empty. e.g.:<br>
<br>
bool openslide_is_present(openslide_t *osr,<br>
int64_t x, int64_t y,<br>
int64_t w, int64_t h);<br>
<br>
6. Others?<br>
<br>
<br>
What are you trying to accomplish with the ROI information? Are you<br>
looking for pixel-precise bounds for the ROIs, or perhaps even some<br>
additional information about them (like which is the first, second,<br>
third ROI in the file)? Or are you just trying to avoid doing lots of<br>
image processing on empty parts of the slide?<br>
<span class=""><br>
> If this is a problem of having test data, we can easily generate data<br>
> sets that can be shared.<br>
<br>
</span>I do have a couple slides with multiple ROIs, but nothing in the public<br>
dataset. If you'd willing to provide scans for the public dataset, that<br>
would be very helpful.<br>
<br>
--Benjamin Gilbert<br>
<br>
_______________________________________________<br>
openslide-users mailing list<br>
<a href="mailto:openslide-users@lists.andrew.cmu.edu">openslide-users@lists.andrew.cmu.edu</a><br>
<a href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users" target="_blank">https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Dr. Nikolay Kladt<div><span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px">Image and Data Analyst, CECAD </span><span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:11.818181991577148px;line-height:16.789772033691406px">Imaging Facility</span><br></div><div><span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:11.818181991577148px;line-height:16.789772033691406px"><a href="mailto:kladtn@uni-koeln.de" target="_blank">kladtn@uni-koeln.de</a></span></div><div><span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px">++49 221 478 84028</span><br></div><div><a href="https://www.linkedin.com/in/kladtn" target="_blank">https://www.linkedin.com/in/kladtn</a><span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px"><br></span></div><div><br></div><div><span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px">CECAD Cologne - Excellent in Aging Research</span><br style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px"><span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px">Universität zu Köln</span><br style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px"><font face="Verdana, Arial, Helvetica, sans-serif"><span style="font-size:11.818181991577148px;line-height:16.789772033691406px">Joseph-Stelzmann Str. 26</span></font><br style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px"><span style="font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16.796875px">50931 Cologne</span><br></div></div></div>
</div>