Option for display RGB images as independent components

[oeway]

In some cases, we would like to adjust each color channel independently, so it would be nice to provide an option to make the contrast of each channel adjustable.

I did a quick test by forcing actorContext.independentComponents=true for RGB images, it show up as 3 channels, however, the overall intensity is much lower than normal.

[thewtex]

@oeway one possible approach is to set the imageType.pixelType to 14, VariableLengthVector. Should be possible after #371

however, the overall intensity is much lower than normal.

The behavior can be more similar to dependent components by setting the piecewise function to be flat as opposed to the default that is low at low intensities and increases to 1 at the highest intensity via:
https://kitware.github.io/itk-vtk-viewer/api/#setImagePiecewiseFunctionGaussians-gaussians-component-name

[oeway]

Great! I will try that!

[oeway]

OK, just tried with pixelType=14 but got an error from DownsampleWasm.js:9 : Unknown or unsupported pixel type: itk::CommonEnums::IOPixel::UNKNOWNPIXELTYPE

[thewtex]

DownsampleWasm.js:9 : Unknown or unsupported pixel type: itk::CommonEnums::IOPixel::UNKNOWNPIXELTYPE

Hmm, since UNKNOWNPIXELTYPE is the 0'th value of the enum:

https://github.com/InsightSoftwareConsortium/ITK/blob/c2116d956b17288dfd3bd58aec2fb4cade4324b1/Modules/Core/Common/include/itkCommonEnums.h#L51

https://github.com/InsightSoftwareConsortium/itk-js/blob/b19d277a654eb90ea4347a0b62c0e73d5433b7c3/src/PixelTypes.js#L1

It is likely that we can not getting 14 passed in somewhere, instead undefined or similar.

[thewtex]

Ah, we are missing VariableLengthVector support here:

https://github.com/InsightSoftwareConsortium/itk-js/blob/b19d277a654eb90ea4347a0b62c0e73d5433b7c3/src/itkJSONImageIO.cxx#L159-L232

[oeway]

I tried to debug it but gave up after some attempts. How do you usually debug this type of issue? Especially when we have both js and wasm.

[thewtex]

For Kaibu I found that:

cd ~/src/itk-vtk-viewer
npm link
cd ~/src/kaibu
npm link itk-vtk-viewer
cd ~/src/itk-vtk-viewer
npm run build:debug

worked.

For WASM, Chrome recently added really cool WASM / C++ / DWARF support:

https://developers.google.com/web/updates/2020/12/webassembly

But I have not tried it, yet.

[oeway]

Ok, thank you! I used npm link too, but I only did npm run build, without :debug. When I add debugger instructions, the code show up in the chrome debugger is not the actual source code, I guess with the :debug I will get the source map in the chrome debugger?

BTW, for Kaibu, I hade some issue with importing itk vtk viewer, right now I am using a script tag without webpack compilation. Do you have any pointer for that?

[thewtex]

With :debug, it does not do minification in the build, which makes the code much more readable.

What are the issues occurring during import? With the recent major refactor, we upgraded to Webpack 5, but that required a few Webpack workarounds.

Patch to address the UNKNOWNPIXELTYPE issue:

InsightSoftwareConsortium/ITK-Wasm#397

[oeway]

I tried a while ago, will test it later and report in another issue.

Awesome! I am glad that you found the issue!

[thewtex]

Patch: #374

[oeway]

@thewtex Would you have a chance to look at the remaining issue with this thread? Basically when I use pixelType=14 I couldn't get it work with either RGB or RGBA image, it becomes gray. See here: imjoy-team/kaibu#50

[thewtex]

@oeway yes will take a look 👍

[thewtex]

Addressed in #382 . The hue of the result is now correct, although the image overall is darker -- will have to look into that.

[oeway]

Addressed in #382 . The hue of the result is now correct, although the image overall is darker -- will have to look into that.

Cool! Thank you!

[thewtex]

overall is darker -- will have to look into that.

#488 should address this.

[thewtex]

For WASM, Chrome recently added really cool WASM / C++ / DWARF support:

BTW, we now have good documentation for this: https://wasm.itk.org/examples/debugging.html#Chromium-based-browsers