DICOM @ OFFIS

Thank you for you proposal. I've added it to our to-do list in order to make sure that it doesn't get lost.

When the fileformat is written, some data elements in the meta information header are updated or added (if they were missing before) - see DcmFileFormat::validateMetaInfo(). So, I guess that the "missing bytes" are caused by this ...

Btw, why do you want to create a DICOM file in memory?

Are there any other differences in the environment, e.g. environment variables that are used by DCMTK set or unset? Memory exhausted ...

What exactly is the returned condition and what is the output in verbose/debug mode?

Are you sure that an overlay plane is an appropriate solution, e.g. does the viewing workstation support DICOM overlays at all?

".raw" is not an image format, so I cannot answer your question. If the image data is monochrome or RGB color or something like that, it should be no problem to make it "DICOM-compatible" without much computing time. However, before starting to implement anything based on the DIC...

I was was asking what "count" is because you probably understood the API documentation wrong: fstart first frame to be processed (optional, 0 = 1st frame), all subsequent use of parameters labeled 'frame' in this class refers to this start frame. fcount number of frames (optional, 0 = all ...

As a default, as least for Windows systems where it is difficult to find an appropriate default directory, we sometimes use the value of "argv[0]" which contains the name of the executable binary. This value is passed to a library function that uses e.g. the Windows API function SearchPath...

What is "count" in your sample code? Why don't you just follow what the referenced Howto shows?

The two tags are usually not present on the main dataset-level but in a nested sequence (e.g. Radiopharmaceutical Information Sequence (0054,0016)). And, as you can read in the documentation , findAndGetElement() by default does not search into sequences. Btw, why are you using the numeric tags and ...

As far as I know, and I'm not the developer of OFConfigFile, you have to use upper case characters only in the program, i.e. not necessarily in the config file.

Without knowing any details on your acquisition process, I guess that storing the image data (RGB uncompressed, MPEG-2 or whatever) directly in a format that is compatible with DICOM would be a first step. You could then store the acquired image data directly in a memory buffer provided by the DCMTK...

No, we haven't tested DCMTK under real-time conditions. However, since DICOM does not support streaming of data (at least not natively), I guess that you need to buffer the data anyway.

The overlay planes are associated with frame 90 and 118. Other than that I cannot find any abnormalities: The overlay planes are rendered as expected when using the patched version of dcmj2pnm.

You should probably ask the OsiriX people whether they support overlays in multi-frame images at all.

Have you already tried to use upper case characters for the section names and keywords, i.e. "DEFAULT" and "HTTPPORT"?

Of course, this is possible with DCMTK. A very simple example on how to do this can the found in the documentation (see the second example). Depending on your "raw data", you might also need/want to use putAndInsertUint16Array() or createUint8/16Array() instead of putAndInsertUint8Array()....