-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DicomFile.Open with ReadAll fails for files larger than Int.Max bytes long #1453
Comments
Looking at the code, the other implementations of |
Similar to #1163 , 2 GB read/write issue |
@rprouse - looks like you know how to fix this - do you want to create a PR? |
I know how to fix it and started a PR, but I was unable to dynamically create a Dicom file big enough to add a proper unit test and I'm not going to add a 2GB file to the repo. I can test locally against files I have. Would that be good enough for you? Or do you know how I can use the library to create a big enough file to use in a unit test? |
I don't have a good idea right now, but maybe somebody else does. I would suggest you submit the PR without a test (given that you tested it locally we can be reasonable sure that the fix does what is should), and we can discuss this in the PR. I personally would be fine with it even if we don't find a way to write a suitable test. |
I gave this a pass tonight but ran into the issue that the max size of a byte array in C# is |
Would it be correct to say that the issue is that a single DICOM tag value (presumably PixelData) exceeds 2GB? I could also be of assistance to have a large DICOM file. We could commit a black image with huge resolution in JPEG Lossless. The compressed file would be small because all pixels are black, but when converted to Explicit VR the raw image would be huge. In any case, if you want some help with this, ping me. |
It is the pixel data. Problem is that I am not sure how much time I will have to work on it. We are using DCMTK. I found this issue evaluating this library but we are not using it. And I'm falling behind maintaining my own projects like NUnit. |
Don't worry about it, thanks for letting us know about this issue then. |
A little update on this. I can confirm that Fellow Oak DICOM successfully saves & opens a DICOM file that is >4GB in size. The bug in Fellow Oak DICOM was that, due to using I've added a unit test that generates a >4GB DICOM file on the fly, with two fragments larger than 2GB, saves it to a temporary file and loads it again. This works now. |
@amoerie, @gofal Is there a way to open a DICOM file using unseekable stream? I see |
Describe the bug
We have modalities sending large Dicom files that are over
Int.Max
bytes long, an example that I unfortunately can't share is 2,359,297,856 bytes long. When we attempt to open them withFileReadOption.ReadAll
, it crashes with an inner exception, "ArgumentOutOfRangeException: Non-negative number required. Parameter name: count" This is happening more as modalities are producing higher resolution imaging.The issue is that in
FileByteSource.GetBuffer(uint count)
the number of bytes to read is passed in as auint
butBinaryReader.ReadBytes(int count)
takes anint
. When theuint
is cast to anint
it goes negative. To fix,if (count > Int.Max)
, we should read into theMemoryByteBuffer
in two passes. Longer term, as files get larger, we should probably pass a long intoGetBuffer
and loop appropriately. The other methods likeSkip
are taking auint
and passing it toSeek
that takes along
, so those are fine.To Reproduce
DicomFile.Open(Filename, FellowOakDicom.FileReadOption.ReadAll);
with a file over 2.2 GB. Will also happen if any dataset is more than 2.2 GB.Expected behavior
No exception is thrown
Screenshots or test DICOM files
I will see if I can get a Dicom file I can share without private data but will need to work with the customer.
Environment
Fellow Oak DICOM version: 5.0.3
OS: Windows 10 x64
Platform: .NET Framework 4.8
The text was updated successfully, but these errors were encountered: