Stuart Golodetz wrote:
> Hi guys,
>
> I'm having a bit of trouble reading some slightly dodgy DICOM files I've
> been given; please could I have some help? I've stepped through the code
> and the problem seems to be that on line 210 of dcmimage.cxx, the condition
>
> else if (Document->getValue(DCM_PhotometricInterpretation, str))
>
> yields false (getValue returns 0). The images open fine in my copy of
> Sante DICOM Viewer, where it shows "Photometric Interpretation =
> MONOCHROME2" in the header, but the (rather less sophisticated) viewer
> on one of the hospital computers was having the same trouble as I'm
> having (possibly for the same reason).
>
> When I check the status returned from DicomImage::getStatus(), it says
> EIS_MissingAttribute (which I guess is not surprising, given that that's
> what gets set in one of the later branches of the "if" in dcmimage.cxx
> mentioned above).
>
> Any thoughts at all please? Sorry I can't give much more information -
> I'm really not sure where to start with this one unfortunately :-( Are
> there any tools which can fill in the missing attribute(s) perhaps? I'm
> happy to do a bit of faffing with the DICOM files to sort this out, but
> I can't find any information on where to start...
>
> Thanks!
> Stu

For the record, here are the error messages I'm getting when I run
various verification tools on one of the DICOM files in question. (And I
really should have mentioned that I'm using DCMTK, sorry!)

I'm still confused as to how to fix the problem though :s

Stu

***

C:\Users\Stuart\Documents\DPhil Work\Research\DICOM Tools>dciodvfy
f:/study000/i0000000.053
Warning - Value dubious for this VR - (0x0008,0x1070) PN Operators' Name
PN [0] = - Retired Person Name form
CTImage
Warning - Attribute is not present in standard DICOM IOD -
(0x0032,0x1032) PN Requesting Physician
Warning - Attribute is not present in standard DICOM IOD -
(0x0032,0x1060) LO Requested Procedure Description
Warning - Dicom dataset contains attributes not present in standard
DICOM IOD - this is a Standard Extended SOP Class

***

G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcmpschk f:/study000/i0000000.053 -v
================================================== =======
Testing: f:/study000/i0000000.053
================================================== =======

---------------------------------------------------------
Pass 1 - Inconsistencies between Meta-header and Data Set
---------------------------------------------------------

-------------------------------------------------------------
Pass 2 - Inconsistencies between Data Dictionary and Data Set
-------------------------------------------------------------

Warning: Attribute value uses retired form.
Affected attribute: OperatorsName (0008,1070), Type PN
Attribute value : [CY]

-------------------------------------------------------------
Pass 3 - Semantic Check of Presentation State Object
-------------------------------------------------------------

Not a Grayscale Softcopy Presentation State, skipping pass 3.

Test failed - one or more errors.

***

C:\Users\Stuart\Documents\DPhil Work\Research\DICOM Tools>dicom2
f:/study000/i00
00000.053
>> [W] [20:15:37]
ifbstream& sbmDicomDataElementSet::ReadFiltered( ifbstream&, const
sbmDic...
Skipped : 6 data elements (6 SQ/length = 0, 0 not found in dic.)

On Oct 7, 7:14*pm, Stuart Golodetz
wrote:
> Hi guys,
>
> I'm having a bit of trouble reading some slightly dodgy DICOM files I've
> been given; please could I have some help? I've stepped through the code
> and the problem seems to be that on line 210 of dcmimage.cxx, the condition
>
> else if (Document->getValue(DCM_PhotometricInterpretation, str))
>
> yields false (getValue returns 0). The images open fine in my copy of
> Sante DICOM Viewer, where it shows "Photometric Interpretation =
> MONOCHROME2" in the header, but the (rather less sophisticated) viewer
> on one of the hospital computers was having the same trouble as I'm
> having (possibly for the same reason).
>
> When I check the status returned from DicomImage::getStatus(), it says
> EIS_MissingAttribute (which I guess is not surprising, given that that's
> what gets set in one of the later branches of the "if" in dcmimage.cxx
> mentioned above).
>
> Any thoughts at all please? Sorry I can't give much more information -
> I'm really not sure where to start with this one unfortunately :-( Are
> there any tools which can fill in the missing attribute(s) perhaps? I'm
> happy to do a bit of faffing with the DICOM files to sort this out, but
> I can't find any information on where to start...

If I understand correctly, either PhotometricInterpretation is missing
or padded with a \0 (instead of a space).
Try using gdcmconv, by default it will feed in any missing attribute
necessary for reading the image, using default values.

$ gdcmconv --raw --force input.dcm output.dcm

--raw instruct to use uncompress transfer syntax
--force tells it to actually an operation even if input.dcm was alread
in some kind of uncompressed transfer syntax

Binaries for linux & win32:

https://sourceforge.net/project/show...ease_id=628923

otherwise you need to build it from source:

http://gdcm.sourceforge.net/wiki/ind...CM_Release_2.0

2cts
-Mathieu

> Any thoughts at all please? Sorry I can't give much more information -
> I'm really not sure where to start with this one unfortunately :-(

Did you check whether the PhotometricInterpretation is the only missing
data
element, e.g. using dcmdump or dcm2pnm (with verbose/debug mode anabled)?

If only PhotometricInterpretation is missing, it could be an old ACR/NEMA
image and you should be able to process it using the
CIF_AcrNemaCompatibility
flag in the DicomImage constructor or the --accept-acr-nema option if you
are using dcm2pnm.

Btw, there is a public discussion forum for DCMTK at
http://forum.dcmtk.org .

Regards,
Joerg Riesmeier

> G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcmpschk f:/study000/i0000000.053
[...]
> Not a Grayscale Softcopy Presentation State, skipping pass 3.

dcmpschk is not the right tool since - as you can read - it's main purpose
is to check GSPS objects and not DICOM images. The DCMCHECK tool [1] would
be more appropriate.

And, as I already wrote in my previous posting: Using dcm2pnm with verbose/
debug mode enabled should report the required details why this particular
DICOM image cannot be processed ...

Regards,
Joerg Riesmeier

[1] http://www.dcmtk.org/dcmcheck

Joerg Riesmeier wrote:
>> G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcmpschk f:/study000/i0000000.053
> [...]
>> Not a Grayscale Softcopy Presentation State, skipping pass 3.
>
> dcmpschk is not the right tool since - as you can read - it's main purpose
> is to check GSPS objects and not DICOM images. The DCMCHECK tool [1] would
> be more appropriate.

Thanks. I think I was a bit desperate at that point (long day) and was
trying almost any tool which seemed relevant. Mea culpa :-)

> And, as I already wrote in my previous posting: Using dcm2pnm with verbose/
> debug mode enabled should report the required details why this particular
> DICOM image cannot be processed ...

I did spot one of your old posts on that actually, and tried:

G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcm2pnm f:/study000/i0000000.053
-v -d > blah.pnm

But I didn't get any output at all (other than the .pnm file).

Cheers,
Stu

> Regards,
> Joerg Riesmeier
>
> [1] http://www.dcmtk.org/dcmcheck

Joerg Riesmeier wrote:
>> Any thoughts at all please? Sorry I can't give much more information -
>> I'm really not sure where to start with this one unfortunately :-(
>
> Did you check whether the PhotometricInterpretation is the only missing
> data
> element, e.g. using dcmdump or dcm2pnm (with verbose/debug mode anabled)?

I checked using dcmdump, yes. It doesn't seem to be missing, which is
puzzling:

(0028,0004) CS [MONOCHROME2] # 12, 1 PhotometricInterpretation

> If only PhotometricInterpretation is missing, it could be an old ACR/NEMA
> image and you should be able to process it using the
> CIF_AcrNemaCompatibility
> flag in the DicomImage constructor or the --accept-acr-nema option if you
> are using dcm2pnm.

I tried that as well actually (although I confess I wasn't quite sure
what I was doing and was just tinkering around...!), but no luck :-(

> Btw, there is a public discussion forum for DCMTK at
> http://forum.dcmtk.org .

Ok, thanks :-)

Stu

> Regards,
> Joerg Riesmeier

> G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcm2pnm f:/study000/i0000000.053
> -v -d > blah.pnm
> But I didn't get any output at all (other than the .pnm file).

Of course, if you are piping the complete output to the pnm file :-)

Please omit the ">" and it should work ...

Regards,
Jörg Riesmeier

Mathieu Malaterre wrote:
> On Oct 7, 7:14 pm, Stuart Golodetz
> wrote:
>> Hi guys,
>>
>> I'm having a bit of trouble reading some slightly dodgy DICOM files I've
>> been given; please could I have some help? I've stepped through the code
>> and the problem seems to be that on line 210 of dcmimage.cxx, the condition
>>
>> else if (Document->getValue(DCM_PhotometricInterpretation, str))
>>
>> yields false (getValue returns 0). The images open fine in my copy of
>> Sante DICOM Viewer, where it shows "Photometric Interpretation =
>> MONOCHROME2" in the header, but the (rather less sophisticated) viewer
>> on one of the hospital computers was having the same trouble as I'm
>> having (possibly for the same reason).
>>
>> When I check the status returned from DicomImage::getStatus(), it says
>> EIS_MissingAttribute (which I guess is not surprising, given that that's
>> what gets set in one of the later branches of the "if" in dcmimage.cxx
>> mentioned above).
>>
>> Any thoughts at all please? Sorry I can't give much more information -
>> I'm really not sure where to start with this one unfortunately :-( Are
>> there any tools which can fill in the missing attribute(s) perhaps? I'm
>> happy to do a bit of faffing with the DICOM files to sort this out, but
>> I can't find any information on where to start...
>
> If I understand correctly, either PhotometricInterpretation is missing
> or padded with a \0 (instead of a space).
> Try using gdcmconv, by default it will feed in any missing attribute
> necessary for reading the image, using default values.
>
> $ gdcmconv --raw --force input.dcm output.dcm
>
> --raw instruct to use uncompress transfer syntax
> --force tells it to actually an operation even if input.dcm was alread
> in some kind of uncompressed transfer syntax

Thanks, just tried that but not having any luck for some reason :-( I
wrote a program to generate a batch file to run gdcmconv on the entire
study, but still getting the same error when I try and load the
gdcmconv'ed images. Is there anything else I could try please?

Thanks,
Stu

> Binaries for linux & win32:
>
> https://sourceforge.net/project/show...ease_id=628923
>
> otherwise you need to build it from source:
>
> http://gdcm.sourceforge.net/wiki/ind...CM_Release_2.0
>
> 2cts
> -Mathieu

Joerg Riesmeier wrote:
>> G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcm2pnm
>> f:/study000/i0000000.053 -v -d > blah.pnm
>> But I didn't get any output at all (other than the .pnm file).
>
> Of course, if you are piping the complete output to the pnm file :-)
>
> Please omit the ">" and it should work ...
>
> Regards,
> Jörg Riesmeier

Ah ok, my bad. I assumed it was necessary because dcm2pnm was outputting
the pnm to the standard output stream when I forgot to specify a .pnm
file. Here's the new output:

G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcm2pnm f:/study000/i0000000.053
-v -d blah.pnm
reading DICOM file: f:/study000/i0000000.053
preparing pixel data.
disabling VOI window computation
writing frame 1 to blah.pnm
cleaning up memory.

I'm still confused though, because there's nothing there indicating that
there's any problem with the file, yet it doesn't load :s Is there
anything else I could try please?

Cheers,
Stu

On Oct 8, 2:08 pm, Stuart Golodetz
wrote:
> Joerg Riesmeier wrote:
> >> G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcm2pnm
> >> f:/study000/i0000000.053 -v -d > blah.pnm
> >> But I didn't get any output at all (other than the .pnm file).
>
> > Of course, if you are piping the complete output to the pnm file :-)
>
> > Please omit the ">" and it should work ...
>
> > Regards,
> > Jörg Riesmeier
>
> Ah ok, my bad. I assumed it was necessary because dcm2pnm was outputting
> the pnm to the standard output stream when I forgot to specify a .pnm
> file. Here's the new output:
>
> G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcm2pnm f:/study000/i0000000.053
> -v -d blah.pnm
> reading DICOM file: f:/study000/i0000000.053
> preparing pixel data.
> disabling VOI window computation
> writing frame 1 to blah.pnm
> cleaning up memory.
>
> I'm still confused though, because there's nothing there indicating that
> there's any problem with the file, yet it doesn't load :s Is there
> anything else I could try please?

Stu,

can you get an image out of gdcmimg ?

$ gdcmimg -i input.dcm -o output.pnm

Otherwise you'll have to either send a copy of your file (private
email is fine). Or at least the output of dcmdump/gdcmdump.

2cts
-Mathieu

Mathieu Malaterre wrote:
> On Oct 8, 2:08 pm, Stuart Golodetz
> wrote:
>> Joerg Riesmeier wrote:
>>>> G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcm2pnm
>>>> f:/study000/i0000000.053 -v -d > blah.pnm
>>>> But I didn't get any output at all (other than the .pnm file).
>>> Of course, if you are piping the complete output to the pnm file :-)
>>> Please omit the ">" and it should work ...
>>> Regards,
>>> Jörg Riesmeier
>> Ah ok, my bad. I assumed it was necessary because dcm2pnm was outputting
>> the pnm to the standard output stream when I forgot to specify a .pnm
>> file. Here's the new output:
>>
>> G:\My Stuff\dcmtk-3.5.4-win32-i386\bin>dcm2pnm f:/study000/i0000000.053
>> -v -d blah.pnm
>> reading DICOM file: f:/study000/i0000000.053
>> preparing pixel data.
>> disabling VOI window computation
>> writing frame 1 to blah.pnm
>> cleaning up memory.
>>
>> I'm still confused though, because there's nothing there indicating that
>> there's any problem with the file, yet it doesn't load :s Is there
>> anything else I could try please?
>
> Stu,
>
> can you get an image out of gdcmimg ?
>
> $ gdcmimg -i input.dcm -o output.pnm

It seems to work, yup (I don't actually have anything that can read .pnm
files on my laptop, but no error messages are thrown out).

I did wonder whether it was something to do with the way I was loading
the file:

new DicomImage(filename.c_str())

So I stepped through dcm2pnm and tried changing it to what was happening
there, including manually setting the various constructor parameters
(using the values shown when I ran dcm2pnm through the debugger):

DcmFileFormat *dfile = new DcmFileFormat;
OFCondition cond = dfile->loadFile(filename.c_str(), EXS_Unknown,
EGL_withoutGL, DCM_MaxReadLength, ERM_autoDetect);
DicomImage_Ptr dicomImage(new DicomImage(dfile, XS_LittleEndianExplicit,
36ul, 0, 1));

The only trouble is, I can step through both of them with the same input
file and get different results (stepping through them both side-by-side
a line at a time even...)

The only thing I can think of is that dcm2pnm might be doing some
important setup work before actually loading the file which I might not
be doing?

Cheers,
Stu

> Otherwise you'll have to either send a copy of your file (private
> email is fine). Or at least the output of dcmdump/gdcmdump.
> 2cts
> -Mathieu

> It seems to work, yup (I don't actually have anything that can read .pnm
> files on my laptop, but no error messages are thrown out).

So, why don't you use a different output format, e.g. BMP (--write-bmp)?

> The only thing I can think of is that dcm2pnm might be doing some
> important setup work before actually loading the file which I might not
> be doing?

The source code of dcm2pnm is available, so you could check what your code
is possibly missing.

Btw, I would suggest to continue the discussion in the DCMTK forum, because
it does not seem to be a general DICOM problem.

Regards,
Jörg Riesmeier

Joerg Riesmeier wrote:
>> It seems to work, yup (I don't actually have anything that can read
>> .pnm files on my laptop, but no error messages are thrown out).
>
> So, why don't you use a different output format, e.g. BMP (--write-bmp)?
>
>> The only thing I can think of is that dcm2pnm might be doing some
>> important setup work before actually loading the file which I might
>> not be doing?
>
> The source code of dcm2pnm is available, so you could check what your code
> is possibly missing.

Currently in the process of doing just that :-)

> Btw, I would suggest to continue the discussion in the DCMTK forum, because
> it does not seem to be a general DICOM problem.

Ok, will do.

Cheers,
Stu

> Regards,
> Jörg Riesmeier

On Oct 8, 3:22 pm, Stuart Golodetz
wrote:
> Joerg Riesmeier wrote:
> >> It seems to work, yup (I don't actually have anything that can read
> >> .pnm files on my laptop, but no error messages are thrown out).
>
> > So, why don't you use a different output format, e.g. BMP (--write-bmp)?
>
> >> The only thing I can think of is that dcm2pnm might be doing some
> >> important setup work before actually loading the file which I might
> >> not be doing?
>
> > The source code of dcm2pnm is available, so you could check what your code
> > is possibly missing.
>
> Currently in the process of doing just that :-)
>
> > Btw, I would suggest to continue the discussion in the DCMTK forum, because
> > it does not seem to be a general DICOM problem.
>
> Ok, will do.

As a side note, Stu sent me the image. It works fine for me. there is
asbolutely nothing wrong with his input file. I simply sent him back a
clean version (dcmconv +un) but I really do not see what can go wrong
with such a simple file (dcm2pnm works fine for me on linux).