-
Notifications
You must be signed in to change notification settings - Fork 5
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
Difference behaviour between WsiDicomFileSource and WsiDicomWebSource #163
Comments
Hi @ChristianMarzahl Limiting WsiDicom to only handle pyramid levels of same tile size was an early design decision. I'm not sure if it is still needed, if it with some effort the restriction could be removed, or how common it is with DICOM WSI-files with non-uniform tile size. Handling WSIs with non-uniform tile size differently when opened by DICOM Web was not intended. I can try to create some test files with non-uniform tile size, but it would also be helpful to know where the library fails when you open your example as DICOM Web. For the second issue, my interpretation of the standard is that the server should respond with 406 (Not Acceptable) when the requested transfer syntax is not accepted. Does the more generic 400 (Bad Request) response from Google DICOM Archive give a clear status reason that can be used to check if the error is due to the requested transfer syntax? |
I played around a bit with disabling the tile size check together with a slide with levels with tile sizes of 200, 300, and 400 pixels. In the images that you have encountered, what levels are of different tile size? Is relaxation to allow different tile sizes a wanted feature or is it better to drop them (and implement the same checks for the DICOM web source)? |
@ChristianMarzahl
Please try this on your problematic WSI. Also please provide the HTTP error message for Google DICOM archive on unsupported transfer syntax. |
Dear @erikogabrielsson, Thank you very much for looking into it. Best, |
Hi,
First of all, thank you very much for providing this great library.
I noticed a difference in the handling of the same DICOM file provided by WsiDicomFileSource and WsiDicomWebSource through a DICOMWeb interface.
The WsiDicomFileSource filters the DICOM levels for matching tile_size and UIDs:
wsidicom/wsidicom/file/wsidicom_file_source.py
Line 274 in b0d097c
This filtering is not done in WsiDicomWebSource:
wsidicom/wsidicom/web/wsidicom_web_source.py
Line 58 in b0d097c
This discrepancy can lead to DICOMs that can be opened via file but not via the web interface. I wanted to ask if this was intended.
Regarding the same topic of opening images via file or DCMWeb:
wsidicom/wsidicom/web/wsidicom_web_source.py
Line 102 in b0d097c
If the DICOMWeb server does not support JPEG2000, for example, as a transfer syntax and throws an exception (requests.exceptions.HTTPError: 400 Client Error: BAD REQUEST for url: Google DICOM Archive), the code only catches 406 exceptions.
wsidicom/wsidicom/web/wsidicom_web_client.py
Line 218 in b0d097c
With kind regards,
Christian Marzahl
The text was updated successfully, but these errors were encountered: