HELP : DICOM initialization failure (version 2)
budhik
got in this forum. Here is the result dcm file. You can download it at
www.materikuliah.com/DICOMTEST2.zip (it was zipped).
Yes, this still can't be initialized by any DICOM viewers and tools.
Please review it and tell me what's going wrong.
Thank you for your comments, suggestions, and helps.
Best regards,
Budhi
David Clunie
a VR of UL (correct) and a VL of 4 (correct) but you have only encoded two
bytes for the value itself, not 4.
David
David Clunie
It posted successfully, but it may be too long for some news hosts,
like Google.
I put the text of the message, as well as the original DICOM file
sample at:
http://idisk.mac.com/dclunie-Public/ECG/
David
budhik
> By the way, Budhi, did you get my complete example the other day ?
>
> It posted successfully, but it may be too long for some news hosts,
> like Google.
>
> I put the text of the message, as well as the original DICOM file
> sample at:
>
> http://idisk.mac.com/dclunie-Public/ECG/
>
> David
>
> budhik wrote:
> > Hi, I already revised my code based on comments and suggestions that I
> > got in this forum. Here is the result dcm file. You can download it at
>
> > Yes, this still can't be initialized by any DICOM viewers and tools.
> > Please review it and tell me what's going wrong.
>
> > Thank you for your comments, suggestions, and helps.
>
> > Best regards,
> > Budhi
Hi David,
I have downloaded the ecg.dcm and ecg.txt from your idisk folder. It
can be read by using DVTK dicom editor, but when I tried to view it by
using dicom ecg viewer (http://www.excel-medical.com/waveforms/Viewer/
DicomWaveformViewer.htm), it can not be read. I don't know why.
Btw, as I wrote my code based on your and other replier of comments in
this group, I suspect that the problem is on the translation of VR's
attributes into C's data type and the value length mis-understanding.
For example, in VR of "US", the max length is 2 byte. But in C code, I
should declare an unsigned short (since unsigned int can be 2 or 4
bytes depend on our machine architecture; in my PC unsigned int will
be represent as 4 bytes / 32 bit). Also for example, VR of "DS" with
max length 16 bytes. I'm not sure whether it should be declare as
char, unsigned char, or unsigned int, because the value can be
numeric.
So please help me to mapping these VRs and C data types :
VR | Max Length | C Data type
AE | 16 | .......
AS | 4 | .......
CS | 16 | .......
DA | 8 | .......
DS | 16 | .......
IS | 12 | .......
LO | 64 | .......
OB | - | .......
OW | - | .......
PN | - | .......
SH | 16 | .......
SQ | - | .......
ST | 1024 | .......
TM | 16 | .......
UI | 64 | .......
UL | 4 | .......
US | 2 | .......
Another question :
If I have (0008,0013) with VR of "TM" and value "165520", since "TM"
max length is 16 bytes, should I declare in my C code unsigned short
(numeric 16 bit / 2 byte) or unsigned char[16] or unsigned char[6] or
what ? I'm so confuse about this mappings.
Please advise,
Budhi
budhik
> On Jul 18, 9:04 am, David Clunie <dclu...@dclunie.com> wrote:
>
>
>
> > By the way, Budhi, did you get my complete example the other day ?
>
> > It posted successfully, but it may be too long for some news hosts,
> > like Google.
>
> > I put the text of the message, as well as the original DICOM file
> > sample at:
>
> >http://idisk.mac.com/dclunie-Public/ECG/
>
> > David
>
> > budhik wrote:
> > > Hi, I already revised my code based on comments and suggestions that I
> > > got in this forum. Here is the result dcm file. You can download it at
Hi,
I already mapped the VRs into C data type based on section 6.2 dicom
spec file number 5.
Based on that, I revised the code and generate new dcm file. This file
shall contains ecg signals from the text file.
You can see the dcm and txt file here (zipped) : www.materikuliah.com/DICOMTEST3.zip
and www.materikuliah.com/12ecgsample2.zip
The text file contains stream of 12 lead ecg signal which is separated
into 14 column : time, ID, lead I, lead II, lead III, lead aVR, lead
aVL, lead aVF, lead V1, lead V2, lead V3, lead V4, lead V5, lead V6.
But still, the dcm file can't be initialized. I don't know why. I
already compared my dcm file with 39da47b7.dcm (downloaded from
http://www.excel-medical.com/waveforms/Waveform.htm), and I found the
meta section seems the same. The only differences are waveform data
and several info like patient name etc.
Please give me further advises.
Best regards,
Budhi
David Clunie
budhik wrote:
>> I have downloaded the ecg.dcm and ecg.txt from your idisk folder. It
>> can be read by using DVTK dicom editor, but when I tried to view it by
>> using dicom ecg viewer (http://www.excel-medical.com/waveforms/Viewer/
>> DicomWaveformViewer.htm), it can not be read. I don't know why.
Actually there are two issues with this file that may have caused problems
with that viewer:
- the waveform bits allocated is > 8 but the explicit VR for the waveform
data attribute is OB, which is illegal - my validator was not checking
for that so I hadn't noticed
- there are two multiplex groups, the first containing the 12 lead ECG and
the second contained some derived waveforms
I have corrected the file to use the OW VR, and the result is in this
folder:
http://idisk.mac.com/dclunie-Public/ECG/
It displays fine with my own ECG viewer, which always uses only the first
multiplex group and ignores the rest. See the screenshot at:
http://idisk.mac.com/dclunie-Public/ECG/
You can try the viewer at:
http://www.dclunie.com/pixelmed/software/webstart/ECGViewer.html
David
David Clunie
You cannot depend on the internal C or C++ data type lengths.
You need to explicitly handle the number of bytes to be written
and the order in which those bytes are written for all the binary
DICOM VRs. The internal representation only has to be a) long
enough, and b) handle sign extension properly if you are going
to perform arithmetic or comparison on those values.
All the string and text VRs can be handled as arrays of char, and
padded to even length and the correct length written.
That includes DA, TM, DT and DS ... those are all strings when
encoded (regardless of whether they are stored "internally" as
long or double or whatever).
Why don't you just look at the source of one of the many C++ or
Java toolkits ?
David
David Clunie
> Based on that, I revised the code and generate new dcm file. This file
> shall contains ecg signals from the text file.
> You can see the dcm and txt file here (zipped) : www.materikuliah.com/DICOMTEST3.zip
> and www.materikuliah.com/12ecgsample2.zip
...
> But still, the dcm file can't be initialized. I don't know why. I
> already compared my dcm file with 39da47b7.dcm (downloaded from
> http://www.excel-medical.com/waveforms/Waveform.htm), and I found the
> meta section seems the same. The only differences are waveform data
> and several info like patient name etc.
% andump /Users/dclunie/Downloads/DICOMTEST3.dcm
(0x0002,0x0000) UL File Meta Information Group Length VR=<UL> VL=<0x0004> [0x0000008c]
(0x0002,0x0001) OB File Meta Information Version VR=<OB> VL=<0x0004> [0x01,0x00,0x02,0x00]
(0x0002,0x4955) ? VR=<UN> VL=<0x2e31001e> [] # skipping ...
% dciodvfy /Users/dclunie/Downloads/DICOMTEST3.dcm
Warning - Bad File Meta Information Version Attribute - wrong VR, length or not 0x00,0x01
(0x0002,0x4955) ? Error - Tag read failed - Implicit VR encoding even though supposed to be explicit
Error - Dicom dataset read failed
budhik
Hi,
I don't understand how the mis-interpretation happened. As we can see,
the bit values are the same.
The 39da47b7.dcm :
02 00 01 00 4f 42 00 00 02 00 00 00 00 01 02 00 02 00 55 49
and my DICOMTEST3.dcm :
02 00 01 00 4f 42 00 00 02 00 00 00 00 01 02 00 02 00 55 49
How can my file was interpreted as (0002,4955) when the 39da47b7.dcm
was interpreted as (0002,0002) and "UI" ???
All the meta values are the same. The different things are : the value
of date, patient name, and waveform signal.
Is the DICOM waveform file should has the same end of bits of the
file ?
Please advise,
Budhi
budhik
Hi, I already upload the 4th result file in www.materikuliah.com/DICOMTEST4.zip
(it was zipped).
The good thing is the dcm file can be opened by using Dicom
Inspector .Net , and I can see the wrong length of VR and the wrong
value also. I already fix them based on David's ecg_ow.dcm file and
39da47b7.dcm file.
But, again, it can be initialized. I suspect the next wrong thing is
in the waveform data syntax.
Here is my (5400,1010) "OW" with 0x0000 of reserved and 0xffffffff of
length (in C code) :
------- headers -----
typedef struct specstruct {
unsigned int ge;
unsigned char vr[2];
unsigned short reserved;
unsigned long vl;
};
struct specstruct metaspec;
float date,id,I,II,III,aVR,aVL,aVF,V1,V2,V3,V4,V5,V6;
------- main (bla... bla...) ----------
fpecg = fopen("12ecgsample2.txt", "r");
fscanf(fpecg,"%f %f %f %f %f %f %f %f %f %f %f %f %f %f", &date, &id,
&I, &II, &III, &aVR, &aVL, &aVF, &V1, &V2, &V3, &V4, &V5, &V6);
metaspec.ge = 0x10105400;
strcpy(metaspec.vr,"OW");
metaspec.reserved = 0x0000;
metaspec.vl = 0xffffffff;
fwrite(&metaspec,sizeof(metaspec),1,fp);
while (!feof(fpecg))
{
fwrite(&I,sizeof(I),1,fp);
fwrite(&II,sizeof(II),1,fp);
fwrite(&III,sizeof(III),1,fp);
fwrite(&aVR,sizeof(aVR),1,fp);
fwrite(&aVL,sizeof(aVL),1,fp);
fwrite(&aVF,sizeof(aVF),1,fp);
fwrite(&V1,sizeof(V1),1,fp);
fwrite(&V2,sizeof(V2),1,fp);
fwrite(&V3,sizeof(V3),1,fp);
fwrite(&V4,sizeof(V4),1,fp);
fwrite(&V5,sizeof(V5),1,fp);
fwrite(&V6,sizeof(V6),1,fp);
fscanf(fpecg,"%f %f %f %f %f %f %f %f %f %f %f %f %f %f", &date, &id,
&I, &II, &III, &aVR, &aVL, &aVF, &V1, &V2, &V3, &V4, &V5, &V6);
}
---------- continue to the end --------------
The signal value of each ecg channels are in float numbers %2.6f.
Question :
1. Is it correct to write the stream of signals without delimiter
between signals ?
2. Should it (the signals) converted first into hex before written
into the file ?
3. How to count the group length (0002,0000) value ?
4. Is the (003a,0010) number of waveform samples should be exactly the
same with the number of lines of signals in the text file ?
Please advise,
Budhi
budhik
This is the newest result : www.materikuliah.com/DICOMTEST6.zip
Based on Dicom Inspector .Net, all tags are OK. The last problem is in
waveform padding data and waveform data encoding itself.
1. Should I use delimiter code like "," or " " between successive
signals ? I know the queue should be C1S1, C2S1,C3S1, ... CnS1,C1S2,
C2S2, C3S2, ... CnSm. In the supplement 30, it was "with no padding or
explicit delimitation between successive samples" written. But I have
tried both, with and without delimitation code, but still not works.
2. Since my raw data is in float format (i.e. 122.001245 or %3.6f
format), is it possible to load them directly ? Or should I use only
decimal number (i.e. 20 or %d format) ?
Please advise,
Budhi
budhik
Just asking, does this forum related with this one :
http://fixunix.com/dicom/509550-help-dicom-initialization-failure-version-2-a.html
??
Because all records are shown in that URL.
Budhi
Mathieu Malaterre
You cannot do that, you need to differentiate based on VR value:
7.1.2 DATA ELEMENT STRUCTURE WITH EXPLICIT VR
You need a special handling for the following VRs:
...
VL32 = OB | OW | OF | SQ | UN | UT, // if( VR & VR_VL32 ) => VR
has its VL coded over 32bits
...
Do not reuse meta data info from other people
(1.3.6.1.4.1.6018.2.11111), you need to set it one yourself.
-Mathieu
David Clunie
The values are concatenated together with no delimiters
(neither ascii, not the Item delimiters that are used with
undefined length Pixel Data ... all waveform data requires
defined length).
If the values in your text file are floating point values
that are going to be truncated during conversion to 16 bit
integers, scale them using Channel Sensitivity (003A,0210).
E.g., if your floating point data is in mV, multiply the
values by 1000 before encoding them as 16 bit words, and
send a value of 0.001 for Channel Sensitivity. E.g., given
float aVR:
long aVRvalue = (long)(aVR*1000);
I mentioned before not depending on the native C data types.
A call like fwrite(&something,sizeof(something),...) is unsafe
for two reasons:
- the number of bytes written is dependent on the compiler and the
host and target
- the byte order written is dependent on the target machine
For each value written you must extract the bytes that you want
into an array of char in the correct order and write it by hand.
E.g. given a 16 bit value in long value to be written as a US or
OW little endian:
char buffer[2];
buffer[0]=(char)(value&0xff);
buffer[1]=(char)((value>>8)&0xff);
fwrite(buffer,2,...);
This does depend on char being one byte (always true) and a byte
always being 8 bits (normally true).
The value length (in bytes) of the Waveform Data attribute is the
number of samples * number of leads * the number of bytes per sample
(which is 2 for OW).
The group length of the meta-information header is required, so you
need to add up the number of bytes that you are going to write,
before writing them.
David
David Clunie
and Synchronization Frame of Reference UIDs, if you are doing
all this by hand without a toolkit ?
budhik
@Mathew
In DICOMTEST6.dcm I already followed the VL32 rules. For
implementation class uid, I will set myown after the result file
correctly viewed.
@David
I just identified which are the mandatory tags for the 12 lead ECG
only, and write them one by one in C code.
By the way, I don't clearly understand with your explanations :
1. ------ all waveform data requires defined length----- how to do
that ?
2. ------- if your floating point data is in mV, multiply the values
by 1000 before encoding them as 16 bit words, and send a value of
0.001 for Channel Sensitivity-----
Yes, my raw data are in millivolt. For example, my data is 2.596498.
After divided (it's divided, not multiplied right ?) by 1000, it is
0.002596498 volt. How to convert 0.002596498 into 16 bit words in C ?
And how to get the channel sensitivity's value by using this result ?
I'm so sorry for my delayed understanding.
Budhi
Mathieu Malaterre
> On Jul 21, 7:09 pm, David Clunie <dclu...@dclunie.com> wrote:
>
> > By the way, how are you going to generate SOP, Series, Study
> > and Synchronization Frame of Reference UIDs, if you are doing
> > all this by hand without a toolkit ?
>
> @Mathew
>
> In DICOMTEST6.dcm I already followed the VL32 rules. For
> implementation class uid, I will set myown after the result file
> correctly viewed.
well then you cannot set an undefined length for VR=OW
-Mathieu
Mathieu Malaterre
>
> > By the way, how are you going to generate SOP, Series, Study
> > and Synchronization Frame of Reference UIDs, if you are doing
> > all this by hand without a toolkit ?
>
> @Mathew
>
> In DICOMTEST6.dcm I already followed the VL32 rules. For
> implementation class uid, I will set myown after the result file
> correctly viewed.
>
> @David
>
> I just identified which are the mandatory tags for the 12 lead ECG
> only, and write them one by one in C code.
>
> By the way, I don't clearly understand with your explanations :
IMHO David is referring -among other- to the UID generation. See PS
3.5 - 2008
Section 9 Unique Identifiers (UIDs)
This is not easy to implement in an open source toolkit (that everyone
can use), it may be easier for you if you control which particular
hardware/machine will be running your code.
-Mathieu
budhik
wrote:
What do you mean ? Please explain me how to fix it.
Best Regards,
Budhi
Mathieu Malaterre
You are inserting a data element: (5400,100a) with VR=OW but at the
same time VL=u/l (== -1). You cannot do that u/l VL is reserved for
SQ and UN vr only. Compute the actual length of your binary blob and
set that length.
HTH
-Mathieu
budhik
Hmm.... OK.
So, if I have bits like this (explicit VR little endian) :
00 54 0a 10 4f 57 00 00 02 00 00 00 00 08
It means :
00 54 0a 10 = tag (5400,100a) : waveform padding value
4f 57 = "OW" (the VR value)
00 00 = 0000h reserved bits for VL32 encoding
02 00 00 00 = 2 bytes of value length (32 bit encoding)
00 08 = 2048 (in decimal)
Question :
What is the meaning of 2048 ? Since I read in the supplement 30
specification that "Equipment which produces digitized waveform curves
may encode a specific value when the source is disconnected or
otherwise invalid. This value is encoded like the Waveform Data
attribute with one sample only. The Waveform Padding Value need not be
within the range specified by the Channel Minimum and Maximum Data
Values"
In my case, if I have a stream of signals, let's say :
2.602857 0.388133 0.285276 3.504505 3.658790 0.336704 0.015254
0.218097 1.083970 1.732829 0.262715 0.461522 (all in millivolt)
What should I put for my (5400,100a) value ?
Please advise,
Budhi