|Message: Re: Bug in DICOM example /||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
I agree with you. My way of avoiding the "10" was to modify DicomHandler::GetMaterialIndex where the conversion from density to material index takes place, since i wanted to be notified if the density exceeds the range for which materials are given. (But the effect is the same.) I would say, setting the index to "9" is fine as long as there are really no other materials in the dicom data set used with the example, like hip implants etc. Otherwise a new material and interval have to be defined.
Other modifications i made are specific to the dicom files i am reading in, but i will report them here since similar problems may be encountered by others. They refer to v9.4.p02.
1) Tag 0x00201041 "Slice Location" is type 3, i.e. optional (cf. ftp://medical.nema.org/medical/dicom/2009/), and was not used in the dicom data set i had, so i had the problem of not having continuous slice numbering since "Slice Location" was 0 for every slice. I then decided to use the z coordinate in 0x00200032 "Image Position" instead which is type 2 and should be present in all dicom data sets. This works fine.
2) Reading of the actual image started 8 bytes too early. I realised that by having unrealistically high Hounsfield units and DicomHandler::Pixel2Desinty therefore issued "@@@ Error density = -1 ...". You find attached a screen shot of the contents of our file, where the tag for the start of the pixels is 0x7fe 0010. (This info is for the authors of the example.) I do not quote our bug fix here since it is neither general nor nice.
With these modifications, the example seems to work.
Best regards, Asja