fixes #88 (which was also showing in a couple datasets).
Occasionally, attributes.widthPx will not be the same as attributes.widthBytes // (attributes.componentCount * attributes.bitsPerComponentInMemory // 8), as was the case with @aaristov's dataset in #88.
In those cases both the sdk reader and the native memmap reader result in skewed images (see #88). Oddly enough, the NIS elements viewer is fine with these files, suggesting they don't directly use the SDK reader internally :/
This PR catches those cases, emits a warning, and forces the image width in pixels to be widthBytes // (componentCount * bitsPerComponentInMemory // 8)
fixes #88 (which was also showing in a couple datasets).
Occasionally,
attributes.widthPx
will not be the same asattributes.widthBytes // (attributes.componentCount * attributes.bitsPerComponentInMemory // 8)
, as was the case with @aaristov's dataset in #88.In those cases both the sdk reader and the native memmap reader result in skewed images (see #88). Oddly enough, the NIS elements viewer is fine with these files, suggesting they don't directly use the SDK reader internally :/
This PR catches those cases, emits a warning, and forces the image width in pixels to be
widthBytes // (componentCount * bitsPerComponentInMemory // 8)