From darcymason@gmail.com on January 23, 2014 19:01:28

This has come up from time to time, and I think it is a reasonable suggestion. Will give some thought as to how best to work it in. I don't like assuming numpy is available (many users have much simpler needs), so it should be some kind of configurable option.

Status: Accepted
Labels: -Type-Defect Type-Enhancement

From thomas.p...@gmail.com on January 23, 2014 23:37:35

Thanks for considering.
If someone doesn't have or does not want to use numpy, chances are that the pixel data is not of interest anyway or that a plain mmap handle would be sufficient.

that would be fantastic - I could use it, too. Hopefully Thomas you are reading this and consider a PR ...

As someone who abuses mmap for speeding things up in pydicom and were we could go...

1. A fair amount of "slowness" in reading large files was in the small reading window that was being used Default read_size in read_undefined_length_value() in fileutil.py is too small and slows down reading large DICOM files #436 that should now be fixed.

2. If you don't need the image, putting stop_before_pixels=True means you can read the non-pixel data within a handfull of ms.

Thinking about strategy:

I don't think the numpy.mmap is the best way - as we not only need to specify a start byte in the file, but also end (there is allowed to be padding / junk after the pixel data in DICOM).

We would probably have to mmap the whole file, then pass a view to numpy, then reshape.

Whether it is worth pulling out the existing code and replacing it with mmap; or closing the file and reopening it wiht mmap when you wan't the PixelData I don't know - what do you think?

Ideally - I am aiming to fix this for compressed data as well - as I want to be able to very quickly load only the first frame (when I show all files in a directory); and then when playing a very large file decompress the frames as they are being shown the first time; but cache the results.

Does anyone know how to detect / know where the frame/slice boundries in compressed PixelData without readingin it - is there an index, or do I have to search for delimiters?

Matt

@mshunshin The value of the Basic Offset Table item can be used to determine the frame boundaries within the Pixel Data element value (see PR #534). The item value is not required, however (see PS3.5 A.4).

Pushing this milestone back again to get v2.0 out first.

Closing this - I believe it has been shown elsewhere that you can open a memmap file and pass the handle to dcmread, which gives a workable solution.