<div dir="ltr"><div><div><div><div>Hi,<br><br></div>@Markus <span class="gmail-il">Pöpping: </span>thank you very for your efforts! I am using the preliminary version of the VMIC driver/openslide-python without any problems. <br><br></div>@Benjamin Gilbert: do you have a release plan?<br><br></div>Best regards,<br><br></div>Kai<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-02 2:28 GMT+02:00 Benjamin Gilbert via openslide-users <span dir="ltr"><<a href="mailto:openslide-users@lists.andrew.cmu.edu" target="_blank">openslide-users@lists.andrew.cmu.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 21, 2016 at 04:05:08PM +0200, Markus Pöpping via openslide-users wrote:<br>
> The notion to move to a simple grid is valid. However, after very long<br>
> pondering, I left the strategic approach as is, first because it's been<br>
> tested well, and the performance is good enough. Secondly, I don't know<br>
> if a simple grid can be used because truncated tiles do appear in VMIC and<br>
> general DeepZoom on right and bottom borders.<br>
<br>
</span>The grid itself doesn't care about truncated tiles on the right/bottom<br>
edges. The read function would need to check for those edges and adjust the<br>
size of the tile it expects to read.<br>
<span class=""><br>
> Thirdly, this also would require specialized code paths for overlapping<br>
> and non-overlapping DZ.<br>
<br>
</span>You said earlier that there are no overlapping VMICs; is that still true?<br>
In general we try not to ship code that is more flexible than we really<br>
need.<br>
<span class=""><br>
> > The existing drivers re-open their data files on every<br>
> > openslide_read_region(). That avoids this kind of thread-safety issue<br>
> > (provided that libzip doesn't have any global state) and also prevents<br>
> > an idle openslide_t from consuming file handles. If creating a ZIP<br>
> > handle is expensive, you can use a handle cache + your own zip_source,<br>
> > similar to the approach used by _openslide_tiffcache.<br>
><br>
> The nefarious global GMutex has been removed, instead, the zip_t* handle<br>
> got wrapped by the _openslide_ziphandle structure, so we can have one<br>
> mutex for each instance of a zip archive.<br>
<br>
</span>That's still inconsistent with OpenSlide's typical approach. We generally<br>
try to avoid shared mutable state, and if we're going to add more, there<br>
should be a good reason.<br>
<span class=""><br>
> Also, there are now wrapper functions for zip_open, zip_open_from_source,<br>
> zip_close, zip_fopen and zip_fclose. This is simpler than a handle cache<br>
> and apparently enough to allow multithreading.<br>
<br>
</span>Yes, but not enough to allow parallel I/O. If multiple threads were using<br>
the same openslide_t, only one would be able to do I/O at a time.<br>
<span class=""><br>
> Reopening the zip for every image access would of course be out of<br>
> question.<br>
<br>
</span>Why?<br>
<span class=""><br>
> The slide has a title, which can be found in vendor-specific property<br>
> "<a href="http://PreciPoint.ScanData.Name" rel="noreferrer" target="_blank">PreciPoint.ScanData.Name</a>". As of now, the slide title is copied into<br>
> the "openslide.comment" tag. Is there a better place ? I cannot find any<br>
> property similar to "openslide.title" or "<a href="http://openslide.name" rel="noreferrer" target="_blank">openslide.name</a>".<br>
<br>
</span>There's no generic "slide name" property, and openslide.comment is not<br>
well-defined. It's as good a place as any, I suppose.<br>
<span class=""><br>
> > What are VMIC's exact rules on the name of the inner archive? All three<br>
> > sample files use a filename of exactly "Image.vmici". If the name check<br>
> > could be restricted further (in particular, if the .vmici extension is<br>
> > always present), it might be reasonable to drop the check for the inner ZIP<br>
> > magic number.<br>
><br>
> Basically, the inner archive is supposed to be named either<br>
> "Image.vmici", or, for older slides up to 2015, "Image".<br>
> Since we do want to support older slides, and the name "Image" is very<br>
> generic, I believe, dropping the check for the magic number is no good<br>
> idea, and I see no problem because the check is inexpensive.<br>
<br>
</span>ZIP doesn't have a magic number in a fixed location. You're checking for<br>
the first local file header, but there can be arbitrary amounts of data<br>
prepended to a ZIP, so the header may not be at offset 0. If we wanted to<br>
be rigorous, we'd have to search the last 64 KB of the member for an End of<br>
Central Directory record. It's probably best to keep the check as is, but<br>
it does impose an additional constraint on the format of the slide file.<br>
<br>
--Benjamin Gilbert<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
openslide-users mailing list<br>
<a href="mailto:openslide-users@lists.andrew.cmu.edu">openslide-users@lists.andrew.<wbr>cmu.edu</a><br>
<a href="https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users" rel="noreferrer" target="_blank">https://lists.andrew.cmu.edu/<wbr>mailman/listinfo/openslide-<wbr>users</a><br>
</div></div></blockquote></div><br></div>