I found a really bad bug in the DCMTK reader. When I wrote it, I got rows & columns mixed up in assigning image dimensions. Until now no one had ever run into it because either they never use DICOM files, or they only use DICOM series with square slices.
I've spent a couple of hours trying to write a test for this, that would write a DICOM series of non-square slices. Turns out it's not that easy -- the DCMTK reader depends on DICOM tags to be in the DICOM file in order to read them in successfully, and the DICOM writer (GDCM) I have access to doesn't fill them out properly. I can simply use some anonymized real-world data to do this, but it's disconcerting we can write files that aren't actually readable. Is there some trick to this that I'm missing? Looking at the GDCM tests, there are places they write GDCM files, but they actually read a DICOM file first and copy the MetaDataDictionary onto the output in order to get the flags in. -- Kent Williams [email protected] ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
