InsightSoftwareConsortium / InsightSoftwareConsortium/ITK-Wasm
IWI sample image data buffers
- 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
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