On 28.05.2012 16:01, Clarkson, Matt wrote: > Hi there
Hi Matt, > > 1. Tag 0020,0037 (patient orientation) is a direction cosines matrix. If > different slices have slightly different matrices due to rounding error, > the loaded image is split into multiple volumes: > https://github.com/MITK/MITK/blob/master/Core/Code/IO/mitkDicomSeriesReader.cpp#L861 Do you have examples (or example data) of how much is "slightly different"? I was not aware of such minor differences from a single modality so far. But I guess if such images exist, it would be a valid correction to accept some minor differences here. I am not sure how much we should tolerate. We should consider impact on distance or volume measurements, which should not be negatively influenced by "nice" loading corrections. > > 2. In our images, tag 0020,0037 (patient orientation) may be missing. > https://github.com/MITK/MITK/blob/master/Core/Code/IO/mitkDicomSeriesReader.cpp#L936 This one is harder. The tag is required by the DICOM Image Plane module and without it we cannot make sure that we do not mix images of different orientations (which do exist, mixed into one series). Also, the spatial image sorting (shortly after the line you pointed out) could not possibly work without that tag. We could guess about the correct orientation and expect that our sorting still works somehow, but I guess this will surely produce cases that don't work as expected. My suggestion would be to modify your images, but I'm also curious about different solutions. > > 3. In our images, tag 0020, 0032 (patient position) may be missing. > https://github.com/MITK/MITK/blob/master/Core/Code/IO/mitkDicomSeriesReader.cpp#L936 Same as above, just more severe because we could not even sort spatially in many cases. > > 4. In our images, tag 0020,000d (Series Instance UID) may be missing. > https://github.com/MattClarkson/MITK/blob/master/Core/Code/IO/mitkDicomSeriesReader.cpp#L853 Also a required tag. Extremely unusual for modalities to produce images without that tag. I would not mind much to add a flag/option for the loader to ignore that tag and sort only depending on other tags. This should be the exception and not the default, however. The simpler solution would be to correct your DICOM images. dcmodify can help much here. > > 5. Image loads as signed short, but not as unsigned short. i.e. if we > force the templating to only load as signed short, it looks ok, > otherwise, the data is not loaded, and image appears blank. > https://github.com/MattClarkson/MITK/blob/master/Core/Code/IO/mitkDicomSeriesReader.cpp#L152 > This sounds bad. Do you have example data that you could upload somewhere? Of course types should be interpreted correctly. > 6. Reportedly, image fails to load first time resulting in a blank > volume, but then simply doing a File Open and trying again loads the > image correctly. Also severe. If you can provide example data, I would take a look into it. > policy. From a code perspective, it might be nice to provide a way to > easily plug-in a class that decides if we can handle a certain image, > like a Chain Of Responsibility pattern? I can imagine something like callback functions at different points to influence which images will be loaded into a single mitk::Image or how they are spatially sorted or even something that leaves the whole loading to a callback. If we find a couple of good places in the loading code where to put such modifications safely, we can work that out. Kind regards Daniel -- Dr. Daniel Maleike Telefon: + 49 6221 647976 3 Mint Medical GmbH, Friedrich-Ebert-Straße 2, 69221 Dossenheim/Heidelberg Geschäftsführer: Dr. Matthias Baumhauer Registergericht Mannheim, HRB 709351 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
