jpr [Tue, 14 Mar 2006 12:09:18 +0000 (12:09 +0000)]
BUG: Newer version of the software on Siemens MR write proper lenght.
GDCM was overriding without checking for wrong length first.
Can now read old (broken) and new Siemens DICOM files.
Thx to Mathieu.
jpr [Mon, 13 Mar 2006 14:44:07 +0000 (14:44 +0000)]
// User should ask gdcm to write an image in Explicit VR mode
// only when he is sure the VR of *all* the DataElements is known.
// i.e : when there are *only* Public Groups,
// or *all* the Shadow Groups are fully described in
// the relevant Shadow Dictionnary.
// Let's just *dream* about it; *never* trust a user !
// If he doesn't, it write process will produce an 'illegal' Dicom image.
// (it doesn't bother most of Dicom readers, but ...
// Therae are enought illegal Dicom image in the world.
// Don't add illegal gdcm-written Dicom images !
In order to avoid furter troubles,
We turn to Implicit VR if at least the VR of one element is unknown.
jpr [Wed, 1 Mar 2006 09:45:04 +0000 (09:45 +0000)]
Some clinical softwares refuse to perform some operations, when images are 'not
native' (i.e. SOP Class UID -> [Secondary Capture Image Storage]), and
gdcm-written images fail.
At write time, gdcm has absolutely *no way* to guess if the image is 'native' or
not.
User is now allowed to specifiy what he wants to do (*he* knows, not gdcm !)
using the method :
void FileHelper::SetContentType (ImageContentType c);
(if you find a more significant name, feel free to tell me ...)
just before writting.
We have to deal with 4 *very* different cases :
-1) user created ex nihilo his own image and wants to write it as a Dicom image.
c : USER_OWN_IMAGE
-2) user modified the pixels of an existing image, using mathematical operations.
c : FILTERED_IMAGE
-3) user created a new image, using existing images (eg MIP, MPR, cartography image)
c : CREATED_IMAGE
-4) user modified/added some tags *without processing* the pixels (anonymization..
c : UNMODIFIED_PIXELS_IMAGE
'Image Type' (0x0008,0x0008)
Conversion Type (0x0008,0x0064)
are set to values supposed to be constistant (hope so)
The reminding of the private method FileHelper::CheckMandatoryElements() remains
unimpared.
/**
* \brief Gets a std::vector <double> holding the value(s) of a DS DataEntry
* @param valueVector std::vector <double> of value(s)
* \return false if VR not "DS" or DataEntry empty
*/
Thx to Vicent Daanen for suggesting.
jpr [Tue, 28 Feb 2006 15:10:12 +0000 (15:10 +0000)]
> # Seems this one hangs on 64 bits processors ?!?
> # I blacklist it untill the pb is solved.
> (to get some more green on the Dasboards)
> "MR_Philips-Intera_BreaksNOSHADOW.dcm"
jpr [Wed, 1 Feb 2006 10:46:53 +0000 (10:46 +0000)]
Since we don't modify pixels -> keep unchanged the following :
// 'Media Storage SOP Class UID' (0x0002,0x0002)
// 'SOP Class UID' (0x0008,0x0016)
// 'Image Type' (0x0008,0x0008)
// 'Conversion Type' (0x0008,0x0064)
We use :
fh->SetKeepMediaStorageSOPClassUID(true);
jpr [Tue, 31 Jan 2006 14:09:26 +0000 (14:09 +0000)]
Since grid tagging is quote either 'ROW' or 'COL' (nobody can guess it !),
user is kindly requested to supply the autoref keyword 'taggrid' when he knows.
jpr [Tue, 31 Jan 2006 11:39:47 +0000 (11:39 +0000)]
Add the method int ElementSet::IsVRCoherent( uint16_t group )
To check whether *all* the DataEntries of the group have all
the same type for VR (ImplicitVR or ExplicitVR)
@param group group number to be checked
@return 1:ImplicitVR 2:ExplicitVR -1:NotCoherent
jpr [Tue, 31 Jan 2006 11:32:06 +0000 (11:32 +0000)]
The automatic set to VR = "LO" for shadow elements that could be
is now commented out in order not to generate 'Shadow Groups' where some
Data Elements are Explicit VR and some other ones Implicit VR
(Stupid MatLab DICOM Reader couldn't read gdcm-written images)
jpr [Thu, 26 Jan 2006 09:22:23 +0000 (09:22 +0000)]
Try to warn user when 'DeflatedExplicitVR' Transfer Syntax found.
--> Still to be done :
find a trick to stop the processing.
--> Still to be done (*later*)
. find a trick to uncompress the whole Dataset and go on Parsing, whitout having
to create a temporary file
. find a trick not to uncompress the Pixel Group every time !
jpr [Tue, 3 Jan 2006 14:28:53 +0000 (14:28 +0000)]
Refine message displaying. Now, we have :
* Warning : Warns the user when some oddity occured, and we used an heuristics
* to bypass the trouble.
* e.g. : SamplesPerPixel missing, we assume it's a grey level image
* e.g : Pixel Representation missing : we assume 'unsigned'
* (we hope our assumption is OK, but user may disagree.)
* Log : we display messages when anything is not Dicom Kosher
* e.g. : non even length field
* e.g : file is declared as Explicit VR, but a DataElement
* is Implicit
* e.g : a file holds an illegal group (0x0005, ...)
* Debug : We help developper to trace, at a glance, the execution.
(before refining with a debugging tool)
* Setting ON Debug leads to set ON Warning (but not Log)
* Setting ON Log leads to set ON Warning (but not Debug)