Failure to view a seemingly valid SM series: "resolutions must be sorted in descending order"
#175
Comments
fedorov
changed the title
resolutions must be sorted in descending order"resolutions must be sorted in descending order"
Sure, I'll take a look at it. |
|
@fedorov This was caused by rounding the zoom factor. (level 0) This way the resolutions array will be [16, 16, 1], and although its descending OpenLayers assertion doesn't allow equivalent numbers, the resolutions array should be composed of unique resolutions in descending order. Removing the rounding here: https://github.com/ImagingDataCommons/dicom-microscopy-viewer/blob/bda0cfea6f906a7c46f525cad2a5210d0722869b/src/pyramid.js#L211 Results: |
|
This is interesting. Why would there be two resolutions that are so close to each other? I would want to wait to hear back from @dclunie to confirm this is expected. @DanielaSchacherer have you ever seen this in any other dataset? |
|
This is indeed interesting. As you might remember we also had some issues with different resolutions being available or not being available and how to deal with that. But I can't remember that we had two resolutions being so close to each other. |
|
I never encountered a problem like this. |
|
Upon discussing this with @dclunie today, it is very suspicious that it is the thumbnail image that has nearly the same resolution as one of the pyramid layers. David will look again at the data and conversion process. No action from you at this point @igoroctaviano! Thank you for the investigation. |
|
Though it is unusual for the thumbnail to have a pixel spacing close to one of the other pyramid layer files, this seems to be what is actually in the TIFF file and the way the images actually are - look at the MPP values and the Image Width and Image Length for the relevant entries; so the issue does not seem to be with the data but the viewer's inability to handle this unusual situation (of two layers of similar size - not sure if "Avoid rounding zoom factors that are too close to avoid duplicated resolution errors" #107 fixes this or not): |
The PR addresses the issue. If the rounded zoom factor conflicts with an existent one, I'm using the zoom factor value rounded to three decimals which doesn't cause conflicts with existent ones and loads the image fine. We could just skip the "too close" resolution too. |
@igoroctaviano can you please help with this? This is a top priority at the moment, since it blocks ingestion of a dataset on our side.
We have Slim failure for this case: https://andrey-slim-test.web.app/studies/2.25.55130914676639429536393362988538406158/series/1.3.6.1.4.1.5962.99.1.1070220424.1519847303.1697582335112.4.0 (restricted access, @igoroctaviano should be clear)
That study/series is located in this DICOM store: https://healthcare.googleapis.com/v1/projects/idc-sandbox-000/locations/us-central1/datasets/fedorov-dev-healthcare/dicomStores/mci-test/dicomWeb (restricted access, @igoroctaviano should be clear), and also in this bucket folder: https://console.cloud.google.com/storage/browser/af-dev-storage/idc-conversion-outputs-mci-test/0DBVRM_121349.
This is the error:
Those images were converted by @dclunie, and he had to say the following about this error:
The text was updated successfully, but these errors were encountered: