jrkerns / radpy Goto Github PK

What steps will reproduce the problem?
1. Open a 3D Dicom-RT dose file.
2. Plot it in a plot window.
3. Resize RadPy's main window.

What is the expected output? What do you see instead?

The viewing planes sliders should still work after resizing.  Instead they do 
not move and give the following traceback.

Traceback (most recent call last):
  File "enthought\enable\qt4\base_window.pyc", line 182, in mouseMoveEvent

  File "enthought\enable\qt4\base_window.pyc", line 120, in mouseMoveEvent

  File "enthought\enable\abstract_window.pyc", line 269, in _handle_mouse_event

  File "enthought\enable\base_tool.pyc", line 114, in dispatch

  File "enthought\enable\tools\drag_tool.pyc", line 109, in _dispatch_stateful_event

  File "enthought\enable\tools\drag_tool.pyc", line 155, in _drag_mouse_move

  File "radpy\plugins\BeamAnalysis\view\Plot3D.pyc", line 186, in dragging

  File "radpy\plugins\BeamAnalysis\view\Plot3D.pyc", line 203, in index_changed

  File "radpy\plugins\BeamAnalysis\view\Plot3D.pyc", line 367, in _index_callback

  File "radpy\plugins\BeamAnalysis\view\Plot3D.pyc", line 345, in _update_indices

  File "radpy\plugins\BeamAnalysis\view\Plot3D.pyc", line 217, in update_index

  File "enthought\chaco\base_2d_plot.pyc", line 119, in map_screen

  File "enthought\chaco\grid_mapper.pyc", line 111, in map_screen

  File "enthought\chaco\linear_mapper.pyc", line 54, in map_screen

TypeError: unsupported operand type(s) for *: 'numpy.ndarray' and 
'numpy.float64'

What steps will reproduce the problem?
1. Add a profile (inplane or crossplane) to a plot window.
2. Add a depth dose curve to that same plot window


What is the expected output? What do you see instead?

It doesn't make sense for a depth dose and profile to be overlayed.  There
needs to be some mechanism to keep this from happening.  Either a new plot
window needs to be opened, or an existing plot window that has the same
type of scan needs to be used.  I would suggest opening a new plot window,
otherwise it will be complicated if multiple plot windows are already open.

Some quantities are given in centimeters and some in millimeters.  RadPy needs 
to standardize on one set of units (probably mm).

When attempting to open certain files that have been edited in OmniPro-Accept, 
I get the following error and the file won't open.

---------------------------
File Read Error
---------------------------
Error reading H:/My Documents/Projects/2013-04 - Stereotactic SRS/Data 
collection/Measured srs data/Scans/Processed/G Diode Scans 100 SSD.rfb.  
timestamp out of range for platform localtime()/gmtime() function
---------------------------


This looks similar to something discussed at 
https://groups.google.com/forum/#!msg/pydata/RDU4zCMVeOg/9OA4zf3_7tEJ

I've attached four files: 2 pre-edit files (i.e. raw data from OmniPro), both 
of which load properly, and both files post-editing, one of which loads 
properly and one of which does not.

Sometimes, the tree view will disappear from RadPy and trying to open a new 
view with   does not work.  The only fix I can find for this is to delete the 
RadPy directory in AppData (under Windows).

I have attached a script that I have used in the past to convert WP700 (ASC 
files) into Varian Eclipse 
beam data format. I hope you find it useful and hopefully can integrate it into 
RadPy. There are 
comments in the file that represent the possible variable choices that Eclipse 
wants for each type of 
file (i.e. PDD, OPD, WDD). These are documented in the beam data guide (maybe 
golden data as 
well).

I haven't used this in over a year, but it worked with Eclipse 8.5 at the time.

Adit

What steps will reproduce the problem?
1. Start RadPy on Windows.
2. Go to the View/Other... or Tools/Preferences menu option.


What is the expected output? What do you see instead?

A dialog window should appear but instead the expected output is rendered
as part of the main window.

There needs to be a cursor to examine the data on the scan plots.

1. Update Enthought Tool Suite to v4.1.0
2. Plot a scan in a plot window

A text label describing the scan should appear in the legend.  Instead, the 
legend is blank.

This is a result of a change to the legend module in Chaco (see <a 
href=https://github.com/enthought/chaco/commit/2aa2335d16883ef8a18f41c0ef0382ef1
c84bade>commit</a> in Enthought git repository).  The change will only allow 
legend labels to appear if they match the name of a plot in the plot window.  
RadPy sets the labels in the legend so that only unique values (machine, 
energy) in the name of each plot are shown. Apparently fiddling around in 
non-exposed module details is fragile.  Who knew?

Now that it is possible to scan a reference data set for matching scans to 
plotted data, there needs to be a way to select a "target" data set and compare 
all scans within that set to matching reference set scans.  There could then be 
some sort of report that gives a quantitative closeness of fit measure.

How to convert rfb profiles to numpy array?

1. Open a file with two scans with the same metadata (field size, energy, scan 
type, depth etc.)  This could be a file with a scan that has been smoothed, for 
example.  It will have the original scan and the smoothed version
2. Both scans will show up in the tree view, but cannot be added to the same 
plot since RadPy thinks they are the same scan.

There needs to be a way to distinguish between scans that have the same 
metadata, but are distinct scans.

There needs to be some sort of progress bar during file loading.

We need to have some sort of unit testing capability for RadPy.  Writing
unit tests for individual modules is easy enough, but we need some way of
automating unit testing of all data analysis modules for every RadPy
plugin.  This will obviously have implications for any automated plugin
system.  SciPy has a global unit testing system.  Some variation on that
might be the best course.

1. Modify any scan (smooth, renormalize, etc.)
2. The modification will not show up in the Modification History of the BDML 
file.

Right now, workbench plugins must be hard coded into run.py.  Ultimately,
there needs to be a system to allow end users with binary copies of the
program to manage plugins.  The workbench has support for Python eggs, so
that may be the way to go.