Closed petroslk closed 1 year ago
@petroslk I would love to look into this for you. Are you able to share an image that are trying to convert so that I can try to replicate the issue?
You may also want to try installing the latest test version: https://test.pypi.org/project/wsic/0.6.1/
pip install -i https://test.pypi.org/simple/ wsic==0.6.1
Hi @petroslk, have you had any luck with this? I can try to replicate the issue if you can let me know the version of wsic. A sample image that you are having trouble with would also be helpful.
Hey @John-P , the latest version also seems to be having the same issue. I've sent you a slide for you to try and replicate it! Thanks a lot for your help!
Thanks @petroslk, I'll try to replicate the issue and see if I can come up with a fix.
Hi @petroslk when I run the conversion with wsic using the file you sent to me I get an error from wsidicom which says that the transfer syntax in the DICOM file is not supported (1.2.840.10008.1.2.1 AKA Explicit VR Little Endian). Do you not see this message? It may also be a differently encoded file as the name is different from in the above example.
Hi @petroslk, I plan to close this due to inactivity. Please can you let me know if this has been resolved?
Hey there,
Sorry for the late reply, the issue still persists.
I should soon have a properly formated DICOM WSI that does not throw this warning and that I can share with you to see if you can replicate the issue. I hope to have this by next week.
Hey there @John-P , I hope you received my DICOM WSI! Let me know if you need anything else!
I have managed to get the conversion to work with the file that you sent me. I had to increase the time option (-to). This file is unusually slow to convert for some reason though. It will require some further investigation.
I was able to perform fast (and lossless) conversion of the pixel data in file that you sent me to a .tiff
using wsic transcode
(~1 min) and then convert this file to a .svs
using wsic convert
as a workaround. I have also confirmed that it opens in Aperio ImageScope. I hope to add transcode/re-packaing support from DICOM to SVS soon as this will be must faster.
I have figured out that the problem is that creating a wsidicom reader object is very expensive. It looks like pydicom is trying to iterate over all the frames (tiles) at startup (or similar), which is unnecessary and expensive. I can limit the creation of the reader to once at the start of the process. This leads to a long warm up but much faster conversion after. To properly fix this issue, there needs to be bug fixes to the wsidicom and pydicom packages, or I need to implement my own reader.
On my machine (a six core Intel i5 with 64 GB RAM), converting this file took over 15 minutes. I believe that this conversion time could be cut down significantly, simply by making the warm-up less expensive.
Thanks a lot for your help, indeed, it takes way too long with the direct conversion.
I used the following command to transcode to a .tiff
file:
wsic transcode -i /media/petros/PortableSSD/R22000049-1-A67-2___427399/ -o test.tiff
But it seems to flatten the pyramid and openslide then seems unable to find the mpp values when I run the second command:
wsic convert -i test.tiff -o test_svs_direct.svs -c jpeg
UserWarning: OpenSlide could not find MPP.
self.microns_per_pixel = self._get_mpp()
It seems like the following bfconvert command can do the trick when it comes to converting DICOM WSI to OME.TIFF:
bfconvert -noflat -compression JPEG R22000049-1-A67-2___427399/1.3.6.1.4.1.36533.147143106742241217322159521414914625468143.dcm conved_dicom.ome.tif
Would you mind sharing the commands you used? Thanks a lot.
Sure, I'll include some commands below.
The transcode function does not (currently) attempt to copy the pyramid resolutions. Wsic as a whole only operates on the baseline full resolution image. This is to keep the implementation simple, and because the downsample method used can vary from tool to tool and sometimes be of poor quality or corrupted. It was also targeted as computational applications where high levels are not typically needed, versus for viewing applications where they are commonly needed. You can, however, easily ask wsic to generate pyramid levels but supplying the -d
options. Future versions of the tool could attempt to copy existing level data, however this may complicate the implementation and I would like to keep it as simple as possible. Wsic could have an option to recreate the scales of the levels without too much complexity, which may be quite useful and a nice middle ground.
I'll have to look into the resolution issue, that sounds like a bug.
$ wsic transcode -i <input_path.dcm> -o <output_path.tiff>
$ wsic convert -i <input_path.tiff> -o <output_path.svs> -c jpeg -cl 90 -d 4 -d 8 -d 32
You can change the pyramid scales to other values, but I found these to work well with ImageScope.
Your files are likely slow due to using sparse tiling. I have been working on a branch to improve performance with such DICOM files. I have also raised an issue on the wisidcom repo and got a helpful answer here. I am also working on a branch to ask the user if they would like to make a full tiled copy before conversion, and the maintainers of wsidicom have also just added some optimizations which may help.
I'll try and make a release soon with all of the PRs merged to fix or alleviate some of these issues.
Version 0.8.0 is now out on pypi which may help. Also using wsidicom 0.9.0 may improve things.
EDIT: I made a careless mistake in the update! Hotfix patch coming soon. EDIT: All sorted in 0.8.2 🤞
Using wsidicom 0.9.0 and the latest wsic (https://github.com/John-P/wsic/pull/102), copying is now much faster even without making a TILED_FULL copy first. Hopefully you find the same :)
Description
Hello, I attempted to convert a DICOM wsi to svs using the following command and it failed:
I manually verified that the DICOM image I was trying to convert was readable on python using wsidicom.
Any ideas on how to do this? Any help would be much appreciated!
Thanks,
Petros