# Pixel Data presence

**URL:** https://discourse.orthanc-server.org/t/pixel-data-presence/689
**Category:** Google Groups archive
**Created:** [May 24, 2017, 2:49pm UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689 "2017-05-24T14:49:41Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![Adit\_Panchal](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/a/3be4f8/32.png) [@Adit\_Panchal](https://discourse.orthanc-server.org/u/Adit_Panchal)
#### Post date: [May 24, 2017, 2:49pm UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689/1 "2017-05-24T14:49:41Z")

</div>

Hello everyone,

I am porting some of my code to use Orthanc as a backend. One thing that is easy to do with pydicom is to detect the presence of pixel data (i.e. [7fe0, 0010].

The best way I found to replicate that is to access the path ‘/instances/{id}/content/7fe0-0010’

However, that is a separate http request for one tag. Is there any way to to add the presence or absence of pixel data inside of MainDicomTags or in the /instance/{id} endpoint?

Is this something that considered to be added to mainline?

Thanks,

Adit

---

<div class="post-metadata">

### Author: ![Thibault\_Piront1](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/t/edb3f5/32.png) [@Thibault\_Piront1](https://discourse.orthanc-server.org/u/Thibault_Piront1)
#### Post date: [May 29, 2017, 12:46pm UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689/2 "2017-05-29T12:46:53Z")

</div>

Hello,

I don’t think it’s on the roadmap. Could you give more detail about the context where you need this?

Just an idea: perhaps you may use transfer syntaxes to detect presence of pixel data (they can be accessed through metadata w/ orthanc 1.2.0) ?

[http://book.orthanc-server.com/faq/features.html](http://book.orthanc-server.com/faq/features.html)

For the record, you the `/instances/{id}/frames/{frameNumber}/raw` route allow to pick up pixel data by frames (in case of multi frame instance).

Kind Regards,  
Thibault.

---

<div class="post-metadata">

### Author: ![Adit\_Panchal](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/a/3be4f8/32.png) [@Adit\_Panchal](https://discourse.orthanc-server.org/u/Adit_Panchal)
#### Post date: [May 30, 2017, 2:14pm UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689/3 "2017-05-30T14:14:11Z")

</div>

Hi Thibault,

Basically, some DICOM files are unreliable if they have pixel data or not, solely based on their modality tag or their transfer syntax.

Also in DICOM RT we have modalities such as RT Dose which may or may not have pixel data. It could contain a DVH sequence, a dose matrix, or both.

I suppose I am just looking to make one less request, especially since pixel data size could be quite substantial.

The workaround I proposed seems to work fine for now.

Question: How does the Osimis or Orthanc web viewer know whether it should display images from a series? Does it look for the presence of pixel data? The Orthanc viewer works for RT Dose but fails on a RT Structure Set (as it does not have any pixel data). The Osimis viewer actually shows neither, but I am not sure if it looks for certain modalities to display.

Thanks,

Adit

---

<div class="post-metadata">

### Author: ![Thibault\_Piront1](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/t/edb3f5/32.png) [@Thibault\_Piront1](https://discourse.orthanc-server.org/u/Thibault_Piront1)
#### Post date: [May 30, 2017, 2:48pm UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689/4 "2017-05-30T14:48:03Z")

</div>

Hi Aditya!

It’s currently quite simple in the case of the Osimis Viewer:

1. we first take the middle instance of a series.
2. we ignore Dicom SR & PR based on modality (small list for now, but optional step - we’ll complete it later).
3. we process tags to retrieve information about the image (such as the Rows & Columns).
4. if an exception is thrown (eg. because a tag is inexistant), we ignore the whole series.

We only process one instance among the series to reduce performance cost. Mostly because prior to Orthanc 1.2.0, we had to parse the DICOM file without orthanc to retrieve the transfer syntax (which is quite slow, and not cached/preprocessed in our case).

The RT dose not showing up is in fact a frontend bug that has already been resolved and will be released quite soon.

Kind Regards,  
Thibault.

---

<div class="post-metadata">

### Author: ![Vo\_B\_o\_Trung](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/v/df788c/32.png) [@Vo\_B\_o\_Trung](https://discourse.orthanc-server.org/u/Vo_B_o_Trung)
#### Post date: [May 31, 2017, 12:12am UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689/5 "2017-05-31T00:12:29Z")

</div>

> **From:** Thibault Piront  
> **Sent:** Tuesday, 30 May 2017 21:48  
> **To:** Aditya Panchal  
> **Cc:** Orthanc Users  
> **Subject:** Re: Pixel Data presence  
>   
> |
> 
> - |

Hi Aditya!

It’s currently quite simple in the case of the Osimis Viewer:

1. we first take the middle instance of a series.
2. we ignore Dicom SR & PR based on modality (small list for now, but optional step - we’ll complete it later).
3. we process tags to retrieve information about the image (such as the Rows & Columns).
4. if an exception is thrown (eg. because a tag is inexistant), we ignore the whole series.

We only process one instance among the series to reduce performance cost. Mostly because prior to Orthanc 1.2.0, we had to parse the DICOM file without orthanc to retrieve the transfer syntax (which is quite slow, and not cached/preprocessed in our case).

The RT dose not showing up is in fact a frontend bug that has already been resolved and will be released quite soon.

Kind Regards,  
Thibault.

---

<div class="post-metadata">

### Author: ![Vo\_B\_o\_Trung](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/v/df788c/32.png) [@Vo\_B\_o\_Trung](https://discourse.orthanc-server.org/u/Vo_B_o_Trung)
#### Post date: [May 31, 2017, 12:12am UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689/6 "2017-05-31T00:12:51Z")

</div>



---

<div class="post-metadata">

### Author: ![jodogne](https://discourse.orthanc-server.org/user_avatar/discourse.orthanc-server.org/jodogne/32/1511_2.png) [@jodogne](https://discourse.orthanc-server.org/u/jodogne)
#### Post date: [June 14, 2017, 3:06pm UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689/7 "2017-06-14T15:06:59Z")

</div>

Hello,

As an alternative to accessing “/instances/{id}/content/7fe0-0010”, you could access “/instances/{id}/tags”.

This URI will return a JSON file containing all the DICOM tags in a single request: You can look for the presence of the “7fe0,0010” value in the JSON dictionary to determine whether the pixel data is present.

HTH,  
Sébastien-

---

<div class="post-metadata">

### Author: ![jodogne](https://discourse.orthanc-server.org/user_avatar/discourse.orthanc-server.org/jodogne/32/1511_2.png) [@jodogne](https://discourse.orthanc-server.org/u/jodogne)
#### Post date: [June 14, 2017, 3:26pm UTC](https://discourse.orthanc-server.org/t/pixel-data-presence/689/8 "2017-06-14T15:26:57Z")

</div>

> Question: How does the Osimis or Orthanc web viewer know whether it should display images from a series? Does it look for the presence of pixel data? The Orthanc viewer works for RT Dose but fails on a RT Structure Set (as it does not have any pixel data).

As far as the Orthanc Web viewer is concerned, it uses the “/series/{id}/ordered-slices” URI to decide whether the frames are arranged either as a 3D volume (using the ImagePositionPatient tag) or as a time sequence (using the InstanceNumber tag).

I kindly refer you to the implementation of the “SliceOrdering” class in Orthanc that implements this “ordered-slices” URI if you want additional technical information:  
[https://bitbucket.org/sjodogne/orthanc/src/default/OrthancServer/SliceOrdering.cpp](https://bitbucket.org/sjodogne/orthanc/src/default/OrthancServer/SliceOrdering.cpp)

Regarding the RT-STRUCT support, it will be part of the ongoing Stone of Orthanc project:  
[http://www.orthanc-server.com/static.php?page=stone](http://www.orthanc-server.com/static.php?page=stone)

Regards,  
Sébastien-
