_pixel_data_numpy in dataset does not respect Planar Configuration

[GoogleCodeExporter]

See: https://www.medicalconnections.co.uk/kb/Planar_configuration for a 
definition of the field tag. It appears that the reshaping assumes that Planar 
Configuration=1.

Original issue reported on code.google.com by arothb...@4combinator.com on 3 Jul 2014 at 3:15

[GoogleCodeExporter]

Going through the issues list, coming back to this.  Does anyone have example 
files that illustrate type 0?  It should be fixable with a numpy rearrangement 
of the data, but it would be good to have examples to confirm correct behaviour.

Original comment by darcymason@gmail.com on 2 Nov 2014 at 8:47

• Changed state: Accepted

[GoogleCodeExporter]

I think you can convert a file from one format to another using dcmdjpeg

planar configuration options:

          +pa   --planar-auto
                  automatically determine planar configuration
                  from SOP class and color space (default)

          # If the compressed image is a color image, store in color-by-plane
          # planar configuration if required by the SOP class and photometric
          # interpretation. Hardcopy Color images are always stored color-by-
          # plane, and the revised Ultrasound image objects are stored color-by-
          # plane if the color model is YBR_FULL.  Everything else is stored
          # color-by-pixel.

          +px   --color-by-pixel
                  always store color-by-pixel

          # If the compressed image is a color image, store in color-by-pixel
          # planar configuration.

          +pl   --color-by-plane
                  always store color-by-plane

          # If the compressed image is a color image, store in color-by-plane
          # planar configuration.

Original comment by arothb...@4combinator.com on 2 Nov 2014 at 8:53

[GoogleCodeExporter]

I fixed the issue here: 
https://github.com/cancan101/pydicom/commit/4113792397c3e26336cd864db8062905f069
b553 for when PlanarConfiguration==0

Original comment by agrothberg on 6 Nov 2014 at 12:42

[GoogleCodeExporter]

I'm not familiar with color images, but after reading a bit, I agree that the 
fix looks correct, but unfortunately it is a backwards-incompatible change, 
because the order of indices of pixel_array is changed (SamplesPerPixel is 
moved from first index to last index). As you mention, that would be correct 
for PlanarConfiguration=1, but it seems that PlanarConfiguration of 0 is the 
dicom default.  Code out there might have rearranged the order to compensate, 
so I'm thinking to introduce this in pydicom 1.0, where there will be other 
backwards incompatible changes.
While we are at it, then, a couple of thoughts.  The code should not assume 
PlanarConfiguration is specified, so should check ('PlanarConfiguration' in ds) 
before testing it (and set a local variable to 0 if not there).  Also, there 
should be the correct branching for PlanarConfiguration of 1 also.

Original comment by darcymason@gmail.com on 9 Nov 2014 at 2:06

• Added labels: Priority-High, Milestone-Release1.0
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Maybe I don't understand the backward comptabile argument, but what would be 
wrong with something like:

if self.PlanarConfiguration==0:
   arr = arr.reshape(self.NumberOfFrames, self.Rows, self.Columns, self.SamplesPerPixel)
else:
   arr = arr.reshape(self.SamplesPerPixel, self.NumberOfFrames, self.Rows, self.Columns)

That should correctly handle both PlanarConfiguration==0 (the DICOM default) 
and PlanarConfiguration==1.

I would be curious as to how current users are able to work around the parsing 
issues when opening color files with PlanarConfiguration==0. I solved the issue 
with the above linked patch.

Original comment by agrothberg on 9 Nov 2014 at 9:04