AT VR's are not returned properly as JSON

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load a SOP Instance that has a AT VR (e.g. an Ultrasound clip or XA cine 
clip)
2. Access the field via the /content endpoint (e.g. Frame Increment Pointer or 
0028-0009)
3. Observe that the tag is not returned (e.g. I get x18 when I should get 
0018-1063)

What is the expected output? What do you see instead?
I see x18 and I should see 0018-1063

What version of the product are you using? On what operating system?
0.84, Windows

Please provide any additional information below.

Original issue reported on code.google.com by cha...@gmail.com on 4 Sep 2014 at 1:18

[GoogleCodeExporter]

Thanks for reporting this issue! Would you kindly provide a (possibly 
anonymized) DICOM file for the Orthanc community to reproduce this problem?

Original comment by s.jodo...@gmail.com on 4 Sep 2014 at 7:18

[GoogleCodeExporter]

Try these images:

http://www.triltech.com/SampleImages/SAMPLE_CV_IMAGES.zip

Look for the FrameIncrementPointer 0018,1063 tag.

NOTE: I have no affiliation with the hosting site so they may take down this 
link at any time. 

Original comment by cha...@gmail.com on 8 Sep 2014 at 2:10

[GoogleCodeExporter]

Hi,

I have just created a small Python script to dump the raw, hexadecimal content 
of the "FrameIncrementPointer" tag for each of the files you sent, using the 
"/content" endpoint (cf. attachment).

This script does dump the value you expect (either "18006510" or "18006310", 
depending on the DICOM file). I guess that you see "x18" because your script 
assumes that the result will be a string encoded with UTF-8, instead of a raw 
buffer as specified for AT VR: https://www.dabsoft.ch/dicom/5/6.2/

Original comment by s.jodo...@gmail.com on 8 Sep 2014 at 3:06

Attachments:

• DumpFrameIncrementPointer.py

[GoogleCodeExporter]

I can't think of any good reason to return the raw buffer for AT VR's.  It is 
referring to a DICOM Tag which can always be converted into a string form which 
will be easier for clients to consume (especially javascript).  You already 
convert other binary types like UI and US to string, why not make it consistent 
in this regard?

Original comment by cha...@gmail.com on 8 Sep 2014 at 3:16

[GoogleCodeExporter]

The specification of the "/content" URI is that it returns the raw value of the 
tag, as stored in the DICOM file. There is no interpretation of this raw 
buffer, even for UI and US VRs.

There are only 2 exceptions to this rule:
1- PixelData (7fe0,0010), that is decoded taking into account the transfer 
syntax.
2- SQ VR (sequences), that are interpreted to allow the exploring of the DICOM 
tag hierarchy using the REST API.

However, you are of course perfectly right about the fact that the "/tags" URI 
should contain the converted string for AT VRs (instead of a "null" value as 
returned by Orthanc 0.8.2), as it is already the case for UI and US VRs.

I have just committed a patch in the mainline to solve this issue:
https://code.google.com/p/orthanc/source/detail?r=ac6bd50a8c83b442ddfbc0f2a08abb
32d749d77f

With this patch, the AT VRs become usable in JavaScript.

Original comment by s.jodo...@gmail.com on 8 Sep 2014 at 3:44

[GoogleCodeExporter]

Thanks for explaining this, I now see that I was incorrectly using the /content 
interface.  I did notice that it was incorrect in /tags too and just assumed it 
was the same issue but now I see that it is not.  Anyway, I was calling the 
/content interface because I found /tags too slow.  I have since switched to 
calling attachments/dicom-as-json/data as that is the fastest way to get what I 
need.  Thanks for clarification and quick response!

Original comment by cha...@gmail.com on 8 Sep 2014 at 3:53

[GoogleCodeExporter]

Actually I see that attachments/dicom-as-json/data does not return 
FrameIncrementPointer properly either - will this be fixed by your patch?

Original comment by cha...@gmail.com on 8 Sep 2014 at 3:54

[GoogleCodeExporter]

#6 - I have just committed a patch so that "/attachments/dicom-as-json/data" 
and "/tags" will have the same speed (by bypassing the unnecessary JSON 
evaluation):
https://code.google.com/p/orthanc/source/detail?r=200fcac0deb4e2b6476b9de03c18df
b287fe65da

#7 - All the patches will be part of Orthanc 0.8.3, to be released in the next 
few hours. You will have to rebuild your Orthanc database (by reimporting all 
the DICOM files into a new instance of Orthanc), for "FrameIncrementPointer" to 
be properly set.

Original comment by s.jodo...@gmail.com on 11 Sep 2014 at 12:20

• Changed state: Fixed