Harmonize pixel data representations

[suever]

From darcymason@gmail.com on May 27, 2009 22:58:02

A pydicom "gotcha" comes from disconnect between Dataset.pixel_array property and Dataset.PixelData. The latter is actually in the Dataset (a dict), the former is created from it but changes are not written back unless ds.PixelData is explicitly set with e.g. pixel_array.tostring().

Possible solutions:

• always require Numpy, always convert pixel data into numpy array. Problem is this requires decompressing JPEG data (which is not available yet in pydicom and would possibly waste time on a step that might never be used if the code is not modifying pixels).
• link pixel_array and PixelData together. if pixel_array is asked for, keep reference to it in dataset instance and automatically do tostring() before data is written. But what if user modified pixel_array and modified PixelData directly (current code would do that using the tostring() method mentioned above). Could see which one was modified most recently and use that as the definitive final value, or could throw an error or warning of possible inconsistent pixel data changes. This idea means PixelData probably needs to be redefined as a property so can flag writes to it. That makes it 'special' and different than other items in the Dataset dict, but perhaps that is necessary.

I like the second idea better, but am hoping someone can come up with an even cleaner solution.

Original issue: http://code.google.com/p/pydicom/issues/detail?id=49

[suever]

From martin.s...@gmail.com on September 17, 2009 16:37:11

The secound lazy approach sounds better to me too, however...

The modification of pixel_array may also effect; Rows, Columns, Bits Stored, Smallest Image Pixel Value, Largest Image Pixel Value. Perhaps pixel_array should be a class corresponding to an Image Pixel Module (PS 3.3 - 2008 C.7.6.3).

If the pixel_aray were requested, then the workflow could be to attempt to extract a representation of an Image Pixel Module from a DICOM file, which could raise an exception if there are problems with the tags.

To get around editing data in two places, and having it crash. In the case that attempts were made to read one of these tags and the module had been changed, then the module could write itself back to the tags. In the case that any attempts were made to write, then the module could update itself or return to a state that it will lazily evaluate itself again if required.

This concept could potentially be extended to other DICOM modules. With the various modules extending from a common base.

[suever]

From darcymason@gmail.com on September 23, 2009 06:09:46

Martin, you've given some good ideas here -- the idea of a Module object is very interesting. Conceptually I've always thought of pydicom as a low-level library, just reading files and giving back a bag of data elements, requiring the user code to structure their meaning and make sure they are self-consistent. However, perhaps there is room to add a Module layer on top. I'd like to see it be explicit (as per the usual "Explicit is better than Implicit" python philosophy) -- in other words, the user calls code that is clearly operating at the Module level. This could mean a new "SmartDataset" object, say, or a dataset.modules object that calls are made to when you want self-consistency to be enforced. To do it in a general way (not just for Pixel data) would require some thought and a significant amount of new code (and IOD definitions files). I've added a new issue ( issue 57 ) for this.

[suever]

From darcymason@gmail.com on December 23, 2011 19:30:33

Changing status as this is not a priority for next release.

Labels: -Milestone-NextRelease Milestone-Release1.5