Two points:
1. Validating against our test images is always going to be problem. The dicom standard allows such variabililty that it we are going to have very serious problems with regression errors if we just go in and do obvious fixes based on dashboard reported errors. I can't see us putting an entire dicom test suite into the vil tests. Dicom images produced by real scanners are usually huge. I think we have to rely on dcmtk being correct, and slowly and carefully deal with errors in the dcmtk<->vil_image_resource translation. If this means leaving tests failing for a while, so be it.
 
2. I suspect that value PIXELPADDINGVALUE, and others like it should have the same sign as the pixels themselves. Since this is a run-time decision, using a union of signed and unsigned values may be appropriate.
 
Ian.
-----Original Message-----
From: Martin G. Roberts
Sent: Wednesday, February 04, 2004 5:58 PM
To: 'perera@cs.rpi.edu'; 'On'
Cc: Chris Wolstenholme; Ian Scott
Subject: Dicom reader - ambiguity of pixel padding sign

Dear Amitha,

Firstly I did not receive your email regarding this, probably because our internal email servers recently changed our proxy addresses, so I probably need to change the one on SourceForge to domain man.ac.uk (not isbe.man.ac.uk). Apologies therefore in not noticing this.

 

As regards the actual change, I can only imagine this is due to a change in the pixel_padding type in the dicom header.

I changed this from unsigned short to signed short in order to get the code to compile at all under gcc-Linux. The contradiction was that this is being read using the SS (i.e. signed short) template specialisation in vil_dicom. Gcc objects to the type conflict, though MSVC 6 and 7 appear to accept it. The DICOM dictionary I have unhelpfully defines the PIXELPADDINGVALUE attribute to be either signed or unsigned. I presume the test data requires unsigned, but of course the code might still fail on any file which adopted the other half of the ambiguity.

 

I will refrain from expressing my personal opinions on a standard which permits such an ambiguity, and will happily change it back to unsigned if the VXL community decide that is the VXL DICOM standard; however I would then change the read to an unsigned specialisation also.

 

Sorry if I inadvertently caused a test fail, but I view that as at least an improvement on a compilation fail.

Finally I would not be too surprised if the test data file was not strictly conformant anyway. We need to decide how to interpret the ambiguity of the “standard”; not necessarily get the code to read a hand-written 5*3 test file if 90% of real manufacturers have gone for the signed option.

 

So any requests: Signed or Unsigned for PIXELPADDINGVALUE ?

Vote now…

 

I will consistently amend to requested majority on Friday and change test if necessary.

Or do we need two attributes: one signed, one unsigned and a bool to say which one is valid?

Martin Roberts