cornerstone3D icon indicating copy to clipboard operation
cornerstone3D copied to clipboard

Target Buffer Uint16 support?

Open Ouwen opened this issue 2 years ago • 1 comments

I noticed that when loading the image we provide a target buffer of either Float32 or Uint8. In cornerstonejs I believe there was support for Uint16 type. Larger medical image volumes (tomo) can be quite large when decompressed (200 slices of 2000x3000 uint16 pixels). This would translate to about 2.4GB if the native Uint16 is used, but would double to 4.8GB using Float32.

I was curious if there were any challenges in supporting uint16 with the underlying vtk engine.

Ouwen avatar Jun 28 '22 03:06 Ouwen

So there are a couple options. You need to minimize both RAM and VRAM but their usage is not 1:1 depending on the WebGL internal format.

If you have a Uint16 array and pass it through the pipeline now it can be mapped to half float as an internal format but this has less precision that 16 bits (see https://en.m.wikipedia.org/wiki/Half-precision_floating-point_format) so it might not completely accurately represent the image. If the range of the image is within a specific range it will, though (I think something like 0-3000ish, it's in the half float conversion code in vtk).

There is another option which is here but it's not merged yet: https://github.com/Kitware/vtk-js/pull/2058 which will allow Int16 to be faithfully represented using the EXT_texture_norm16 extension. That is probably a better option for the Tomo I think

Having said that, I think we would use a stack viewport for tomo and not make one massive buffer anyway. Especially because the array buffer length for the whole volume is likely going to exceed the chrome max array buffer length of around 2gb.

On Tue., Jun. 28, 2022, 5:53 a.m. Ouwen Huang, @.***> wrote:

I noticed that when loading the image we provide a target buffer of either Float32 or Uint8. In cornerstonejs I believe there was support for Uint16 type. Larger medical image volumes (tomo) can be quite large when decompressed (200 slices of 2000x3000 uint16 pixels). This would translate to about 2.4GB if the native Uint16 is used, but would double to 4.8GB using Float32.

I was curious if there were any challenges in supporting uint16 with the underlying vtk engine.

— Reply to this email directly, view it on GitHub https://github.com/cornerstonejs/cornerstone3D-beta/issues/141, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEUMMP3PB4VARFDYWOSHVLVRJZKDANCNFSM52AVMITQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

swederik avatar Jun 28 '22 05:06 swederik