TImage from numpy array

Hello,

I am new to python and I am using a script that accesses DICOM images and reads the pixel matrix into a numpy array. Now, I am trying to turn this array into a TImage and I have a few questions. Sorry, it turned a bit into a lengthy post, but thanks for your input!

  1. What would be the quickest way to do the transfer? After a lot of trial and error I succeeded with the intermediate step of reading the pixels into a TH2D (see below), but is there no simpler way to create an image from an array? Failed on TArray attempts…
# read_dicomImages.py
# that's the code that works, can we do it without the TH2D?
import dicom
import numpy
from ROOT import *

# get DICOM image and pixel array
dcm = dicom.read_file("image.dcm")
pix_arr  = dcm.pixel_array
col = dcm.Columns
row = dcm.Rows

# turn pixel array into TH2D
his = TH2D("his", "Pixel matrix", col, 0, col, row, 0, row)
for y in range(0,512):
   for x in range (0,512):
     his.SetBinContent(x, y, pix_arr[y,x])

# create TImage from TH2D
img = TImage.Create()
img.SetImage(his.GetArray(), col+2, row+2, 0)
img.Draw()
  1. I am evaluating some of the pixel information for which I can use the the numpy array. However, I would like to draw onto the image the concerned area with something like

img.DrawCircle(250, 250, 50, "#000000", 5) here’s what I get:

[code] *** Break *** segmentation violation

Thread 2 (Thread 0x7f4502d91710 (LWP 15263)):
#0 0x00007f450f88b600 in sem_wait () from /lib64/libpthread.so.0
#1 0x00007f450fb91521 in PyThread_acquire_lock () from /usr/lib64/libpython2.6.so.1.0
#2 0x00007f450fb6f919 in PyEval_RestoreThread () from /usr/lib64/libpython2.6.so.1.0
#3 0x00007f450e3b8110 in ?? () from /usr/lib64/python2.6/lib-dynload/time.so
#4 0x00007f450fb7165c in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#5 0x00007f450fb76251 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#6 0x00007f450fb43fa2 in ?? () from /usr/lib64/libpython2.6.so.1.0
#7 0x00007f450fb37cb2 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#8 0x00007f450fb721f3 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#9 0x00007f450fb7380b in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#10 0x00007f450fb7380b in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#11 0x00007f450fb76251 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#12 0x00007f450fb43db2 in ?? () from /usr/lib64/libpython2.6.so.1.0
#13 0x00007f450fb37cb2 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#14 0x00007f450fb3a03f in ?? () from /usr/lib64/libpython2.6.so.1.0
#15 0x00007f450fb37cb2 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#16 0x00007f450fb6fd26 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0
#17 0x00007f450fb28238 in ?? () from /usr/lib64/libpython2.6.so.1.0
#18 0x00007f450f884a4f in start_thread () from /lib64/libpthread.so.0
#19 0x00007f450ef9082d in clone () from /lib64/libc.so.6
#20 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f4510047700 (LWP 15254)):
#0 0x00007f450ef5fbfd in waitpid () from /lib64/libc.so.6
#1 0x00007f450eefd3b1 in do_system () from /lib64/libc.so.6
#2 0x00007f450eefd7f0 in system () from /lib64/libc.so.6
#3 0x00007f4509d1cc57 in TUnixSystem::StackTrace() () from /usr/local/root_5.28/lib/root/libCore.so.5.28
#4 0x0000000000000008 in ?? ()
#5 0x00007f450f21beb8 in main_arena () from /lib64/libc.so.6
#6 0x00000000000000a0 in ?? ()
#7 0x00007ffffa481840 in ?? ()
#8 0x000000000508d993 in ?? ()
#9 0x00007f4509a85120 in ?? () from /usr/local/root_5.28/lib/root/libCint.so.5.28
#10 0x00007f450f21be80 in ?? () from /lib64/libc.so.6
#11 0x0000000000000070 in ?? ()
#12 0x00007ffffa481890 in ?? ()
#13 0x00007ffffa4817f0 in ?? ()
#14 0x00000a14ffffffff in ?? ()
#15 0x00007f450ef37aa9 in malloc () from /lib64/libc.so.6
#16 0x00007f4509a850d8 in G__break_exit_func () from /usr/local/root_5.28/lib/root/libCint.so.5.28
#17 0x00000000026e5680 in ?? ()
#18 0x00007ffffa47fd00 in ?? ()
#19 0x01007f4509ac0400 in ?? ()
#20 0x00007f450a06b6f9 in ?? () from /usr/local/root_5.28/lib/root/libCore.so.5.28
#21 0x0000000000f6d440 in ?? ()
#22 0x0000000000000000 in ?? ()
Traceback (most recent call last):
File “”, line 1, in
File “import_CT_Data.py”, line 24, in run
printPixelInfo(path.join(rootpath, filename))
File “import_CT_Data.py”, line 113, in printPixelInfo
img.DrawCircle(250, 250, 50, “#000000”, 5)
SystemError: problem in C++; program state has been reset

[/code]
Any input on that? Similar things come up when I try other interesting stuff like

img.Gray(kTRUE)

whereas

print img.IsGray() works fine and prints “False” on the output screen.

  1. Anybody heard of a way to work with DICOM files in ROOT on the C++ end? I would be glad to skip the whole python adventure for now…

  2. Alternatively, how could I transfer the numpy pixel array to a
    double pixarray[col][row]
    on the C++ side, i.e. what’s next after

TPython::Exec("import read_dicomImages");

Hi,

no access to dicom, so I’m just venturing a guess. Usually when conversion from a numpy array fails, that means that it is not a flat array. See e.g. [url]TGraphErrors taking numpy arrays as arguments

Cheers,
Wim