dg1an3
visualization | mapping | imaging | opensource
Sunday, March 07, 2021
My Back Pages
An index of...
Injuries...Head injuries...Bone breakages
Disease...G
Civ
Pinhole
ZX-81
Merlin
James
Zilog
RLE
Radar...Sperry, Ellason, NexRad
Popular Culture
Fear of...
Julian Jaynes
Drawing on the Right Brain
Levay
Radio
CA1D
JuliaB
Fractals
Cessna...SkyHawk, Citation
Track
Band
Monday, March 01, 2021
Thursday, February 04, 2021
TG-263 vs StructureSet
can a VAE help w the mapping?
python to parse spreadsheet <link>
python to parse hn sset <link>
python parse fma <link>
Monday, June 29, 2020
Sunday, December 01, 2019
SRO Decoder Ring QA Worklist
And in the sledgehammer solution department--as mentioned in the previous post, the problem of mapping SRO meaning is insidious. Confusion about patient positions (as in the this post) is bad enough. So why not use machine learning here as well?
Given an SRO and an offset, train an ML model to recognize the input-output relationship. Notebook link is here.
To turn the notebook in to a production service, we made the following adaptations:
A few contextual pieces of information that still need work:
Given an SRO and an offset, train an ML model to recognize the input-output relationship. Notebook link is here.
To turn the notebook in to a production service, we made the following adaptations:
- Fable ElmishFatline front end on IPFS
- Flask RESTful Web App on azure
- Train through notebook
- Weights in IPFS
A few contextual pieces of information that still need work:
- what about association to site?
- iView: Applying shift after first field--how to enter with TPO that won't associate with second field?
Friday, November 29, 2019
RT Image Review Worklist Triage
In this previous post on better image review workflows, David Clunie's noted zombie apocalypse was imminent as we waited for better predictive models for image review behavior. Well, the zombie apocalypse never happened. But I have made some progress in sketching a basic model to analyze usage patterns.
The inputs are:
The inputs are:
- Time of day of physician login / workstation location
- Time of day of image acquisition
- Time offfset of image approval
- Image feature vector, in some latent space of patient geometry
Then these are regressed to get a prediction of likelihood of image being opened on a workstation, at a given time.
What can be done with this prediction? Caching on the local drive could be accomplished using:
- Windows Offline Files
- Dokan library, or similar
- BDS Storage for local drive
Additionally, memory caching could be used
- For a WCF-based SoA architectures, memory caching can be implemented either in the client (using a custom binding stack), or in the service as a custom IOperationInvoker.
- MSQ 3D IRW already implements a memory caching for AVS-based cone beam CTs.
So with some implementation for the actual caching, we can fit the model and produce predictions. If only we had some test data...
Stay tuned for a demo of the model, possibly with only fake input data.
Monday, February 25, 2019
A picture of IEC Table rotations
I have always struggled with a mental picture to help understand how rotation directions work in IEC table coordinates. As we were looking in to support for decubitus, it occurred to me that rotation directions could be understood in terms of the relationship between orientations that were separated by 90 degrees.
For instance, HFS > HFDL > HFP > HFDR are all related by a 90 degree table roll / transverse rotation, and that the direction corresponds to a positive rotation (clockwise when viewed from the foot of the table). Likewise, HFS > FFS and HFP > FFP can be viewed as resulting from two 90 degree rotations, with an intermediate stop at a rotation that isn't typically used for treatment (but does generally correspond to stereotactive treatment mode on advanced linacs).
So I assembled this in to a single chart, that I have been checking over to see if it still makes sense:
For instance, HFS > HFDL > HFP > HFDR are all related by a 90 degree table roll / transverse rotation, and that the direction corresponds to a positive rotation (clockwise when viewed from the foot of the table). Likewise, HFS > FFS and HFP > FFP can be viewed as resulting from two 90 degree rotations, with an intermediate stop at a rotation that isn't typically used for treatment (but does generally correspond to stereotactive treatment mode on advanced linacs).
So I assembled this in to a single chart, that I have been checking over to see if it still makes sense:
Subscribe to:
Posts (Atom)
-
Looking at the CQRS architectural pattern, there are interactions that maybe I didn’t fully understand. Like if the target of queries/comma...
-
One of the problems to be addressed for adaptive treatment paradigms is the need to visualize and interact with deformable vector fields (...
-
I was reading a bit on the developing RayCare OIS , and wondered why an optimization algorithm company would have an interest in developin...