educelab / volume-cartographer

Volumetric processing toolkit and C++ libraries for the recovery and restoration of damaged cultural materials
GNU General Public License v3.0
63 stars 21 forks source link

[Bug] Textures are all noise #108

Closed csparker247 closed 3 weeks ago

csparker247 commented 3 weeks ago

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:

render-test_head

However, if I render using the v2.26.0 binaries, I get the expected result:

render-test_v2 26 0

If I modify the default value of Volume::memmap_ to false on the develop 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:

ExifTool Version Number         : 12.76
File Name                       : 0000.tif
Directory                       : .
File Size                       : 8.1 MB
File Modification Date/Time     : 2024:10:10 09:57:40-04:00
File Access Date/Time           : 2024:10:17 15:35:42-04:00
File Inode Change Date/Time     : 2024:10:10 09:57:40-04:00
File Permissions                : -rwx------
File Type                       : TIFF
File Type Extension             : tif
MIME Type                       : image/tiff
Exif Byte Order                 : Big-endian (Motorola, MM)
Subfile Type                    : Full-resolution image
Image Width                     : 2014
Image Height                    : 2014
Bits Per Sample                 : 16
Compression                     : Uncompressed
Photometric Interpretation      : BlackIsZero
Image Description               : ImageJ=1.54g.unit=mm.min=0.0.max=65535.0.
Strip Offsets                   : 240
Samples Per Pixel               : 1
Rows Per Strip                  : 2014
Strip Byte Counts               : 8112392
X Resolution                    : 38.998518
Y Resolution                    : 38.998344
Resolution Unit                 : None
Image Size                      : 2014x2014
Megapixels                      : 4.1

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

csparker247 commented 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.