Skip to content

Latest commit

 

History

History
70 lines (41 loc) · 3.33 KB

2022-10-27.md

File metadata and controls

70 lines (41 loc) · 3.33 KB

OHIF Office Hours Notes 2022-10-27

How to optimize the viewer for mobile? OHIF WebView goes out of memory if go back and force between

A: it was a known issue before, but is fixed now (hopefully) by cornerstonejs/cornerstone3D#253


When creating docker compose for orthanc and OHIF, is there a way to automatically login to Orthanc server. How to make Ortahnc docker compose up doesn't show the username and password upon start

A: https://v3-docs.ohif.org/configuration/datasources/dicom-web/#running-orthanc

https://book.orthanc-server.com/faq/authentication.html#:~:text=To%20configure%20user%20authentication%20for,password%20to%20all%20your%20users.

Probably some combination of

 "RemoteAccessAllowed": true,
 "SslEnabled": false,
 "SslCertificate": "certificate.pem",
 "AuthenticationEnabled": false,
 "RegisteredUsers": {
   "test": "test"
 },

Will turn that off


Some use cases don’t want to show the annotations on every volume that are in the same frame of reference or another use case for prior study measurements, do we want to show up on others? Probably not. Or in the 4D case, it doesn’t make sense to have it appear on all frames

A: We have viewportSpecificAnnotationManager, one solution can be to generate a different manager for each viewport, but in the 4D case it is the same viewport so that might not work.

We discussed adding a config for cornerstoneTools to maybe in addition to checking if the volume slice is in the same slice span of the annotation, it also checks if the imageURIs match (similar to stack viewport), however, what about the reconstructed views? Maybe we add the imageURI of one of the handles of the annotation since basically we need to just check if the volume contains that imageURI volumeViewport.hasImageURI()


Depending on the system running OHIF, Cornerstone3D crashes on 750 slices for volume viewport.

A: cornerstone cache can be increased to increase its max

Since in vtk.js everything will eventually need to get converted to uint8 or float32, we do it automatically when loading and scaling the data ourselves and convert the data to float32, so there might be some extra memory footprint while technically not needed.

At the shader level, we added support of halfFloat implementation usage of the texture. Kitware/vtk-js#2046 but since halfFloat is approximation (11 bit instead of 16 bit) a flag should be set on the mapper via setPreferSizeOverAccuracy(true) to enable halfFloat

In another PR we experimented (Kitware/vtk-js#2058) with 16 bit textures via EXT_texture_norm16 extension of WebGL but that is not guaranteed to be supported in all devices

Eventually with the WebGPU becoming mainstream we will have much better memory management since WebGPU supports 16 bit texture natively.


How to learn vtk.js

A: There are some good tutorials here https://kitware.github.io/vtk-js/docs/tutorial.html


WebAssembly debugging

A: https://developer.chrome.com/blog/wasm-debugging-2020/


OpenJPEG problem with data becoming blurry

A: probably since our openjpeg codec is a two years old fork (https://github.com/PrecisionMetrics/openjpeg/tree/69e8e479cc3aed087d7fffc89b050452ad6d8ae8) of the official open jpeg (https://github.com/uclouvain/openjpeg) maybe if we try the upstream openjpeg everything is just solved