Reg23 example

[Yves]

Hi,

I am interested in using reg23 and I was wondering if there is a
complete example with sample images and corresponding configuration
file to get me started?

Thanks,
Yves

[Philipp Steininger]

Yves,

my colleague recently prepared a demo-pack for another interested researcher. Below you find the attached demo as well as a description from Markus:

I set up a minimal working sample config (Demo.zip) and provide some basic introductionary infomration to our geometric setup.
Please extract it to 'C:\UNO23REG-Demo\Demo'
and run 'C:\PATHTOREG\reg23.exe -c C:\UNO23REG-Demo\Demo\

uno23reg-config.ini' with the compiled reg23.exe based on the plastimatch source code.

### About the frameworks current geometry definition approach: ###

The world coordinate system is defined as shown in world_coordinate_system_definition.png. We often call it "IEC-coordinate-system" or "world-coordinate-system (WCS)" in the code/docs.

Both X-rays AND the CT-volume are defined absolutely in this WCS.

Projection geometry: (see geometry_def1.png)

Is defined by the source position (source of projection, focal spot) S and the image position (R) and orientation (v1, v2). S is configured explicitly in the config.ini for each view ([Geometry]\SourcePosition{X}). The image orientation, however, is defined implicitly; the size/spacing/orientation/position(origin) can be directly read from the MHD-image - we do exactly this and, therefore, rely on the information we find in the MHD headers. R (reference point) is a specified point of the X-ray where your pixel buffer starts. The pixels grid is assumed to be rectangular, and its orientation is defined by v1 (row vector) and v2 (column vector).

e.g. for APPostShift we find the following MHD header to be useful (pixel spacing 0.4 assumed):

ObjectType = Image
NDims = 3
BinaryData = True
BinaryDataByteOrderMSB = False
CompressedData = False
TransformMatrix = 1 0 0 0 1 0 0 0 1   ### v1_x v1_y v1_z v2_x v2_y v2_z v1_cross_v2_x v1_cross_v2_y v1_cross_v2_z (provided v1, v2 are normalized vectors)
Offset = -204.6 -204.6 -600
CenterOfRotation = 0 0 0
AnatomicalOrientation = RAI
ElementSpacing = 0.4 0.4 1
DimSize = 1024 768 1
ElementType = MET_SHORT
ElementDataFile = APPostShift.raw

the according source position is:

SourcePosition1=0.0,0.0,1000.0


The absolute definition in WCS gives us the freedom to support any projection geometry completely independent of the imaging device (not necessarily a rotational system) - we do not need to know the SID/SAD/gantry angles for the registration. The system which converts the source images (e.g. ELEKTA HIS files) into MHD files or our native ORA.XML and generates the config.inis needs to have this information (in this case I was this system).


VOLUME:

What you need to do moreover is to re-orient/re-position the volume correctly - you have to map it from DICOM patient-based CS into WCS. You can do it manually by defining the according direction cosines:

ObjectType = Image
NDims = 3
BinaryData = True
BinaryDataByteOrderMSB = False
CompressedData = False
TransformMatrix = 1 0 0 0 0 -1 0 1 0  ### direction cosines that describe the DICOM CS to WCS conversion
Offset = -170.163 -170.163 98.15  ### I centered the volume around WCS origin
CenterOfRotation = 0 0 0
AnatomicalOrientation = RAI
ElementSpacing = 0.666 0.666 1.3
DimSize = 512 512 152
ElementType = MET_SHORT
ElementDataFile = testCT.raw

Regarding the volume, you can moreover define the very radiotherapy-specific "isocenter" translation ([Geometry]\IsoCenter) that internally shifts the volume accordingly ...



Regards,
Markus

[Yves]

Hi Philippe,

Thanks a lot for your quick reply and very detailed example.

When I ran it first, I got the following error:

The hardware (graphics card, GPU) appears to be invalid for REG23. The
application cannot resume!
Possible reasons:
GLSL fragment_shader extension is obviously not supported (or OpenGL
2.0)!

and I remembered a statement about support of DRR-Engine only n-vidia
cards in the README.TXT
I am currently using Ubuntu 10.04 on a macbook1,1, so I have an intel
graphics card and opengl 1.4 only.
However, I can turn on software rendering (using mesa 7.7.1) which
should provide opengl 2.1 (although not hardware accelerated) by
running:

$ LIBGL_ALWAYS_SOFTWARE=1 reg23 -c uno23reg-config.ini

reg23 runs and says it is registering, but I don't see any DRR
generated and the transformation does not change either.

Does OpenGL2.1 provide the fragment_shader? I assume yes, since reg23
runs. Maybe it is not implemented properly in mesa 7.7.1, could that
be the problem? Is there a CPU-DRR in oraifutils I could enable?

I'll try to get my hands on a PC with n-vidia card.

Thanks for your help,
Yves



On May 3, 10:40 am, Philipp Steininger <phil.steinin...@gmail.com>
wrote:

>  Demo.zip
> 3701KViewDownload
>
>  geometry_def1.png
> 130KViewDownload
>
>  world_coordinate_system_definition.png
> 89KViewDownload

[Philipp Steininger]

Hi Yves,

I have never tried reg23 in an environment like yours. One fact is that some environments may solely implement stubs instead of really implementing the required openGL functions. This may or may not be the case with your mesa package. In principle, you should be fine with openGL 2.1.

At the moment, unfortunately, solely the GLSL uniform ray-casting renderer is available. There is already a CPU-based DRR filter (Siddon sampling) in oraifutils. moreover, an openCL siddon filter is available (not sure whether already in oraifutils or not). However, the problem is that we decided to implement a new generic "DRR API" for geometrically defining the projection geometry. The Siddon filters are already conformant with this new guideline, however, the rest of the registration core is not. There is already a student working on this topic. Are you interested in supporting us in these affairs? If yes, I would provide you with more details on the topic and what we have to do together to make reg23 more generic and get rid of the nvidia dependency.

cheers,
phil

[Yves]

Hi Phil,

I got reg23 compiled and the example working on a PC with n-vidia and
OpenGL 2.1. I'll try to fiddle with the geometry settings to
understand the definitions of coordinate systems.

You are probably right, it looks like the mesa setup I have does
provide some sort of stubs without a complete implementation.

Sure, I'd be interested in having a CPU DRR engine available in reg23.
Let me know how I can help.

Yves



On May 4, 1:42 am, Philipp Steininger <phil.steinin...@gmail.com>
wrote:

[Taylor Braun-Jones]

Just wanted to say thanks, this information was helpful for me to understand the REG23 geometry. 

Also, any chance you could share the source files that produced geometry_def1.png and world_coordinate_system_definition.png? What application was used?

Thanks,

Taylor

[Philipp Steininger]

Hi,

the software "linac sim by phil" used for the screenshots is a simple (and dramatically dirty!) VTK-based application I wrote over a weekend before a conference talk to generate a few movies that visualize the typical 2D/3D workflow in conventional radiotherapy. At the moment I can't find the sourcecode in our repository, however, somewhere it must hide ...

phil

--
You received this message because you are subscribed to the Google Groups "Plastimatch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plastimatch...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mengjiao Wang]

Hi, Phil,

I am trying to use REG-2-3 to do the registration. Thanks to your example, I can roughly understand the geometry and how the reg-2-3 works. But when I tried to register my own data, which is a 3D cone beam volume and two projections at 90 and 180 gantry angle respectively, the software went wrong. Firstly, the DRR of 3D volume is not visible. And the projections are displayed upside down.

I visualized the geometric relationship between 3D volume and 2D projections in slicer, and compared it with your example. The geometry looks fine.

Could you help me out with this problem? Thanks.

The data, screen shot of reg-2-3 display and slicer are in the attached files. 

MJ    

[Taylor Braun-Jones]

Hi Phil,

I poked around in the SVN repository, but didn't find anything. No big deal - I'll probably just end up re-implementing something similar to what you did. Thanks anyway!

Taylor

--
You received this message because you are subscribed to a topic in the Google Groups "Plastimatch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/plastimatch/8qAMscOoV90/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to plastimatch...@googlegroups.com.

[Philipp Steininger]

MJ,

attached you find the modified files (mhds and ini). Along with this zip you find a doc describing how I usually derive the reg23 geometry (this document, however, refers to another, more challenging example of imager setup).
I tried to track your geometry and did my best to configure it correctly in reg23 environment.
However, to determine whether it is correct or not, I miss essential information on the experiment: are the two images at 90 and 180 deg LINAC-gantry-angle (! - not imager gantry angle) raw projections from the reconstructed CBCT (volume.mhd)? in the current configuration you have to shift the volume (CBCT) approximately -10 cm in IEC x direction to get the approximate setup error.

Cheers,
phil

[Mengjiao Wang]

Hi, Phil,

Thank you so much for your reply. The gantry angles are for the LINAC. And those two images are the raw projections (NOT DRRs).  In this experiment, the panel is off centered, about 110mm. I modified the offset in each projection's MHD file to account for it. 

Best,

MJ

You received this message because you are subscribed to a topic in the Google Groups "Plastimatch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/plastimatch/8qAMscOoV90/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to plastimatch...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

<modified.zip>

<marta_geometry_extended_explanation.doc>

[WANG Mengjiao]

Hi, Phil
I am using reg23 to register a 3D CBCT volume and 2 projection
images. But I encountered with a error, whose information is like this "
after try to load the texture ERROR". It happened after initialize the
framework and before the auto-registration. Could you give me some
information about what does this error mean and how to solve this problem?
Thanks!
Mengjiao