Skip to content

Latest commit

 

History

History
315 lines (216 loc) · 14.3 KB

2024-08-29.md

File metadata and controls

315 lines (216 loc) · 14.3 KB
Raw

OHIF Office Hours Notes 2024-08-29

Q & A

Attendees: 14

Discussed:

  • 🖥️ Upcoming changes in Cornerstone 3D 2.0 affecting volume loading and shared array buffer usage
  • 🎨 Strategies for changing colors of prior studies in OHIF viewer
  • 🖼️ Progressive loading options and mobile device considerations for OHIF
  • 📊 Changing default volume color in Cornerstone
  • 🤖 Automatically reloading AI segmentations in OHIF viewer
  • 🏥 Resources for DICOM code mapping in Echocardiogram reports
  • 🖼️ Integrating OHIF viewer with custom DICOM storage solutions
  • 🔄 Managing annotations between main website and OHIF in iframe
  • 🌐 Optimal hosting strategies for OHIF viewer and DICOM files across servers
  • 📍 Adding point annotations in OHIF using existing tools or custom extensions

🖥️ Using the volume loader what is the implications of deactivating the sharedArrayBuffer, in general terms, performance, and what does it mean for the cpu/gpu rendering pipeline?

A: This question is becoming outdated due to upcoming changes in Cornerstone 3D 2.0:

  1. Shared array buffer is being phased out in the new version.
  2. The new approach eliminates the need for a large volume array buffer.
  3. In Cornerstone 3D 2.0:
    • Everything will be in the image cache.
    • 3D textures will only be created on the GPU side.
    • There will be no CPU-side volume cache.
    • Images will be sent directly to GPU for volume rendering.
  4. These changes will significantly reduce memory footprint and improve performance.
  5. The new system will work without shared array buffer, solving compatibility issues on some platforms.

These updates are expected to be released soon, with OHIF integration following shortly after.

🎨 How can I change the color (either outline or viewport overlay text) for prior studies? Or perhaps for all studies whose StudyInstanceUID doesn't match the one in the URL?

A: To change colors for prior studies or studies not matching the URL:

  1. The outline color is defined in the ViewportPane component.

  2. You can access study information through various services:

    • Use viewportGridService to get viewport state
    • Use displaySetService to get display set information
    • Compare study instance UIDs to determine if it's a prior study

  3. Modify the ViewportPane component to accept a prop for custom border color:

    • Add a condition in the component to check if it's a prior study
    • Apply different styles based on this condition

  4. For a more dynamic approach, consider using the hanging protocol service to define rules for different studies.

  5. You may need to create a PR to add this functionality to the core OHIF code.

Example approach:

// In your mode or extension const isPriorStudy = (studyInstanceUID) => { // Compare with current study UID from URL or state };

// In ViewportPane component const borderColor = isPriorStudy(viewportData.StudyInstanceUID) ? 'yellow' : 'default-color';

Implement this logic and create a PR for the OHIF team to review.

🖼️ https://www.cornerstonejs.org/live-examples/volumeprogressive I am looking for JLSMixed options. Is this progressive loading supported by the OHIF framework? If yes, can you please help me where to configure

A: Regarding JLSMixed options and progressive loading:

  1. JLSMixed is not currently supported in OHIF.
  2. It's not recommended for mobile devices due to performance issues.
  3. For mobile devices, server-side rendering might be a better solution.
  4. The DICOM standard recently added 3D support, which could be leveraged for more efficient rendering.

Recommendations:

  • For mobile devices, consider using a stack viewport and fetch 3D renderings from the server-side.
  • This approach reduces the amount of data transferred, which is crucial for mobile performance.
  • Wait for the implementation of the new DICOM web standard with 3D support in OHIF.

Future developments may include a new viewport type that combines aspects of volume and stack viewports for more efficient mobile rendering.

📊 When we init the volume, it default color as gray, where this default value is declared? I want to change this gray color to something else, can you please help me locate that code place? I have checked the initial volume loading in the cornerstone but I am not able to locate it. Does that require code change in VTK?

A: To change the default gray color of the volume:

  1. The color is determined by the transfer function that maps pixel values to colors.
  2. For CT scans, the default mapping often results in a gray appearance for zero values.

To change this:

  1. Locate the getVolumeProps function in the Cornerstone streaming image volume loader.
  2. Find where the scalar data is initialized (likely as a Float32Array).
  3. Instead of initializing with zeros, set a default value that maps to your desired color:

scalarData.set(-10000); // or another appropriate value

  1. Be cautious as this change might affect different modalities differently (e.g., CT vs PET).

Alternative approach:

  • Modify the transfer function to map zero (or your new default value) to the desired color.
  • This might be a safer approach as it doesn't change the underlying data.

Consider creating a lookup table for different modalities to set appropriate defaults for each.

🤖 Upon computing my own AI segmentations in the viewer (which are stored in Google Cloud), how can I automatically reload the viewer to display these masks without having to manually reload the entire page to fetch the updated Google Cloud state? I see that the code for the "Loading SEG..." progress bar is within the OHIFCornerstoneSEGViewport.tsx file. How can I induce this "Loading SEG..." screen?

A: To automatically reload and display new segmentations:

  1. You need to invalidate the data source and reinitiate the flow of the app.

  2. Options for implementation:

    a. Direct approach:

    • Call retrieveSeriesMetadata in the DicomWebDataSource
    • Reinitiate the flow: retrieve metadata -> add to store -> create display sets

    b. Cloud function approach:

    • Set up a Google Cloud Function to watch for changes in your storage
    • When a new segmentation is uploaded, notify the OHIF frontend
    • Frontend can then trigger a reload of the specific segmentation

  3. To reload a specific DICOM SEG object:

    • Currently not directly supported
    • You'd need to implement a way to selectively reload and update specific objects

  4. For the "Loading SEG..." screen:

    • This is part of the viewport rendering process
    • You'd need to trigger a re-render of the viewport with the new segmentation data

Implementation steps:

  1. Create a method to fetch updated segmentation data
  2. Implement a notification system (websocket or polling) to detect new segmentations
  3. When notified, fetch new data and update the relevant display sets
  4. Trigger a re-render of the affected viewports

Consider creating a feature request or PR for OHIF to support more granular updates of specific DICOM objects.

🏥 We are trying to create an Echocardiogram report and we have the report template in which we need to map the DICOM code against each label, however we failed to map all the fields. Is there was any resources or consortium for provide these mapping details based on modality

A: For Echocardiogram report DICOM code mapping:

  1. Refer to the full DICOM standard for comprehensive information:

  2. Specific resources:

    • Part 16 of the DICOM standard contains templates for various reports, including ECG
    • Look for sections related to Echocardiogram measurements and report structures

  3. Example mappings:

    • AOV2 might refer to "mean velocity at aortic valve"
    • Look for specific measurement codes in the DICOM standard

  4. Validation:

    • Cross-reference with official DICOM documentation
    • Consult with domain experts or echocardiography specialists

  5. For PDF export:

    • You have more flexibility in how you present the information
    • Ensure you're using consistent terminology with DICOM standards

  6. For DICOM SR (Structured Reporting):

    • Adhere strictly to the DICOM standard for proper interoperability

If you're unsure about specific mappings, consider reaching out to medical imaging informatics communities or DICOM working groups for guidance.

🖼️ I have a website with the OHIF viewer as an iframe. I have a server with lots of DICOM files that is not a PACS (a custom sql database + dicom files). I want to be able to send a Dicom from the server to my iframe. How do you suggest I do that? Should the OHIF server be on the pseudo PACS or the front ?

A: To integrate OHIF with your custom database:

  1. Preferred approach: Implement DICOMweb standard on your server

    • This allows OHIF to communicate with your server using standard protocols

  2. Alternative: Create a custom data source for OHIF

    • Implement methods to fetch studies, series, and instances from your SQL database

  3. OHIF server location:

    • OHIF doesn't need a server; it's a client-side application
    • Host the built OHIF files on a web server (e.g., nginx, AWS S3 + CloudFront)

  4. Configuration:

    • Set up OHIF to point to your custom DICOMweb endpoints
    • Modify the configuration file (e.g., default.js) to specify your server URLs

  5. Data flow:

    • OHIF in iframe -> Your custom DICOMweb API -> SQL Database + DICOM files

  6. Optimization:

    • Consider implementing the Static DICOMweb approach for better performance
    • This involves pre-generating JSON metadata files and organizing DICOM data in a specific folder structure

  7. Security:

    • Ensure proper authentication and authorization between your main site and the OHIF iframe

Remember, implementing the DICOMweb standard is the most compatible and future-proof approach. If possible, consider migrating to a proper PACS system for better integration and standards compliance.

🔄 I want to be able to add send/update/store annotation from my main website and store it in my DB. Is it possible if I use an iframe ? If so, how do you suggest i can do it ? Should I modify the OHIF viewer fork that I have to do so ? Or I can do it by calling special event in the iFrame ?

A: To manage annotations between your main website and OHIF in an iframe:

  1. Communication options:

    • Use postMessage API for iframe-parent communication
    • Implement custom events in OHIF that trigger postMessage calls

  2. Annotation storage:

    • Option 1: Custom backend API
      • Create endpoints to save/update annotations
      • Send annotation data from OHIF to parent, then to your backend
    • Option 2: DICOM SR (Structured Reporting)
      • Use OHIF's built-in DICOM SR support
      • Store DICOM SR objects in your database

  3. Implementation steps:

    • In OHIF: Add listeners for annotation changes
    • In parent: Implement postMessage listeners
    • In backend: Create API endpoints for annotation CRUD operations

  4. Example flow:

    // In OHIF window.parent.postMessage({type: 'annotation', data: annotationData}, '*');

    // In parent window.addEventListener('message', (event) => { if (event.data.type === 'annotation') { // Send to your backend API } });

  5. Considerations:

    • DICOM SR is standards-compliant and interoperable
    • Custom JSON format might be simpler but less portable

  6. OHIF modifications:

    • You may need to extend OHIF to expose annotation events
    • Consider contributing back to OHIF if you implement useful features

Remember, the iframe is just a deployment method. Focus on implementing the annotation storage and retrieval logic, which can work with or without an iframe.

🌐 If the dicom files are stored on a server A and my frontend is on a server B. The user connect from the server A to my website hosted on server B. Do you recommend, I host the OHIF viewer on the server A or server B ? Did you experienced UX delay if the OHIF server is hosted in a different server than a front ?

A: Regarding hosting OHIF and managing DICOM files across servers:

  1. OHIF Hosting:

    • It's generally recommended to host OHIF separately from the DICOM web server
    • OHIF is a client-side application and can be hosted on a CDN for better performance

  2. Server Configuration:

    • Server A: DICOM files and DICOM web server
    • Server B: Frontend and OHIF viewer

  3. Performance Considerations:

    • The main factor is the network latency between the user and the DICOM web server
    • Hosting OHIF closer to the user (e.g., on a CDN) can improve initial load times

  4. Recommendations:

    • Use a load balancer to distribute traffic
    • Implement a reverse proxy on the local site to access data
    • Compress OHIF files before serving (use yarn build)
    • Set appropriate caching headers for OHIF static files

  5. Deployment Options:

    • Serve OHIF files using nginx or any suitable web server
    • Consider using cloud services like AWS CloudFront for global distribution

  6. Security:

    • Ensure proper CORS configuration if OHIF and DICOM web server are on different domains

  7. Optimization:

    • Use HTTP/2 or HTTP/3 for better performance
    • Implement client-side caching strategies

The key is to optimize the delivery of OHIF static files and minimize latency for DICOM data requests. The exact setup depends on your specific requirements and infrastructure constraints.

📍 Can we add points (instead of arrow), if yes, should we modify cornerstone js ? or is it possible to add feature like this from the extension or the modes ?

A: Yes, you can add points instead of arrows in OHIF:

  1. Use the existing ProbeTool:

    • This tool already provides point annotation functionality

  2. Implementation:

    • You can add the ProbeTool to your mode or extension without modifying Cornerstone.js
    • Configure the tool in your hanging protocol or toolbar setup

  3. Customization:

    • If you need specific behavior not provided by ProbeTool, you can create a custom tool
    • Extend the base annotation tool in Cornerstone Tools

  4. UI Integration:

    • Add the tool to your toolbar configuration
    • Use the existing UI components or create custom ones for the point tool

Remember, modifying Cornerstone.js directly is not necessary for most use cases. Utilize the extension and mode system in OHIF for customizations whenever possible.