Precipoint VMIC driver and DeepZoom

[PD Dr. M. Weihrauch]

Dear Benjamin:

Is there any development on the Olympus vsi format? It'd be great to
have it available in OpenSlide, but I guess, they are still closed shop?

Thx

Martin

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


-- 
---------------------------------
Priv.-Doz. Dr. med. Martin Weihrauch
Facharzt für Innere Medizin,
Hämatologie und intern. Onkologie
Smart In Media GmbH & Co. KG
Intelligent Software

Office address:
Gleueler Str. 373a
50935 Köln

Legal address:
Elsternweg 6
50997 Köln
GERMANY
Tel: 02233-6278658
Fax: 02233-6278659
Mob: 0163-9600829

Geschäftsführung : Priv.-Doz. Dr. med. Alberto Perez Bouza
Umsatz-Steuer ID Nr. : DE 27 999 2044
Amtsgericht Köln HRA 28691