hello,

i test some syntax transfert to understoud the protocol...I am confused... my questions are about q/r and compare emulator.

i compare a file (allways the same) tansfered from server ( q/r emulator configured for explicit VR big endian only ) to a move-SCU with the same tansfert syntax (association explicit big endian for outgoing and incoming association).
but files are stored wiht c-move scu using other output transfert syntax). The first is in explicit little endiane, the second is in implict little endiane the last is in explicit big endian.

1)
tag of the 3 files show : the 3 output transfert syntax
explicit little endiane
implict little endiane
explicit big endian
compararor tell me than 2 files in explicit little endiane and implict little endiane have syntax tranfert tag differant bug same pixel data. Is it normal ? if yes i don't understand wath is difference between implicit and explicit. just big endian pixeldata is differant.

2)i use a c-move scu based on dcmtk.
Partial log of qr emulator show

QR_SCP_subDicomThread1
send A_ASSOCIATE_AC Message
presentation Context ID: ID:1
transfert syntax: 1.2.840.10008.1.2.2 (sound normal)
presentation Context ID: ID:3
transfert syntax: 1.2.840.10008.1.2.2 (sound normal)

but when i display
a StorageSubOperationAsScu

Send: A_ASSOCIATE_RQ Message
Application Context: 1.2.840.10008.3.1.1.1
Presentation Context Item(s):
Presentation Context ID: ID: 1
> Abstract Syntax: 1.2.840.10008.5.1.4.1.1.7
> Transfer Syntax: 1.2.840.10008.1.2.1
User Information:
> Maximum Length: 16384
> Implementation Class UID: 1.2.826.0.1.3680043.2.1545.1.2.1.7
> Implementation Version Name: dvt2.1

I dont understant why " 1.2.840.10008.1.2.1" explicit little endian. Logs of my movescu tell the transfert of file was in implicit little endian. and i dont understant why this transfert syntax ar not in "explicit big endian"

3)
the log of DicomThread "StorageSubOperationAsScu"
show a error :
Error: Could not find Command definition for SOP: 1.2.840.10008.5.1.4.1.1.7, Dimse: C-STORE-RSP

this message is only show in section "StorageSubOperationAsScu" but in general Dicom Thread "QR_SCP" section no error are displayed

but client tell "files are transfered succesfully!". So what is happends ??


thanks

Ps : if need i can post full log.

Hi lordglub,

I’m going to try to give an answer to all of you’re 3 questions. If you have after reading this reply still some questions, please feel free to ask them.

1:
There are a lot of different Transfer Syntaxes. Most of them focus on providing an optimal compression technology for the pixel data. The transfer syntax that always should be supported is ILE (Implicit Little Endian – 1.2.840.10008.1.2). The implicit means that the VR (Value Representation) of the attributes is not send over. The Little Endian denotes the byte ordering that is used. ELE (Explicit Little Endian – 1.2.840.10008.1.2.1) is the same as Little Endian but additional sends over the VR of the attributes. EBE (Explicit Big Endian, – 1.2.840.10008.1.2.2) uses a different byte ordering and sends over the VR of all the attributes.
The use of Implicit or Explicit does not result in a file difference that is detected by the DICOM Compare Tool except in the command set. The difference between Little Endian and Big Endian does result in a difference between the files, especially when it comes to the pixel data. If the rest of the file is encoded and decoded successful the DICOM Compare tool won’t show any differences.

2:
Each association that is setup agrees on an amount of presentation contexts that will be used. A presentation context is the combination of a SOP Class and a transfer syntax that will be used for it. During the association it is allowed to use any of the transfer syntaxes and sop classes that were agreed on.
In your example you are referring to two different associations. One is the association for the Query part, the looking for information. The second part is the actual Retrieval (move) of the information. Depending on configuration it is possible to use a different transfer syntax in both associations. Not also that during the query part there is no actual object send across the line. Only find results and queries are send over.

3:
The message you see is a known bug in the application. It is more a warning that is coming because of an issue in the application. You can ignore it safely since it doesn’t have any affect on the functionality of the application. It will be solved in a future release of the application.

Kind regards,

Floris.

thank you for your detailled responce !


i have made some test to be sure of my result.

not i have understout the difference between the different syntax.

first the transfert syntax in the metaheader show how the dicom file was writed and not how i was send over the network ? right ? ( it is just to be sure).

i have compare the same file and i dont see the result that i ame supposed have (after your responce). i have made an error in my last post. The detail of comparaison is:

explicit big endian : EBE
explicit little endian : ELE
implicit little endian : ILE

EBE vs ELE
tag 0002,0010 : 1.2.2 vs 1.2.1

EBE vs ILE
tag 0002,0000 : 182 vs 180
tag 0002,0010 : 1.2.2 vs 1.2
tag 7FE0,0010 : pixel data are differents

ELE vs ILE
tag 0002,0000 : 182 vs 180
tag 0002,0010 : 1.2.1 vs 1.2
tag 7FE0,0010 : pixel data are differents

so the lenght group is different ok
the transfert syntax is different ok

but for the pixel data big endian or little endian dont change the pixel data. after this result i can see than just explicit or implicit change the pixel data !!!!!!!!
wath compare exaclty comparator for tag 7FE0,0010 ( pixeldata )

ps : i investige on my question 2)

thanks

i can not edit my post:

i have write :
not i have understout the difference between the different syntax.

you must read :
Now i have understoud the difference between the different syntax.
;)

The behaviour of the DICOM Compare application you describe sounds incorrect. You van view the raw pixel data since it gets extracted into a separate file. If you look in the Compare application you will see a filename as value for the pixel attribute. If you open that file you will see the raw pixel data.

i have edit files with a hexadecimal editor so :

first i have used the instance wiht uid 100.118.116.2005.2.1.1132055943.781.1 in One^Secondary Capture Image study to my test transfert.

pixel data a file transfert in explicit big endian is named:
B08_0010.pix
pixel data a file transfert in explicit little endian is named:
B08_0020.pix
pixel data a file transfert in implicit little endian is named :
W08L0012.pix

Aaa it sound strange i suppose than 08 is for bits allocated or bits stored . B or W i suppose it is some information refering to data... L or "_" i have no idea end the 4 last caracter for a number.

if i edite all B files raw pixel data i can see before the transfer syntax "BB" and a "*"(the start is not always at teh same place but it is not a probelem for the comparator) but in W file raw pixel data i can see before the transfer syntax "WW" and a "*".
of sure in every pixel data the transfert syntax are different.

To test,
I have add a CT image from INCISIX study find on :
http://pubimage.hcuge.ch:8080
the 3 file tranfered in EBE ELE ILE genered in comparator a W type pixel data file and the comparaison betwen file wore fine et the only diffrence observed is in tag length et tag of syntax transfert

have you an idea about this probleme ??

file are downloadable on :
http://dl.free.fr/ru4Xvghcw

clic on telcharger ce fichier:

thanks