Use correct data type from Display Set for vtkDataArray

We are currently hardcoding the vtkDataArray to be backed by an Int16Array:

Lines 27 to 35 in 982f193

    
           // TODO: Support all data types (UInt8Array, etc...) 
        
           const pixelArray = new Int16Array(xVoxels * yVoxels * zVoxels); 
        
           // TODO: Support numberOfComponents = 3 for RGB? 
        
           const scalarArray = vtk.Common.Core.vtkDataArray.newInstance({ 
        
               name: "Pixels", 
        
               numberOfComponents: 1, 
        
               values: pixelArray, 
        
           });

We need to make this support the actual datatype provided with the display set metadata.

Not sure how to get other data into correct json format or other way to load data. Also need some RBG data to test with

OHIF/Viewers#177

Gist is here:

https://gist.github.com/swederik/b7901bd933e6497720783e532616eec0

Check image pixelRepresentation (signed) and bitsAllocated to determine data type. Use correct typed array. An example is here: https://github.com/cornerstonejs/cornerstoneWADOImageLoader/blob/b468ad706276daa4c3cf6aefb3beca924a588b61/src/shared/decoders/decodeLittleEndian.js#L6

The point here is to use the BitsAllocated and the PixelRepresentation to determine the correct array datatype to create. Also to generate appropriate diagnostics if there isn't a valid mapping.

We now support signed and unsigned 16 bit data. console.asserts() have been put in for 8 bit data (signed and unsigned) as the vtk renderer crashes when using 8 bit data. RGB data makes no sense for these plugins so we also console.assert() on components > 1.

console.assert doesn't really do anything except print. Better to throw an error that can be caught and acted on by the application.

Agreed. I’ll add them. One advantage to the Singleton approach might be that if we associate a valid data configuration with the class rather than the instance we can show one error message for the class. So in the case of the MPR views we would get 2 errors thrown rather than 4....

Or perhaps the application can combine the errors in a list view dialog....

I put in throw new Error("messages") but they get swallowed here in tracker.js:
_compute() {
this.invalidated = false;

var previous = Tracker.currentComputation;
setCurrentComputation(this);
var previousInCompute = inCompute;
inCompute = true;
try {
  withNoYieldsAllowed(this._func)(this);
} finally {
  setCurrentComputation(previous);
  inCompute = previousInCompute;
}

}

The try just does a finally, no errors are reported to the user.
I put in console.log() messages as well so that something will show up.

Oh that's interesting... I'll see if we can fix that

Is there more to do on this task?

	// TODO: Support all data types (UInt8Array, etc...)
	const pixelArray = new Int16Array(xVoxels * yVoxels * zVoxels);

	// TODO: Support numberOfComponents = 3 for RGB?
	const scalarArray = vtk.Common.Core.vtkDataArray.newInstance({
	name: "Pixels",
	numberOfComponents: 1,
	values: pixelArray,
	});