InsightSoftwareConsortium / InsightSoftwareConsortium/ITK-Wasm
[Bug] `writeImageNode` crashes with `Uint32Array`, but not `Uint8Array` or `Uint16Array`
- Dominant language
- Python
- Stars
- 235
- Forks
- 61
- Avg merge
- 4d 19h
- Merged PRs (30d)
- 4
Description
Crashes with both `writeImage` from the cdn or `writeImageNode` in nodejs.
Let me know if this is expected behavior or not. The [documentation](https://github.com/InsightSoftwareConsortium/ITK-Wasm/blob/main/packages/core/typescript/itk-wasm/src/interface-types/int-types.ts) seems to indicate `uint32` should be supported.
Repro:
```js
import { writeImageNode } from '@itk-wasm/image-io'
const dtypes = [
{componentType: 'uint8', data: new Uint8Array(100*100), name: 'uint8_test'},
{componentType: 'uint16', data: new Uint16Array(100*100), name: 'uint16_test'},
{componentType: 'uint32', data: new Uint32Array(100*100), name: 'uint32_test'},
]
dtypes.forEach(async (d) => {
console.log("Writing", d.name)
const res = await writeImageNode(
{
imageType: {
dimension: 2,
pixelType: 'Scalar',
componentType: d.componentType,
components: 1
},
name: d.name,
direction: new Float64Array([1.0, 0.0, 0.0, 1.0]),
size: [100, 100],
data: d.data, // <- !!! Will crash if Uint32Array
},d.name + '.tif')
console.log(d.name, res)
})
```
Contributor guide
Research direction
Start at the writeImageNode entry point in @itk-wasm/image-io and trace how the supplied typed arrays are handled for image output. Run the provided Uint8Array, Uint16Array, and Uint32Array reproduction, then verify that uint32 writing completes without a crash while the existing cases continue to work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, nodejs
- Domain
- data
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100