-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rendering offset for some WSI formats #38
Comments
Just observed the same using the latest artefact when testing a custom mitosis segmentation model. I was running a lot of different tests. I could not reproduce this issue on the CellSens VSIs, but for the generic TIFF images, it seems to reproduce quite consistently. However, I find it strange, as these images were originally stored as .vsi, but converted to .tiff. I believe this used to work before (in the first release of FP). Not sure what changed. Might also be that the converter stores some spacing data wrong. There should be some WSIs located on the SINTEF-server you could test: I observed the same issue using the nuclei segmentation method that is part of the software. If that WSI is not in the path, you could test any of the .tif-files. I believe it should be consistent among those files, but not sure. |
This is caused by pixel spacing of segmentation being calculating incorrectly. We are not able to extract spacing information from the VSI format, that is why it is not occurring on these images. |
I'm observing this issue on the TIFF images, not the VSI images. But the TIFF images were originally in the VSI format. The TIFF images are located at: The corresponding VSI images are located at: on the SINTEF server, if I recall correctly, if you wish to check this further. |
Hello, I have observed the same behavior on .MRXS whole slide images, on Windows, with latest release (v1.1.0), with all segmentation models. I can provide a test image if needed. |
That's interesting, @vladpopovici! Thanks for reporting it! @smistad is on vacation now and I am preoccupied with some other deadlines, so we will not be able to look into this until August earliest. Will keep you updated! Regarding test data, could you reproduce the issue on any of the MXRS files that are part of the OpenSlide test data (see here). |
Now that's awkward: on the test data the segmentation mask is spot on! I will take a closer look to see what are the differences in metadata between test images and mine. My images are produced by the scanner software for 3DHistech. Keep you posted. V. |
Oh, yeah. This we have seen in a separate issue. See issue #13 (or more specifically, see this comment). Basically, the MRXS format produced from the 3DHistech format has been modified, which results in OpenSlide failing to interpret it correctly. This was also talked about thoroughly in this thread. To get these images to work with non 3DHistech-products, you will need to use the 3D Histech converter tool (see here). Which should resolve this issue, but I have myself never tried it. Could you give it a go to see if it resolves the issue you are experiencing on your local WSI? |
I can confirm the observations made by @pr4deepr: -original .MRXS from 3DHistech scanner is read by FP, but segmentation is shifted; Additionally, I tried .MRXS -> OME-TIFF (with bioformats tools: bioformats2raw + raw2ometiff which results in a file that cannot be read by FP ("level is too large to convert into a FAST image"). |
The annoying problem is basically that the 3DHistech have corrupted the original MRXS format slightly, meaning that for FP the regular OpenSlide test MRXS files reads as expected, but the one directly for the 3DHistech server does not.
I believe that is because it does not produce a pyramidal TIFF, which is needed to be read by FP. If you try to open it in QuPath, it will likely open, it might take a while and prompt a warning, as it will try to pyramidize the entire image before reading it.
That is related to the previous comment. I would recommend using
See the aforementioned script for more information regarding compression in the first step and bfconvert path. |
The bfconvert produces a corrupted image that vips fails to convert afterwards.
The resulting file is perfectly opened by FP, but the detection mask is, again, shifted. I will have to check in the code to see which meta-parameters are causing this behavior. It's really frustrating... :) |
I believe by attempting to convert in another software than 3DHistech's own converter, you will likely still get the offset. Something in the metadata of the raw MRXS format you are getting from the 3DHistech scanner is likely not following the MRXS standard. They likely added this annoyance to force people to use their products. I have seen the same with Philips scanners before. Did you find a good workaround for this issue, @pr4deepr? Did you try to use the converter I mentioned previously. Might be that it has been rebranded to slidemaster. |
Yes, I tried with SlideMaster - see my attempts above. |
I guess this is something that could be addressed in FAST then. We have a similar issue with some other WSI formats, so it should be possible to resolve. However, @smistad is on vacation, so it will have to wait until August. |
Hi, As discussed on https://forum.image.sc/t/nocodeseg-deep-learning-based-segmentation-without-code-qupath-deepmib-fastpathology/60069/10, I have the exact same shifting problem in FAST (via FastPathology). And the shift looks like this: I can send a test image if needed. |
Hello, @cavenel! It would be great if you could share an image, such that we could see if we could reproduce the issue. It would also help us in debugging the issue and potentially finding a fix. If you do not wish to make it open to everyone, you could share the WSI with me at: andrped94@gmail.com |
Note that we have resolved similar issues before for a difference image format: #61 (comment) Also note that for this exact format, @pr4deep seemed to have managed to resolve this issue for the same 3DHistech MRXS format by converting the format to TIFF using 3DHistech's own converter: #13 (comment) @cavenel Could you please check again that you did the conversion correctly. This is also relevant for @vladpopovici (see comment below).
@vladpopovici I believe the conversion you did here actually fixed it, but you have to convert the image to pyramidal TIFF, not regular TIFF, as FastPathology only works with pyramidal images, in contrast to QuPath that can pyramize the image if necessary. |
Hello @andreped @cavenel and @vladpopovici Sorry for responding so slowly to this. I have now found the reason for this error. I will commit a fix to FAST soon, then we will need to rebuild FAST-Pathology with the new fix. |
@cavenel I have now rebuilt FAST-Pathology with the fix. You can download installers from artifacts here: Let us know how it goes |
I can confirm as well that the patch fixed the issue. Thanks a lot! |
Just run the nuclei segmentation pipeline which follows with FP on a local WSI, and observed that the rendered segmentations were off.
This was observed for a WSI stored in the generic TIFF format, on Windows 10, using the latest artifact.
See example below.
The text was updated successfully, but these errors were encountered: