Closed csparker247 closed 3 weeks ago
The fix in #110 disables memory mapping when the slice files are not encoded with the same endianness as the host system. If the volume in question absolutely needs to be memory mapped, users are encouraged to re-encode the TIFF files in their volume directory.
What happened?
If I use
vc_render
on the current develop (commit: 020c8b2), I get the following noisy texture for surfaces from a particular volume:However, if I render using the v2.26.0 binaries, I get the expected result:
If I modify the default value of
Volume::memmap_
tofalse
on thedevelop
branch, the image is rendered correctly, which confirms my suspicion that this bug is related to the memory mapping introduced in #98.Given the nature of the noise, I suspect that there's an image encoding property that we're not handling properly. The super saturated regions look more or less correct as well, which suggests to me an endianess issue, and this volume is encoded in big-endian while I'm on a little-endian system:
Probably, libtiff handles the endian conversion when we load into memory, but obviously does not when we memory map the files.
On which operating systems have you experienced this issue?
Relevant log output
No response
Code of Conduct