GNOME Bugzilla – Bug 313008
Mistake in DICOM format file creation
Last modified: 2008-01-15 12:58:43 UTC
Please describe the problem: The Patient Sex (0010,0040) attribute is incorrect. Patient Sex (0010,0040) is a type 2 attribute. This means that when the correct value is not known, the attribute tag is present but the value field shall be of zero length. This might be fixable by just changing the string from "?" to "", but I didn't track through the various subroutines involved to see whether they handle encoding null strings correctly. Steps to reproduce: 1. Save an image as a DICOM file 2. Examine the file. Patient Sex (0010,0040) is present as "?", which is an illegal value. 3. Actual results: Expected results: The Patient Sex (0010,0040) should have a zero length value field. Does this happen every time? Yes Other information: I have not run the resulting objects through a DICOM validator. I just looked at the file with a hex editor. There might be other problems. The GIMP does not comply with the full set of DICOM media storage requirements, but it never claims compliance. There might be no need. Other programs can do this separately from GIMP. One side effect of this is the need for the file reader to guess the transfer syntax. The guess logic used is usually right, so that is a minor issue. Guessing is needed anyhow to deal with other systems that also do not comply.
Looks like a simple change to do, setting on the 2.2 milestone.
Created attachment 50471 [details] [review] patch as applied to the HEAD branch
Fixed in HEAD branch, should be backported to the stable branch also. Perhaps someone could check the spec beforehand and verify that this is indeed the right change to do... 2005-08-09 Sven Neumann <sven@gimp.org> * plug-ins/common/dicom.c: use an empty field instead of "?" for the unknown value (bug #313008).
I went ahead and merged this change into the stable branch: 2005-08-24 Sven Neumann <sven@gimp.org> Merged from HEAD branch: * plug-ins/common/dicom.c: use an empty field instead of "?" for the unknown value (bug #313008).