1. OpenREM
  2. OpenREM
  3. OpenREM
  4. Issues

Issues

Issue #61 open

Visualise fluoroscopic dose distribution

Ed McDonagh
created an issue

Probably on a rotatable cylindrical model

Comments (300)

  1. David Platten

    Updated code to check that certain fields have a value before trying to calculate the dose from a view. Do I need to check all of these? Should they be set to None or 0 if a value isn't found? The python and JavaScript code is hard-written for a 70 x 90 skin dose map at the moment: needs to be made more general. References issue #61

    → <<cset 5a9aebba89a3>>

  2. Ed McDonagh reporter

    Nice!

    Would min/max be more intuitive than level/width? I think my main two views would be 0 to max and 0 to xGy where x would be the same for a range of scans that I wanted to compare. Maybe a preference I could set somewhere. I think both of these would be trickier to manually set with level/width as I'd have to do some mental arithmetic!

  3. Ed McDonagh reporter

    That's pretty. But I still think min/max slider bars make more sense. Particularly as I now understand the min/max dose below the diagram represents the min/mas in the image, not the min/max of the scale, and because the scale can go negative.

  4. David Platten

    Done:

    • Calculate the skin dose map during import of each study, as an admin option
    • Make calculation of skin dose map happen via AJAX
      • Would be better to show the pending graphic in the skin map div
    • Decide on what controls the user should have (window/level or max/min)
      • User can interactively switch between one or the other
    • Store the calculated data somewhere so that it can be retrieved almost instantly if the map is viewed again
      • Create a folder called skin_maps inside MEDIA_ROOT?
      • Use the pk as the basis of a filename (skin_map_pkValue.p)
      • Use pickle to store variable data in a file
    • Enable a choice of colour scales
    • Remove use of skinDose JavaScript variable
    • Display the dose at the mouse cursor in a tooltip by the mouse pointer
    • Encapsulate the skin dose map JavaScript code into an object. This will remove the need for the messy global variables
    • Enable viewing of a 3D representation of the skin dose map using three.js
    • 3d skin map should be put into an object to tidy it up
    • 3d skin map calculations currently hard-written to specific phantom dimensions: need to be made generic
      • New object code can accept custom dimensions
    • 3d skin map now showing data in the correct place around the phantom - adjusting array by half of flat front width
    • Enable saving of the displayed skin dose map as a graphic
    • Label the skin dose map to show which part is front, back, left and right of patient
      • 3d skin dose map now has a mini-person to orientate the user
      • 2d skin dose map now labelled with an overlay
    • Decide on what numerical values should be displayed (dose at cursor; max dose of whole map etc)
    • Display phantom details (height, width, depth)
    • Display patient values used (height and weight)
    • Add a full-screen button similar to the one for the charts
  5. Ed McDonagh reporter

    It would be good if the storing of calculated data and the check to see if is there before recalculating it could be done in a standard way such that we could have jobs running on Celery to do them in the background if desired.

    I would suggest the data is stored in a folder in MEDIA_ROOT.

  6. David Platten

    Added max and min displayed dose values to the skin dose map. These are in addition to the existing window and level controls. Changing any of them updates the display of the skin dose map, and also updates the other sliders as appropriate. The live version will only display one set of sliders: either the max / min dose, or the window / level ones. References issue #61

    → <<cset d56c9d178724>>

  7. David Platten

    Updated JavaScript code to prevent min dose slider from having a larger value than the max dose slider. Also updated to prevent the max dose slider from having a value less than the min dose slider. References issue #61

    → <<cset 9c1223462121>>

  8. David Platten

    Not sure: the output is just what OpenSkin spits out from a standard sized 3D phantom. I'm not sure which part of the image equates to left, front, right and back.

  9. David Platten

    Included skin map width and height in json return. Changed hard-written dimensions in JavaScript code to use mag, skin map width and height instead. Will add control to change mag at some point. References issue #61

    → <<cset 5600949027eb>>

  10. Jonathan Cole

    The left and right bits are because the map is like slicing down the sternum and peeling the skin off flat.

    I have had a bit of a crack at the 3D stuff but haven't had time recently.

    David, is it possible to change the colour map to something else? I am not a fan of this one.

  11. David Platten

    Skin dose map data is now stored as a pickle in a skin_maps sub-folder of MEDIA_ROOT. Before the calculation of a skin map this folder is checked to see if there is a pickle file in the folder corresponding to the current study. If there is, the data in the pickle is loaded rather than recalculating the skin dose map. I've used cPickle rather than pickle, as apparently it is much faster (http://wiki.python.org/moin/UsingPickle). I've also added a line of JavaScript to resize the dose scale to the height of the displayed skin dose map. References issue #61

    It's likely that when I get around to the 3D visualisation of the dose maps that I'll need to store a few more things in the pickle, such as the 3D phantom height, width and depth.

    → <<cset 8b9f2a5cf430>>

  12. David Platten

    Added the width of the flat part of the phantom and the distance around the curved edge to the 3D phantom properties. These will be useful when splitting the totalDose array into front, back, left and right parts for 3D display. References issue #61

    → <<cset 26bcabb6663b>>

  13. David Platten

    Skin dose maps now make use of new JavaScript objects: one for the skin dose map, and the other for the colour scale. These make the code cleaner, with newer global variables. Also updated the style of the colour scale selection div. References issue #61

    → <<cset 518a5c1d0444>>

  14. David Platten

    Not yet: Jon replied to me on the OpenSkin site yesterday with some comments about that, but I haven't read them properly yet. I think that the color scale clubs needs a cull too.

  15. David Platten

    Added stylised person to orientate the user when viewing the 3d skin dose map. I'd prefer that it was displayed in the bottom-left corner, rather than the top-left, but can't work out the css for that at the moment. References issue #61

    → <<cset 3c9670089f98>>

  16. Ed McDonagh reporter

    Toshiba do log this information on an exposure-by-exposure basis, as per TID 10003. This goes into the IrradEventXrayData model:

        patient_table_relationship_cid = models.ForeignKey(
            ContextID, blank=True, null=True, related_name='tid10003_pttablerel')  # CID 21
        patient_orientation_cid = models.ForeignKey(
            ContextID, blank=True, null=True, related_name='tid10003_ptorientation')  # CID 19
        patient_orientation_modifier_cid = models.ForeignKey(
            ContextID, blank=True, null=True, related_name='tid10003_ptorientationmod')  # CID 20
    

    On a sample of one of each, Toshiba seem to populate the orientation (erect, recumbant, semi-erect) and orientation_modifier (prone, supine etc), but not the table relationship (ie where the patient is relative to the head of the table). Siemens don't populate these fields.

  17. Ed McDonagh reporter

    I've been trying and failing to find a method of anonymising a decent fluoro RDSR, including times in all the sequences etc.

    So instead I've pulled the code locally to see what it looks like; unfortunately the patient size being present has made it fall over :-(

    Traceback (most recent call last):
      File "/home/mcdonaghe/research/veOpenREM/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 132, in get_response
        response = wrapped_callback(request, *callback_args, **callback_kwargs)
      File "/home/mcdonaghe/research/veOpenREM/local/lib/python2.7/site-packages/django/contrib/auth/decorators.py", line 22, in _wrapped_view
        return view_func(request, *args, **kwargs)
      File "/home/mcdonaghe/research/bbOpenREM/openrem/remapp/views.py", line 515, in rf_detail_view_skin_map
        matt_thick=4.0, matt_trans=0.75)
      File "/home/mcdonaghe/research/bbOpenREM/openrem/remapp/tools/openskin/calc_exp_map.py", line 37, in __init__
        self.phantom = geomclass.Phantom_3([0, -25, -self.matt_thick], mass=self.pat_mass, height=self.pat_height)
      File "/home/mcdonaghe/research/bbOpenREM/openrem/remapp/tools/openskin/geomclass.py", line 155, in __init__
        torso = refTorso * height / refHeight
    TypeError: unsupported operand type(s) for *: 'float' and 'Decimal'
    
  18. Ed McDonagh reporter

    I've now tried displaying some studies that don't have patient size included, and whilst the 2D version displays (on a simple study at least), I've not managed to get the 3D version.

    Is it likely to be a memory or processing issue? Might it be that I'm just using SQLite/runserver?

  19. David Platten

    Added styles to the range sliders; replaced hard-written dimensions with whatever the current skin dose map has; Update the size of the skinDoseMapGroup div according to the size of the current skin dose map. I've just noticed that the range sliders don't appear in Internet Explorer or Edge (whether they're styled or not) - need to find out why. References issue #61

    → <<cset b70b955d21e5>>

  20. David Platten

    Added overlay to the 2d skin dose map that will orientate the user. The display of this overlap can be toggled on and off by the user. The overlay contains a little text at the moment, but also needs to have some lines drawn on to illustrate the boundaries between anterior, left, posterior, right and anterior. References issue #61

    → <<cset cac8229dd113>>

  21. David Platten

    Latest updates on the DJP site. I'd like comments on what users (and developers - Ed McDonagh and Jonathan Cole) would like displayed on the overlay. I think I'm going to fix the colours used in the overlay, rather than have it follow the colour of the skin dose map colour scale. Thoughts on suitable colours would also be welcome.

  22. Ed McDonagh reporter

    It's looking really good! Only looked on my phone (away, with no laptop aaaarrrrrgggghhhh!). Labels were hard to see in grey, easier when the dose map was in colour and the labels stayed grey.

    Couple of things that don't help to answer your request - save to png doesn't show the overlay or the little man; and the new scale widgets don't show on Chrome on Android, but as discussed previously that is a niche use case!

  23. David Platten

    Removed need for a second (rotated) copy of the skin dose map array for the 3d object. This halves the storage requirement (the pickle files are half thier size if there's only one skin dose map array). I've also shifted the skin dose map by half the flat front width, so that it now displays from left to right as front, left, back, right. This enables the overlay to be simplified. Anyone testing this themselves will need to delete their existing pickle files from their MEDIA_ROOT folder as the new code creates a different data file. References issue #61.

    → <<cset dbfc2459b5ce>>

  24. Jonathan Cole

    Wow, it is looking really good.

    I'd like to be able to set maximum doses higher than the maximum in the image so it is possible to do a comparison between two patients. Is this a change that would be useful for other people or would it be better as a local change on my copy when I get a chance to reinstall?

  25. David Platten

    Overlay is now saved if it is being displayed when the user clicks on the save button. Hopefully Ed will like this. I'll take a look at including the orientation man on the 3d map at some point. It also references issue #61

    → <<cset 1615be391423>>

  26. David Platten

    3d skin dose map and orientation person now drawn on the same canvas. This means that the orientation man is included in the png when saved. It also means that there is only one 3d render, which is apparently a good thing. References issue #61

    → <<cset f21e4d7d31db>>

  27. David Platten

    Added new <div> to display peak skin dose, phantom dimensions and patient height and mass. Not in it's final position yet. Added more information to the saved pickle, so any existing pickle files will need to be deleted. References issue #61

    → <<cset 0ea40ed1c487>>

  28. David Platten

    Adjusted appearence of peak dose, phantom size and patient height and mass data. Now automatically adjusting the number of decimal places used to display skin dose values. Switched the skin dose values to the right of the colour scale to avoid lots of white space between the values and the colour scale when only a few decimal places are shown. References issue #61

    → <<cset fe61ac3a0d41>>

  29. David Platten

    I've done everything on my to-do list for this except for calculating the skin dose maps at the point that a new study arrives in OpenREM.

    Does anyone have any comments on how things currently look? Is there anything you'd like added or changed? The most recent commit is on the DJP demo site.

  30. Ed McDonagh reporter

    I'll try and have a look today. Does it need a comment along the lines of: Indication only: calculations not validated. Contributions welcome, see ... for details

    Also, is Jonathan Cole happy that the code is distributed within OpenREM rather than being submitted to PyPI as OpenSkin and then pulled in?

    Does the current view mention OpenSkin (I should really just look - sorry! I'm about to lose signal on the train!)

  31. Ed McDonagh reporter

    Thanks Jonathan Cole. I guess the question is more about how you want your codebase and David Platten's version to be maintained? Should they be the same codebase, which would favour pulling in OpenSkin version x from PyPI? Otherwise I guess they'll diverge (which would be a shame in my opinion).

  32. Ed McDonagh reporter

    David Platten I still can't get it to work with studies with patient size information. And I don't see any useful error messages either, either with the inspection tools or at the server logs.

    As proper anonymisation of these studies is so difficult, would you be able to add height and weight into some of your data to see if you can replicate the issue?

    Otherwise, with the restriction that I can't use the 3D version on my VM due to lack of working WebGL, its looking really good 😄

  33. David Platten

    OK Ed McDonagh. I've just added a patient_size and patient_weight to a study in the patientstudymoduleattr table. I used 155 for the size, and 66 for the weight. The resulting skin dose map worked perfectly...

    Should patient size be stored as cm or m in the database?

  34. David Platten

    I think I've answered my own question: the height is stored in m. This may be why it's not working for you, as OpenSkin expects height in cm... Sorting out the issue now (multiplying the stored height by 100).

  35. David Platten

    Patient height (patient_size) is stored in the database in m, so need to multiply this value by 100 before passing it on to OpenSkin, as this needs the height in cm. References issue #61 and hopefully fixes the issue that Ed was having with the skin dose maps displaying.

    → <<cset 9c0b60011b46>>

  36. David Platten

    Fixed problem where skin dose map group canvas wasn't resizing for different sized skin dose maps. Also added code to reset the rotation and zoom of the 3d skin dose map when the reset button is clicked. References issue #61

    → <<cset dc2832f9828a>>

  37. Ed McDonagh reporter

    Love to :-)

    from celery import shared_task
    
    @shared_task(name='remapp.tools.openskin.CalcExpMap')
    class CalcExpMap(object):  # or which ever function it is...
    

    Then at the end of the _rsdr2db function in rdsr.py

        CalcExpMap.delay(stuff)
        # After importing it of course, and switching it for whichever is the right function.
    
  38. Ed McDonagh reporter

    How would you feel David Platten about rolling this into develop for the next beta? I want to get it out soon, so that the people who are wanting to use mammo RDSR can do so, but it would be great to drop this in too!

  39. David Platten

    Hi Ed McDonagh. That is fine with me, but I do have some concerns:

    • It's not well-tested across systems (my Siemens Artis Zee data works well)
    • It fails with the test RDSR that john loveland send to me from a Toshiba system (there is no reference distance in the RDSR, and I don't know what the value should be)
      • Perhaps have a sensible default d_ref, rather than letting it fail?
  40. Ed McDonagh reporter

    Mmm. I'm getting myself confused. The two Tosh CCL RDSRs I have on the laptop, one is a DFP-8000D software v6.01, the other is also a DFP-8000D but software v6.10. Both of them have a Reference Point Definition of the usual 113860/15cm from Isocenter toward Source.

    The Philips RDSR I have, with no model name or software version, though I think it's an Allura, has an unusual RP Definition of '15cm below BeamIsocenter', in text rather than using the coded version. Don't know why, means the same thing.

    What is it that isn't being picked up for OpenSkin?

  41. David Platten

    Hi Ed McDonagh. I've just deleted the bi-plane study that John sent to me (and fixed the problem that gave). I then re-imported it into OpenREM and looked at it in the rfdetail view: no skin map. This is because the distance_source_to_isocentre field in the doserelateddistancemeasurement table are blank. The distance_source_to_reference_point data is also blank.

  42. Ed McDonagh reporter

    I don't have direct access to any, though I could probably look at a single plane system that's linked to one of my installs, with permission.

    I have one single plane and one bi-plane in my samples folder.

  43. Ed McDonagh reporter

    I've sent you one. But asking for others isn't a bad idea!

    Meanwhile, do you have a black background when you view the 3D view (any colour scheme)? It makes the text at the top regarding the doses impossible to read. This is from the djp demo, as I don't get the 3D on my laptop VM.

  44. Ed McDonagh reporter

    I've committed a small change to add Source to Detector Distance to the detail view - not strictly related to this branch, but I was wanting it when I was trying to work out what we know about distances, and thought it should stay. Hope that's ok!

  45. David Platten

    Introduced a skin_map_version to version.py. This is used to check that skin dose map pickle files are compatable with the current version of the skin dose mapping code. I've set the version to 0.7 to begin with. References issue #61

    → <<cset 628f4a1435f5>>

  46. Jonathan Cole

    Just a thought. I've never been able to test openSkin with anything but Siemens as no-one sent me any RDSRs.

    It is entirely possible that the reported geometry uses different reference points which could screw up skin dose calculations. Do we know these RDSRs actually work with openSkin?

  47. Ed McDonagh reporter

    Siemens and Toshiba use the same definition of RP. Philips uses a free text definition instead, which is legal, but means the same as the coded version Siemens and Toshiba use so it's annoying they didn't just use that!

    Sample sizes for the above statements by the way are 2 for Toshiba and 1 for Philips...

  48. Ed McDonagh reporter

    Toshiba uses the standard template for:

    • Positioner Primary Angle
    • Positioner Secondary Angle
    • Table Longitudinal Position
    • Table Lateral Position
    • Table Height Position
    • Table Head Tilt Angle
    • Table Cradle Tilt Angle
    • Patient Orientation
    • Patient Orientation Modifier

    For the angles the orientation and positive direction are defined, but not where 0 is as far as I can see. Similarly the table movement positive direction is defined but the 0 position is arbitary.

    I'll look at Philips later. They seem to have more information but quite a lot of it is using a Philips coding scheme :-(

  49. Ed McDonagh reporter

    Philips Allura

    • 113780 DCM Reference Point Definition Text 15cm below BeamIsocenter
    • 112011 DCM Positioner Primary Angle Numeric Value
    • 112012 DCM Positioner Secondary Angle Numeric Value
    • 113745 DCM Patient Table Relationship F-10470 SRT headfirst
    • 113743 DCM Patient Orientation F-10450 SRT recumbent
    • 113744 DCM Patient Orientation Modifier F-10340 SRT supine
    • 113751 DCM Table Longitudinal Position Numeric Value
    • 113752 DCM Table Lateral Position Numeric Value
    • 113754 DCM Table Head Tilt Angle Numeric Value
    • 113755 DCM Table Horizontal Rotation Angle Numeric Value
    • 113756 DCM Table Cradle Tilt Angle Numeric Value

    Additionally the following are described using 99PHI-IXR-XPER coding scheme rather than DCM or SRT:

    • wedges and shutters
    • beam position/angle
    • table height position
    • final versions of SDD, table cradle angle, table height position
    • detector field size in x and y
    • object thickness!
  50. David Platten

    I had a look at implementing a celery task to create a skin dose map on import of a new RF study a few minutes ago. However, I'm unclear about where to put the @shared_task, and quite what function this needs to be. Feeling dense. Ed McDonagh, can you offer any more pointers?

  51. Ed McDonagh reporter

    Trying to remember how to deal with this. Easiest way is probably to create a new function in remapp.tools.openskin somewhere that becomes the shared task, and takes just the id of the study. Then the call only includes the study id, which then looks up the study, gets the height and weight etc and calls CalcExpMap.

  52. Ed McDonagh reporter

    I think users aught to be able to choose whether OpenSkin maps should be available, and if so whether they should be made automatically (celery) or just on page view.

    Also, what happens if RDSR comes in, OpenSkin job goes into the RabbitMQ queue, then the user loads the detail view of that study before Celery has had a chance to process it. Does overwriting the pickle cause any issues?

    Also (!), I think it would be better/safer/easier to maintain if the function I more-or-less lifted from views into rdsr were just the one function used by both.

  53. David Platten

    Created new tools file that comtains the make_skin_map routine. This single routine is now the only one used to calculate skin dose maps. I've checked that it works when being used to calculate data that's already in the database, but am unable to check that it works for skin dose map calculations that are made when a new study is imported into the system from an RDSR. References issue #61.

    → <<cset 82420cbdf09e>>

  54. David Platten

    Hi Ed McDonagh (and Jonathan Cole), the skin dose maps are working well with the Siemens RDSRs that I have in my system. I'm glad that the skin dose maps can now be calculated at the point at which a new study comes into the system. However, neither the Toshiba bi-plane nor Philips Allura RDSR files that I have produce a working skin dose map. At the moment I don't know why: I've tried forcing a sensible default d_ref, but that doesn't work. As I don't have any vested interest in getting the Toshiba or Philips systems to work, I'm not going to spend any further time investigating. However, I am keen that version 0.7 of OpenREM is released in the not-too-distant future. So: what do you think is the best way forward with this?

    I'm happy to take a look at creating an option for skin dose maps to be available, and also whether they should be created on import, or just on study view.

  55. Ed McDonagh reporter

    I'm content that Philips and Toshiba are left for 0.7.1 or later, as long as a sensible message appears instead.

    I'll check the auto processing of RDSRs.

  56. David Platten

    Created global setting to enable or disable skin dose maps. Also added global setting to enable or disable calculation of skin dose map data on import. Not done yet: there's no way to change these settings yet (need to add a new admin menu item); the setting values aren't populated to start with (I had to manually add the values to the database table). References issue #61

    → <<cset ab439fd294bc>>

  57. Jonathan Cole

    The table top position is given by reference to an arbitrary point on the equipment. It would appear (as is typical) that all the companies use a different point.

    We would need to convert them all to the same co-ordinate system.

    The first thing I would need is to know what point the Toshiba and Philips are using. Does anyone have the DICOM info?

  58. Ed McDonagh reporter

    From the Philips Allura I just sent you:

    • height of system: 1065 mm
    • focal spot to isocenter: 810 mm
    • distance source to isocenter: 810 mm
    • distance source to detector: 1194 mm
    • table longitudinal position: 12 mm
    • table lateral position: 1818.6 mm
    • table height postition: 905 mm
  59. Jonathan Cole

    Yeah, so the distances for table position clearly indicate they are not using the head end, table plane, mid-line. Looks more like foot-end, floor and mid-line. OpenSkin is calculating the dose, but it is outside the phantom because of the assumed table position.

    Siemens define the zero point in their DICOM conformance statement but the ones I have found on the internet for Toshiba and Philips do not.

  60. Ed McDonagh reporter

    Toshiba single plane I sent you:

    • distance source to detector: 1200 mm
    • table longitudinal position: 520 mm
    • table lateral position: 30 mm
    • table height position: 990 mm
  61. David Platten

    Added openSkin data export back to the rfdetail page if skin dose map display is switched off. Also included the text about only Cu filters being included. Added some text to let the user know that this version of OpenREM can calculate and display skin dose maps for some systems. References issue #61, issue #382 and issue #384.

    → <<cset 128002420c9c>>

  62. Ed McDonagh reporter

    David Platten - did you or Jonathan Cole ever establish the head toe orientation on the 3D model?

    I've been having fun generating 3D visualisations for some of the studies in my laptop test database, and I'm pretty sure that for my datasets they are wrong in the head-toe direction.

    The coronary catheterizations are all taking place in the lower half of the phantom, and an NG tube insert has radiation right on the bottom edge of the phantom and a little further up - I hope for that patient's sake that it is displayed upside down!

    These are all Siemens Zee units.

  63. Ed McDonagh reporter

    Yes, the radiation is at the right end of the phantom now, but i'm not convinced about the angles. I must book some time in one of the rooms to thrash it out!

    In the mean time, can you add openSkin to the release notes?

  64. Jonathan Cole

    I thought I had checked orientations. It is possible top-bottom needs flipping but left-right doesn't as David has found.

    Have you tried it straight in openSkin with the PNG map? Is that upside down as well?

    There might be some co-ordinate system differences we need to account for.

  65. Jonathan Cole

    Head should be at the top of the PNG.

    If the orientation is wrong in openSkin we should fix it there. If it is just a matter of how the array is treated in the python, javascript and PNG export we can fix it in either.

    I'm going to try and install the latest dev version of OpenREM today so I can work on these issues properly.

  66. David Platten

    Added some (commented out) code that will try and calculate skin dose map data for every RF study in f when the user goes to the rffiltered.html page. I put this in as I wanted to calculate the skin dose map data for all of the studies in my off-line install of OpenREM. May be useful to have this as a feature at some point. References issue #61

    → <<cset be6f67576f28>>

  67. Jonathan Cole

    Testing this now and seems to work.

    It does block loading the page while rendering the skin doses though. Any way to avoid that? It takes about 10 minutes per skin map on my poor little server.

  68. Jonathan Cole

    I stand corrected. It doesn't seem to realise it already has some and is redoing them all.

    It's looking for a date folder structure that doesn't exist. My pickle files are all in the skin_maps with names skin_map_138.p

  69. Jonathan Cole

    It works as expected if I remove

    if study_date:
        skin_map_path = os.path.join(MEDIA_ROOT, 'skin_maps', "{0:0>4}".format(study_date.year), "{0:0>2}".format(study_date.month), "{0:0>2}".format(study_date.day), 'skin_map_'+str(study.pk)+'.p')
    else:
    

    and just leave the path without the date bits.

  70. Ed McDonagh reporter

    My fault. See Issue 398. I was thinking of Windows users like you, in the very long term, getting many thousand pickles in one folder and finding that the filesystem limits prevented any more going in.

    Have you been able to make any progress with orientations?

  71. Jonathan Cole

    OK, so it turns out my real issue is I never enabled celery. Now skin doses are running in the background. I don't know whether from this code or the original import.

  72. Jonathan Cole

    Orientations are definitely wrong right back in openSkin. I never noticed because of how I was using it.

    It's next on my list. I wanted to get the skin dose maps processing first so I have good guidance of what is right and wrong.

  73. Ed McDonagh reporter

    Celery should be processing them as they come in - if you view a fluoro study that was already in the database or hasn't yet been processed by Celery, then it should be generated on-the-fly. But I think Celery will do it again when it gets around to it.

    Regarding the orientations - I'm trying to work out a strategy for getting 0.7 to release, so any indication of timelines would be welcome 😄

  74. David Platten

    The IrradEventXRayData database table has the following fields that I assume will be populated if the data is available in the rdsr, but I'm not sure if this is really what we need as these could be different on an exposure-by-exposure basis (I think in practice this is unlikely as once a patient is positioned for a fluoroscopy procedure they usually stay there for the duration). Ed McDonagh, any thoughts?

    patient_table_relationship_cid, includes "feet-first" and "headfirst" (http://dicom.nema.org/MEDICAL/Dicom/2015c/output/chtml/part16/sect_CID_21.html)

    patient_orientation_modifier_cid, includes "prone", "supine" etc. (http://dicom.nema.org/MEDICAL/Dicom/2015c/output/chtml/part16/sect_CID_20.html)

  75. Jonathan Cole

    The Siemens unit gives me a choice of: HFS, FFS, HFP, FFP, HFLL, FFLL, HFRL, FFRL I've checked all of these and concluded the following: - As defined in the DICOM standard angles are always 0 degrees out of the chest and -90 degrees to the patient's right. - Table movement directions are defined once and does not change with patient position.

    I can either correct the angles to the table geometry and then we can change the display based on orientation or I can correct the table directions based on orientation and we always display the patient standing up.

    Somehow OpenREM will need to know that it is one of these 8 choices.

  76. David Platten

    My Siemens Artis Zee OpenREM data does not have any information in the patient_table_relationship or patient_orientation_modifier fields. However, the study includes the text Postion SRData="HFS " within the comment field.

    We could look for suitable data in the proper fields, and then try looking in the comment, and then revert to some sort of sensible default.

  77. Jonathan Cole

    I've got some code for correct patient orientations (the main ones anyway). Can anyone help with modifying the RDSR extractor to capture the orientation as David suggested?

  78. David Platten

    Skin dose maps now display either Assumed or Extracted for patient height, mass and orientation information depending on whether the corresponding information is available in the database. I think I'd prefer verbose orientations to be displayed, such as Head-first supine, rather than HFS, but can't work out how to do this at the moment (ideas welcome...). References issue #438 and #61

    → <<cset 80713e1992b4>>

  79. David Platten

    Update disclaimer below skin dose map? Make failure graceful for more systems

    The Philips RDSR on the demo site fails, for example:

    UnboundLocalError at /openrem/rf/9/skin_map/ local variable 'patPosZ' referenced before assignment Request Method: GET Request URL: http://testing.openrem.org/openrem/rf/9/skin_map/?http%3A%2F%2Ftesting.openrem.org%2Fopenrem%2Frf%2F9%2F=undefined Django Version: 1.8.18 Exception Type: UnboundLocalError Exception Value:
    local variable 'patPosZ' referenced before assignment Exception Location: /home/deploy/sites/testing.openrem.org/source/openrem/remapp/tools/openskin/geomclass.py in init, line 213 Python Executable: /home/deploy/sites/testing.openrem.org/virtualenv/bin/python2 Python Version: 2.7.12 Python Path:
    ['/home/deploy/sites/testing.openrem.org/source/openrem', '/home/deploy/sites/testing.openrem.org/virtualenv/bin', '/home/deploy/sites/testing.openrem.org/virtualenv/lib/python2.7', '/home/deploy/sites/testing.openrem.org/virtualenv/lib/python2.7/plat-x86_64-linux-gnu', '/home/deploy/sites/testing.openrem.org/virtualenv/lib/python2.7/lib-tk', '/home/deploy/sites/testing.openrem.org/virtualenv/lib/python2.7/lib-old', '/home/deploy/sites/testing.openrem.org/virtualenv/lib/python2.7/lib-dynload', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/home/deploy/sites/testing.openrem.org/virtualenv/local/lib/python2.7/site-packages', '/home/deploy/sites/testing.openrem.org/source', '/home/deploy/sites/testing.openrem.org/source/openrem'] Server time: Sat, 24 Jun 2017 09:50:09 +0100

  80. David Platten

    Regarding manipulating the 3D visualisation, we could detect if a mobile device is being used and then load in either desktop / laptop events, or mobile touch events as appropriate:

    if( /android|webos|iphone|ipad|ipod|blackberry|iemobile|opera mini/i.test(navigator.userAgent.toLowerCase()) ) {
        // include jQuery mobile and also the mobile touch events
        // http://www.w3schools.com/jquerymobile/jquerymobile_events_intro.asp
    }
    else {
        // include the non-touch events that are used at the moment
    }
    
  81. Ed McDonagh reporter

    As previously established, low priority. But the proposed test would mean that touch screen desktop/laptops would not be able to play... Is there a disadvantage to having the touch controls available all the time? The trackball link above seems to work as nicely with a mouse, track-pad or a finger.

  82. David Platten

    The previous commit seems to have largely worked. With Chrome on my laptop in "mobile device" mode it all works as expected. On my Nexus 5 phone it isn't quite as good: pinch zooming doesn't work, but everything else does. Ed McDonagh, how does this look for you?

  83. Ed McDonagh reporter

    On my Windows touchscreen laptop and my android phone, both using Chrome, single finger touch works well once it has made the first jump - initial touch makes a random spin, then it works as you'd want it to until you lift your finger.

    Multi-touch just makes it spin crazily.

    At first I looked using Chrome on my Ubuntu virtual machine and it didn't work very well - then I realised that normally 3D is disabled in that environment because there is a problem with the WebGL graphics or something in virtualbox. Has this new code disabled or overcome the disabling? It works ok-ish with the mouse.

  84. Ed McDonagh reporter

    I can't remember how it was before, but now the first press is always nice and glitch free. However, subsequent ones are usually subject to an initial jump. Two fingers does nothing (it used to spin madly).

    That is assuming I'm not using cached js. I tried it on Edge, and it ignored that there was anything there.

  85. Log in to comment