InsightSoftwareConsortium / InsightSoftwareConsortium/ITK-Wasm

IWI sample image data buffers

Open
#1,239 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
235
Forks
61
Avg merge
4d 19h
Merged PRs (30d)
4

Description

I was able to create sensible IWI images with Python:

```python
import itk

image = itk.imread('fslmean.nii.gz')
itk.imwrite(image, 'fslmean.iwi.cbor')
```

However, the validation itk-wasm test datasets seem odd, specifically
- 197kb 24-bit RGB itk-wasm\test\pipelines\median-filter-pipeline\cthead1.iwi.cbor
- 66kb 8-bit @itk-wasm\dam\test\data\cthead1.iwi.cbor

When I decode each, the data.buffer.bytelength is larger than the data.byteLength, with the latter being the number of bytes described by the header (while the former is >200 bytes too large). While padding datasets for byte alignment seems understandable, the strange thing is the the padding is at the start of the array, not the end. This makes fast reading of byte data as Uint8Array regardless of datatype (e.g. Float32Array, etc) ungainly. My best guess is these validation versions were created by beta software and should be updated to reflect the standard, but it might be worth understanding the origin of this discrepancy.

```javascript
import { decode } from 'cbor-x'

export function iwi2nii(arrayBuffer) {
// decode from cbor to JS object
let iwi = decode(new Uint8Array(arrayBuffer))
if (iwi.data.buffer.byteLength > iwi.data.byteLength) {
console.log(`!buffer larger than data ${iwi.data.buffer.byteLength} vs ${iwi.data.byteLength} bytes`)
}
// note padding at the start!
const img8 = new Uint8Array(iwi.data.buffer, iwi.data.buffer.byteLength-iwi.data.byteLength, iwi.data.byteLength)
// this also works, but only if data is Uint8Array, not Float32Array:
const imgOK = new Uint8Array(iwi.data.slice())
}
```

Contributor guide

Open the contributing guide

Research direction

Start with the validation datasets at itk-wasm\test\pipelines\median-filter-pipeline\cthead1.iwi.cbor and itk-wasm\dam\test\data\cthead1.iwi.cbor, decoding them with the shown cbor-x check. Trace how these IWI files were generated and compare their buffers with the standard. Done means the discrepancy's origin is understood and the affected validation data is updated or the behavior is documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, python, wasm
Domain
data, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.