Skip to content
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

Memory usage (sometimes 15x from the size of dicom file) #291

Open
vitalii-komenda opened this issue Oct 17, 2023 · 1 comment
Open

Memory usage (sometimes 15x from the size of dicom file) #291

vitalii-komenda opened this issue Oct 17, 2023 · 1 comment

Comments

@vitalii-komenda
Copy link

dicom.ParseFile() method expands memory a lot. I have a service that gets OOM killed because of this method uses so much memory

@suyashkumar
Copy link
Owner

suyashkumar commented Nov 5, 2023

Thanks for the info! Any more details you can share on your use case? Note that we have options to not read (or not parse) PixelData if that makes sense for your use case. #267 might also help, depending on what you're trying to do e.g if you're doing element by element processing you will never have to hold the whole dicom in memory at once. Also, what version of the library are you using?

See more performance discussion in #161 (in particular #161 (comment)), but there's a known situation where underlying native dicom integer data will be expanded from smaller ints (e.g. int8s) to int (usually int64, mostly in the name of having a consistent API for pixel data), but we might be able to hold the data as a Wrapper[T] where T is {int8, int16, int32, etc} at some point in the future. Also note the data is copied when generating an image.Image (here) for now (which for now takes only a uint16).

I'll take another pass at ways to reduce memory footprint for native images without compromising the API too much, esp now that we have generics.

If you're using the native pixel data, I'd love to know a little more about the use case as well! Are you working with the raw values at all?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants