I am trying to run DicomImageReadWrite.cxxx example from ITK website in Visual Studio 2019.
I have my input dicom image in working directory and gave correct command arguments in Properties.
But still while running the example following box pops up and while debugging it is showing “DicomImageReadWrite.exe has triggered a breakpoint.” error.
I am also trying to run this example in my Linux ubuntu system but still it is not detecting my DICOM image. Even also trying with Reading dicom series and it shows “No dicoms in: SER01”
I get Assertion failed: 0, file C:\Libs\ITK-5.0.1\Modules\ThirdParty\GDCM\src\gdcm\Source\MediaStorageAndFileFormat\gdcmRescaler.cxx, line 336. The assert gets triggered here, during writing as unsigned char. That doesn’t seem to be supported any longer. If the line writer3->Update(); is commented out or removed, the example works.
@mathieu.malaterre, did when did GDCM lose the ability to write UCHAR images?
Interesting… That example, i took it from actual master branch Examples folder and run with arguments IMG019 out1.dcm out2.mha out3.dcm, seems to work for me if i comment out line: writer3->SetImageIO( gdcmImageIO );
Could you reproduce? Thanks. (Edit: i don’t have DCMTKIO compiled)
With or without setting UseInputMetaDataDictionaryOff.
So generally GDCMIO still can write UCHAR images.
The problem without editing the example seems to be
Slope=1 Intercept=-1024
Where it comes from is not clear just now (edit: it is from setting old gdcmImageIO, s. next post), writer takes re-scaled data and slope/intercept have to be 1/0 and function Rescaler::InverseRescale should exit here , before the switch with assert(0).
Edit: BTW, IMG019 has rather seldom transfer syntax Explicit VR Big Endian, but i don’t think it is related to problems, just FYI, if someone will investigate the issue.
OK, seems that it is wrong to use single instance of gdcmImageIO for reader and for writer3. For writer1 it seems to be the purpose to copy imageIO, but how it can work with another, very different data. If i print gdcmImageIO before setting it to writer3 it has already
That is reason for errors, highly likely, isn’t it?
Edit: regarding applying inverse re-scale to int8/uint8 images in general - FYI, it was once added inside ITK by this commit 2014, actually it is gone again. Anyway i think that part of example with writer3 is questionable. The re-scaled data is so different compared with original, it is not clear what the should be achieved by re-using the imageIO from the reader (patient name and id may be), anyway original slope and intercept should not be passed to re-scaled uchar image, it is clear.
I removed try & catch block of writer3->Update(); as you said.
But still the example is not working for me. It is showing the same error.
I don’t understand the reason.
Even I tried by removing writer3->SetImageIO( gdcmImageIO ); line.
That is also not working for me.
Do you have arguments IMG019 out1.dcm out2.mha out3.dcm?
With commenting out writer3->update or writer3->SetImageIO( gdcmImageIO ) there should be no assert, have tried just now again.
With one of both workarounds (disable writer3 update or don’t set imageIO) i have no assert, may be something trivial? I see two files DicomImageReadWrite.cxx at the screenshot. Sorry, just guessing. I am testing on Linux, but i don’t think there is difference with Windows.
Just commenting dfg does not work for me. I still get:
Warning: In C:\Libs\ITK-5.0.1\Modules\ThirdParty\GDCM\src\gdcm\Source\DataStructureAndEncodingDefinition\gdcmMediaStorage.cxx, line 526, function gdcm::MediaStorage::SetFromModality
Unknown/Unhandle MediaStorage, but Pixel Data element found
I don’t have DCMTK enabled in this build, maybe that’s the reason it works for you Mihail and not for me. I am testing on Windows.
I also tried the same example in Linux system. It is working when I remove writer3->Update; line.
But I don’t understand what is the problem with Visual Studio in Windows.
If I try other examples also, those are also not working.
GDCM did not lose ability to write 8bits image. The assert() you triggered indicate that you somehow try to rescale y = ax + b) onto an 8bits image. While this could be acceptable for academic, this does not make sense in the real world.
@mathieu.malaterre BTW, there was one change related to rescale/slope and char images done in this commit 5 years ago and disappered again later. Were interesting to know what do you think about. Thank you.