DICOM @ OFFIS

Thanks again for your report (and your feedback). The fix has just been committed to the git repository.

Of course, you could convert the PDF to a common image format (bitmap) and then use img2dcm for the creation of a DICOM SC image.

Does it work when you apply the following patch? diff --git a/dcmdata/tests/telemlen.cc b/dcmdata/tests/telemlen.cc index d30dcb7..3724057 100644 --- a/dcmdata/tests/telemlen.cc +++ b/dcmdata/tests/telemlen.cc @@ -1,6 +1,6 @@ /* * - * Copyright (C) 2011, OFFIS e.V. + * Copyright (C) 2011-2012, OFFIS...

Yes, because internally the length value passed to the constructor is stored, but the memory is not allocated.

Could you please try to construct the DcmFloatingPointSingle with len=0 and then call putFloat32() in increasing order of the pos parameter, i.e. 0, 1, 2, ... This is because (taken from the API documentation of DcmElement): * @param pos position for insert operation. Value: pos <= getVM(), i.e. a v...

Unless the private tag is part of the data dictionary (which includes the VR), you have to specify the VR explicitly to the DcmTag constructor. See the following HOWTO.

This is the git commit: http://git.dcmtk.org/web?p=dcmtk.git;a= ... 395ccd134e
And here is the regression test: http://git.dcmtk.org/web?p=dcmtk.git;a= ... 94787b10d3

Good catch! Thank you for the report and suggested fix. I would propose the following (slightly different) patch: diff --git a/dcmsr/libsrc/dsrtree.cc b/dcmsr/libsrc/dsrtree.cc index 5b666c3..4cea6b0 100644 --- a/dcmsr/libsrc/dsrtree.cc +++ b/dcmsr/libsrc/dsrtree.cc @@ -1,6 +1,6 @@ /* * - * Copyrigh...

Which version of the DCMTK are you using?

Btw, the "len" parameter in the DcmFloatingPointSingle constructor takes the length in bytes and not the number of values (VM). And, there is also a putFloat32Array() method ...

Almost correct, and the main purpose of the DICOM image class is visualization/display of images, i.e. not accessing raw data. So, the access to the internal representation has been added later because many users asked for it. Btw, the modality LUT transformation is already applied to the internal p...

If you need the raw (not the rendered) pixel data, then getInterData() is what you should probably use.

Did you alredady check this recent patch? http://git.dcmtk.org/web?p=dcmtk.git;a= ... 1c8170d06d

Reading the documentation should help:

Nothing is wrong. By default, no VOI window is selected, so the whole range of input values is mapped to the available range of output values. Read about VOI (Value of Interest) transformation if you do not understand this ...

Did you already check what the output of dcm2pnm for this particular image is? If it's bad, does it improve with option +Wm?