openslide_read_region filling buffer with 0's for Mirax

[Terry Wilson]

So I just tried the CMU-3 sample mrxs slide from the OpenSlide site and I
am getting the exact same result ... openslide_read_region is filling in
the supplied buffer with all zeros.  Has anyone been able to use OpenSlide
with this particular demo case?  I was certainly trying to avoid building a
debug version of the OpenSlide library to start stepping through the code
... hopefully someone has successfully used the C library to read an Mirax
slide?

I did download the 3DHistech viewer and sure enough it was able to view the
various mrxs slides, however, I did not see any reference to an SDK that I
could download ... can someone provide a link to that?

I also tried playing around with their converter ... when I converted MRXS
to MRXS, it generated the corresponding data files and directory but I
didn't see any new 'mrxs' file being created ... so wasn't able to try
OpenSlide on the converted slide ... any ideas on that?

Ultimately, I am still hoping that I can read these files using only the
OpenSlide library ... I will start looking at building my own version of
the library to debug next but I am REALLY hoping someone has an answer
before I have to resort to that!

Thanks,

Terry

On Fri, Apr 10, 2020 at 11:42 AM Derek Magee <D.R.Magee at leeds.ac.uk> wrote:

> "no pathologist will ever invest due to lack of return of investment"
>
> For info we've digitised out entire clinical workflow in Leeds UK (1000+
> slides/day) using ~6 Leica-Aperio scanners (they will be replaced by 3
> higher capacity ones soon). There are a number of other institutions around
> the world that have done the same (Granada in Spain, Coventry in UK, The
> whole of Sweden, Some institutions in the Netherlands etc.). Most are using
> either Leica-Aperio or Hammamatsu scanners, and propriety formats. There
> are a few Phillips clinical sites coming online also. There is even the odd
> institute using DICOM. This is definitely the way forward for image
> standardisation. We're in a lot of discussions  with various parties
> regarding DICOM for Digital Pathology and I can tell you it's  a matter of
> when, not if, this will be supported by all the major scanner vendors as a
> native format. If people are interested (probably when the COVID thing is
> all over)  we have been sharing our experiences of this via various courses
> and publications. If people are interested I can put you in touch with the
> appropriate people.
>
> BTW Metasystems (German company) have had a robot slide loader for 15
> years I'd say. It works with a regular microscope with a motorised stage. I
> think you'd be impressed with that also. It approaches the throughput of a
> dedicated slide scanner these days, and the system is only around E10-20K
> (not including the microscope)
>
> Derek
> ------------------------------
> *From:* openslide-users <openslide-users-bounces+d.r.magee=
> leeds.ac.uk at lists.andrew.cmu.edu> on behalf of PD Dr. med. M. Weihrauch <
> m.weihrauch at smartinmedia.com>
> *Sent:* 10 April 2020 14:42
> *To:* jcupitt at gmail.com <jcupitt at gmail.com>
> *Cc:* openslide-users at lists.andrew.cmu.edu <
> openslide-users at lists.andrew.cmu.edu>
> *Subject:* AW: openslide_read_region filling buffer with 0's for Mirax
>
>
> The truth is (for Germany) that most scanners sold are still for isolated
> research projects. Digital pathology as a “complete digitalization” of a
> diagnostic pathology institute is not yet happening. However, the “game” is
> slowly starting now and there will be pressure coming from the doctors as
> soon as they want to interact with colleagues hitting a brick wall of
> vendor formats.
>
> I know that some of the vendors already have a hard time selling their
> scanners due to bad (non-open) formats.
>
>
>
> There are some great developments though (not yet marketing). One engineer
> husband of a dermatopathologist now builds his own scanners with a Kuka
> robot arm in between loading them. When I first saw this, I could not speak
> for 10 minutes – it really was like this first iphone moment.
>
>
>
> After having scruitinized all available scanners on the market he quickly
> saw that NONE of them was ready for digitalizing 1,000 slides per day. Most
> scanner vendors do the same mistake: all 1,000 slides queue in front of
> only one objective. Or you buy 3 scanners (a 250,000€) to speed up the
> process, which no pathologist will ever invest due to lack of return of
> investment. Thus, he took his wife’s fate into his own hand and started
> constructing scanners. I really hope his small company will succeed.
>
>
>
> This is super intriguing and I can share a video to anyone interested (you
> can email me personally).
>
>
>
> He is using – and John you will love this – the SZI format 😊
>
>
>
> Hope, things will change for the better, my company is working hard on
> that.
>
>
>
> Best
>
>
>
>
>
> Martin
>
>
>
>
>
>
>
> *Von:* openslide-users <openslide-users-bounces+m.weihrauch=
> smartinmedia.com at lists.andrew.cmu.edu> *Im Auftrag von *jcupitt at gmail.com
> *Gesendet:* Freitag, 10. April 2020 15:20
> *Cc:* openslide-users at lists.andrew.cmu.edu
> *Betreff:* Re: openslide_read_region filling buffer with 0's for Mirax
>
>
>
> If people made good openslide support a "must have" feature when choosing
> a scanner, vendors might contribute code for their formats to the project,
> and perhaps even pay something towards maintenance.
>
>
>
> Unfortunately, it has not become a common requirement, and openslide is
> slowly becoming less relevant. I suspect vendors are (privately) delighted
> :(
>
>
>
> John
>
>
>
>
>
>
>
>
>
>
>
> On Fri, 10 Apr 2020 at 14:02, PD Dr. med. M. Weihrauch <
> m.weihrauch at smartinmedia.com> wrote:
>
> I just had a look at their SDK: There is C# and C++ parts, but everything
> is “.sln” = Visual Studio based. I guess, it’s all for Windows really.
>
>
>
> God, when will all the vendors get real and implement one single common
> file format – radiology made that happen 100 years ago? It’s like a jungle
> getting crazier by each day. It also seems like they are all competing, who
> can come up with an even worse format (Roche *.bif anyone? Different
> overlapping tile sizes of tiles with >1,000 pixels and an XML, which tells
> you how to rearrange that mess on the screen? / 3dHistech or Olympus with
> many files per slide, etc)…
>
> With better, faster and especially cheaper scanners, we could be 5 years
> in the future already.
>
>
>
> Sorry for letting off steam here – totally off-topic 😉
>
>
>
> Martin
>
>
>
> *Von:* Dr. M. Weihrauch <martin.weihrauch at uni-koeln.de>
> *Gesendet:* Freitag, 10. April 2020 14:27
> *An:* T. N. <ca95129 at hotmail.com>; PD Dr. med. M. Weihrauch <
> m.weihrauch at smartinmedia.com>; openslide-users at lists.andrew.cmu.edu
> *Betreff:* Re: openslide_read_region filling buffer with 0's for Mirax
>
>
>
> I don't know. Their demo is in C#, but I doubt they are running .NET Core.
>
>
>
> I'll check once I havd the chance.
>
>
>
>
>
>
>
> Von meinem Samsung Galaxy Smartphone gesendet.
>
>
>
>
>
> -------- Ursprüngliche Nachricht --------
>
> Von: "T. N." <ca95129 at hotmail.com>
>
> Datum: 10.04.20 13:35 (GMT+01:00)
>
> An: "PD Dr. med. M. Weihrauch" <m.weihrauch at smartinmedia.com>,
> openslide-users at lists.andrew.cmu.edu
>
> Betreff: Re: openslide_read_region filling buffer with 0's for Mirax
>
>
>
> Does the SDK from 3DHistech work on Linux?
>
> Thanks.
> thomas
>
> On 4/10/2020 10:23 AM, PD Dr. med. M. Weihrauch wrote:
>
> 3dHistech can also give you there SDK. it is somewhat buggy, but reads all
> files..
>
>
>
> best
>
>
>
> Martin
>
>
>
>
>
>
>
> Von meinem Samsung Galaxy Smartphone gesendet.
>
>
>
>
>
>
>
> -------- Ursprüngliche Nachricht --------
>
> Von: "T. N." <ca95129 at hotmail.com> <ca95129 at hotmail.com>
>
> Datum: 10.04.20 10:16 (GMT+01:00)
>
> An: openslide-users at lists.andrew.cmu.edu
>
> Betreff: Re: openslide_read_region filling buffer with 0's for Mirax
>
>
>
> I don't work with C interface, I just use the tools under Linux and
> recently  have problem with the Mirax files generated by the new 3DHistech
> scanner. The new file format does contain some extra information that
> OpenSlide rejects or doesn't understand. I read in other mailing lists that
> people have successfully use 3DHistech converter (free download from
> 3DHistech site) to convert from MIRAX format to MIRAX format (same format
> conversion) and can successfully use the converted file with OpenSlide. The
> converter basically removes the extra overlapping information from the
> file, This is an extra step that needs to be done on the scanner PC. Is
> there possibility that OpenSlide library can be updated to avoid this
> conversion step, eg, skipping the overlapping information in the new Mirax
> format.
>
> Regards,
> Thomas
>
> On 4/9/2020 11:21 PM, Terry Wilson wrote:
>
> I am using the C interface to the windows version of OpenSlide.  I have
> successfully used it to for a number of different formats, however, the
> same code does not appear to be working for Mirax slides.  I am able to
> open the slide and see the various properties, however, anytime I try
> calling openslide_read_region, it always just fills in the buffer with
> 0's.  According to the documentation that is an indication of some error,
> however, calling openslide_get_error immediately after just returns a null
> error object.
>
>
>
> I saw an older post from someone on this mailing list who seemed to have
> the exact same problem I am having with Mirax slides ... unfortunately they
> seemed to eventually get it working but had no idea what they changed to
> get it to work.  So I am looking for some suggestions on what to try.  I
> have tried retrieving all the data for the entire level 0 using a tile size
> of 512x512 and they all seem to come back with 0's.  I tried getting an
> entire higher level (level 6) with one call but same result.  I have also
> tried various different Mirax slides (including some of the demo ones from
> the OpenSlide site) The code is pretty simple:
>
>
>
> // Try reading a single tile
>
> // x, y values start at 0,0 and increase based on the tile size
>
> int size = 512;
>
>
>
> uint32_t *data = new uint32_t[size * size];
>
> openslide_read_region(openslide, data, x, y, 0, size, size);
> const char* err = openslide_get_error(openslide);
> if (err != NULL)
> {
>     printf("error detected");
> }
>
> I used openslide_get_property_names / openslide_get_property_value to dump
> out all the various metadata values for the slides ... is there some value
> in this metadata that I need to be accounting for (I assumed that the
> OpenSlide library was already doing that)? Any suggestions on how to
> trouble shoot this problem would be greatly appreciated.
>
>
>
> Regards,
>
>
>
> Terry
>
>
>
> _______________________________________________
>
> openslide-users mailing list
>
> openslide-users at lists.andrew.cmu.edu
>
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/openslide-users/attachments/20200410/626e8a8b/attachment-0001.html>