search

GoogleCloudPlatform / wsi-to-dicom-converter

Conversion tool/library for converting whole slide images to DICOM
Apache License 2.0
77 stars 26 forks source link

Image Center Point Coordinates Sequence #38

Open nutzlastfan opened 4 years ago

nutzlastfan commented 4 years ago

Hi, first thank you for the work this is a really good conversion tool.

Second this is more of a feature request is it possible to calculate the X and Y Offsets (0040,072A) ,(0040,073A) ?

I am using the resulting dicom with a slide microscopy plugin for ohif dicom viewer which needs these values for calculating the overlays when drawing points of interest.

pavertomato commented 4 years ago

Are you sure this is something what can be calculated just by data from tiff file? seems like this is something what is specified after modification of original image, if zero values is good enough for you, you may specify those tags by json file https://github.com/GoogleCloudPlatform/wsi-to-dicom-converter#jsonfile

nutzlastfan commented 4 years ago

The base image is in svs format and actually I am not sure myself, the orthanc wsi converter seems to calculate these values somehow but fails for newer svs images. Zero values do not work, from testing it seems as it has to be at least the width (x) and height(y) values for the offset, anything particularly higher or some default value does not work. I have not looked to deep into what metadata the svs has to provide to get working values.

pavertomato commented 4 years ago

The base image is in svs format and

svs is basically tiff

actually I am not sure myself, the orthanc wsi converter seems to calculate these values somehow but fails for newer svs images. Zero values do not work, from testing it seems as it has to be at least the width (x) and height(y) values for the offset, anything particularly higher or some default value does not work. I have not looked to deep into what metadata the svs has to provide to get working values.

yeah, seems like this tags is just pixel position of tile recalculated in mm, it may be added to metada if size of image is present in svs or json tags, or may be you can try to generate TILED_FULL dicom, may be ohif can handle it

nutzlastfan commented 4 years ago

TILED_FULL is the default I using right now. Would the converter use the value if it was present in the svs ?

pavertomato commented 4 years ago

but TILED_FULL does not contains tile position metadata, have you tried TILED_SPARSE with ohif?

Would the converter use the value if it was present in the svs ?

not yet, but if i'll have free time i'll implement this feature, it seems quite simple

nutzlastfan commented 4 years ago

Same result, that would be very nice, I could provide sample svs files, other than that i am not much of a help in this case.

pavertomato commented 4 years ago

Same result, that would be very nice, I could provide sample svs files, other than that i am not much of a help in this case.

yeah, would be great to have some test data to make sure it works like expected

nutzlastfan commented 4 years ago

Can I send you a link directly ?

pavertomato commented 4 years ago

Can I send you a link directly ?

sure

nutzlastfan commented 4 years ago

Hi, thanks for the work, but the it doesn't seem to generate the tags. I compiled it with the changes but the output files look the same not sure what is wrong.

pavertomato commented 4 years ago

Hi, thanks for the work, but the it doesn't seem to generate the tags. I compiled it with the changes but the output files look the same not sure what is wrong.

have you generated dicom with sparse parameter? https://github.com/GoogleCloudPlatform/wsi-to-dicom-converter#sparse

nutzlastfan commented 4 years ago

Yes that works, the tags are there.. but they sit nested for each tile inside (5200,9230) SQ PerFrameFunctionalGroupsSequence , which is not interpreted from the viewer. Normally it would look for the values on the top level where the other 0048,xxxx tags are. image

pavertomato commented 4 years ago

Yes that works, the tags are there.. but they sit nested for each tile inside (5200,9230) SQ PerFrameFunctionalGroupsSequence , which is not interpreted from the viewer. Normally it would look for the values on the top level where the other 0048,xxxx tags are.

https://dicom.innolitics.com/ciods/vl-whole-slide-microscopy-image/vl-whole-slide-microscopy-image-multi-frame-functional-groups/52009230/0048021a according to this docs slide coordinates have to be inside of (0048,021A), and (0048,021A) have to be inside of (5200,9230)

on the top level where the other 0048,xxxx tags are.

but those tags frame specific, it have to be inside of some sequence, it can't be top level

do you have some error message from viewer to make sure we are on the same page?

nutzlastfan commented 4 years ago

It hangs on:

metadata.TotalPixelMatrixOriginSequence[0];

i think it is not looking for the seqequence where it should be / Problem with the metadataprovider. I will contact the developers. Thank you.

function _coordinateFormatGeometry2Scoord3d(coordinates, pyramid) { let transform = false; if(!Array.isArray(coordinates[0])) { coordinates = [coordinates]; transform = true; } const metadata = pyramid[pyramid.length-1]; const origin = metadata.TotalPixelMatrixOriginSequence[0]; const orientation = metadata.ImageOrientationSlide; const spacing = _getPixelSpacing(metadata); const offset = [ Number(origin.XOffsetInSlideCoordinateSystem), Number(origin.YOffsetInSlideCoordinateSystem), ];

pavertomato commented 4 years ago

I will contact the developers. Thank you.

if it's ohif you may mention me and i help if i could

nutzlastfan commented 4 years ago

Yes it is, I have done that, thanks for the help so far.

igoroctaviano commented 3 years ago

@pavertomato I got some feedback from Markus (dicom-microscopy-viewer maintainer) regarding Denny's test data for this issue.

He found out that several type 1 and type 2 attributes were missing in this dataset, including the TotalPixelMatrix in the top level which is a type 1 (required).

The VOLUME images seem to extend beyond the slide, i.e., larger image (Column, Row) total pixel matrix coordinates map to negative (X, Y) slide coordinates. It seems image position or image orientation are wrong. For series 1.2.276.0.7230010.3.1.3.2239900507.13211.1608803103.713303 he used image position (13.679949, 13.679213, 0.0).

He said he wouldn't trust the spatial information contained in these data sets based on what he saw. The constraints in the viewer could be relaxed and allow visualization and annotation of images that extend beyond the slide, but I think that would be a bad idea. If data sets are fundamentally incompliant with the standard (missing type I attributes) or contained information is wrong (incorrect image position and orientation), the viewer should refuse to display.

In this case, maybe worth another round of checks in the converter regarding these attributes + this dataset? I also want to know if the converter currently calculates or add defaults for any missing DICOM attribute, because if cases like this exists, maybe it could try to incoming datasets?

pavertomato commented 3 years ago

thank you @igoroctaviano sorry for delay, i'll try to understand this issue again this week also @nutzlastfan - links to examples which you have sent me by email are expired, and i don't have my local copy, could you please send it one more time?

igoroctaviano commented 3 years ago

(Update) The problem was figured out here: https://github.com/MGHComputationalPathology/slim/issues/32