OnUpdatePositionValues cant display very low dose

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load a dose image with max values less than 1e-4 Gy
2. Select 2dview panel
3. Attempt to read dose values from bottom right of panel, only 0.00 Gy will 
display.

What is the expected output? What do you see instead?
The expected output is 0.00 Gy and that is what is shown for the entire dose 
graph.

What version of the product are you using? On what operating system?
0.4a2.
Windows 7 64bit.

Please provide any additional information below.
To demonstrate,I have made a childish change to the code to use exponential 
format when displaying dose values less than 1e-4. By adding 3 lines and 
changing 1 I was able to update OnUpdatePositionValues(), in 2dview.py, lines 
529-532. I have attached a before and after of the function to demonstrate.

Original issue reported on code.google.com by lstrd...@gmail.com on 27 Aug 2011 at 3:09

Attachments:

• 2dviewOUPVBefore.py
• 2dviewOUPVAfter.py
• ex.jpg

[GoogleCodeExporter]

I tried your changes and they look fine from the perspective of clinical data. 
I can commit your changes to the repository.

Do you think the Rx dose and the isodose list should be modified as well to 
match the same style of float formatting? These can be found in main.py in the 
methods PopulatePlan() and PopulateIsodoses(), respectively. 

If so, here is patch for the latest source that should fix those two methods as 
well. If that works for your data, I will commit it. I tested it with the 
example data with a fake Rx dose of 0.0000012345 as seen in the attached 
screenshot.

Original comment by bastula on 27 Aug 2011 at 4:39

• Changed state: Accepted

Attachments:

• lowdose.diff
• lowdose.png

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I was able to work that into the windows version and it looks great(attached).

A silly idea perhaps but maybe there could be a general settings option to 
display a preferred accuracy for floats toward the end of the MainFrame().

Original comment by lstrd...@gmail.com on 27 Aug 2011 at 5:54

Attachments:

• ex2.jpg

[GoogleCodeExporter]

Just out of curiosity, why are you trying to display dose so low? Normally when 
you run a low statistics MC simulation, you'll scale the result to clinical 
values first (i.e. no one shoots a beam on purpose that delivers 10^-17 cGy).

Very excited to see the Geant4 DICOM plugin you're working on.

Original comment by roy.coding@gmail.com on 27 Aug 2011 at 6:09

[GoogleCodeExporter]

The reason for the low dosages are due to the simulation only passing ~1e5 
electrons through the patient. This of course is not a physical simulation and 
was done just to get a quick dose graph. Many of our simulations will yield 
values less that 1e-4 Gy but in my examples here the dose values are quite 
meaningless due to the beam setup.

Original comment by lstrd...@gmail.com on 27 Aug 2011 at 7:06

[GoogleCodeExporter]

Looking at http://docs.python.org/library/stdtypes.html#string-formatting , 
there is a formatting string "g" that can be used to solve both problems at 
once without any conditionals.

I tried using "%.6g" instead of "%.2f" which displays decimal format for any 
precision value less than 6, otherwise the display will be in exponential 
format.

i.e. 1400 displays as 1400,
      123456 -> 123456,
      1234567 -> 1.23457e+06,
      0.0001234567 -> 0.000123457
      0.00001234567 -> 1.23457e-05

Barring any outstanding issues, I think this would be the way to go, since it 
allows display of values regardless of size which solves the problem for 
clinical doses, low doses and extremely high doses.

Can you please test with your data and let me know?

Original comment by bastula on 3 Sep 2011 at 1:44

[GoogleCodeExporter]

I applied the "%.6g" format to the rxdose, isodose panel, and mouse tracking on 
my end. Images attached showing a simulator and clinical.

Appears to be a good solution for a general formatting.

Original comment by lstrd...@gmail.com on 3 Sep 2011 at 3:06

Attachments:

• 6gformat.png
• 6gformat1.png

[GoogleCodeExporter]

This issue was closed by revision d312b938b38f.

Original comment by bastula on 6 Sep 2011 at 2:32

• Changed state: Fixed