Comments (6)
Related to #4
from dicom-microscopy-viewer.
Yeah that seems like a good idea.
With Cornerstone we are storing some tool-specific information like e.g. length, area for each measurement inside the ROI. It would probably be useful to automatically compute them for each type of ROI, but I guess we would have to ask a pathologist which information would be valuable.
However, this would require the ability to define where and how these should be displayed as text. Do we want to handle this in the library or require an application to do this?
I think we should do this at the library and provide sensible defaults, but allow the display function to be configured for each type of annotation (or possibly each annotation itself). Lots of cases have come up where people want to have custom labels, e.g. showing the annotator name that made the measurement, showing the target # for the lesion for the clinical trial, switching the label to another language, but probably 95% of people are using the default "Area X mmˆ2".
from dicom-microscopy-viewer.
@swederik I agree that it could be useful to automatically compute measurements; however, here I was more generally referring to the ability to store measurements on the ROI object and how we may approach this.
According to TID 1411 Volumetric ROI Measurements and Qualitative Evaluations, each Measurement Group contains a reference to one volume. A ROI
object is thus similar to a Measurement Group:
A grouping of related measurements and calculations that share a common context.
Therefore, I thought we could store the information for content items of TID 1411 Volumetric ROI Measurements and Qualitative Evaluations on the ROI
objects, including the actual ROI Measurements as defined in TID 1419 ROI Measurements as well as other items, such as Unique Tracking Identifier or Activity Session.
Alternatively, we could let an application (e.g. OHIF) handle all of this and provide such functionality outside of the viewer library (e.g. in the dcmjs microscopy adapter.)
from dicom-microscopy-viewer.
Yes, this makes sense. @swederik and I were digging through this a lot while working on converting the crowds-cure.org data into SR and it would have been great if all the data needed to create a Measurement Group were in the same place and all used the coded concepts for direct serialization.
from dicom-microscopy-viewer.
To me, it feels like these things should live in dcmjs rather than dicom-microscopy-viewer, because the same code could then be reused across projects/applications.
The viewer would then only handle the "bare" spatial coordinates (as it does at the moment). All other high-level information (e.g. measurements) would then be handled at the application-level (potentially using common tools provided via the dcmjs library).
What do you think?
from dicom-microscopy-viewer.
Yes, abstracting measurements away from the specific imaging modalities sounds good. To the extent possible I'd want the in-memory data structure (application state) to mirror the SR encoding as closely as possible so that edits to that state, say from a widget/tool or from editing a parameter form, would be kept in sync and the state could be serialized back to a dicom encoding whenever needed.
from dicom-microscopy-viewer.
Related Issues (20)
- Module Import Errors When Using [email protected] HOT 6
- Image Orientation of pyramid images are not covering all scenarios
- Request: Target IE 11 HOT 1
- Wrong log message HOT 1
- Offset issue / TotalPixelMatrixOriginSequence is different per layer HOT 1
- Examples do not run properly with local built version due to random css issue HOT 3
- Wrong markup measurements HOT 4
- On line example site doesn't work HOT 8
- Use only one unit testing framework
- Unit tests failing
- Do not use query parameters for retrieve rendered transations if not needed
- Tile debugging
- Is dicom-microscopy-viewer support Z-stacks image?
- Assert code 17 - resolutions_ assertion HOT 3
- Add dicom-microscopy-viewer to OHIF HOT 3
- Revisit status checks for branch configuration HOT 2
- IMS responds with octet-stream when image/jpeg is available HOT 7
- Microscopy images (modality = SM) doesn't render on the viewer. HOT 1
- Make media types configurable as options for the viewer
- Deploy new version to npm HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dicom-microscopy-viewer.