bug: Mismatched bit-depth on Mipmap tiles

[SitiSchu]

Describe the bug
By default it seems like both maketx and oiiotool (with -otex) always turn the output texture into 32-bit float even if the input image is a half (16-bit float) image:

$ oiiotool --info ./basecolor_1001.exr
./basecolor_1001.exr : 4096 x 4096, 3 channel, half openexr

$ oiiotool basecolor_1001.exr -otex basecolor_1001.tx

$ oiiotool --info ./basecolor_1001.tx
./basecolor_1001.tx  : 4096 x 4096, 3 channel, float tiff (+mipmap)

To prevent this from happening --attrib tiff:half 1 can be used. This will keep the input images bit depth on the root tile:
(Using imagemagick because I could not find a way for oiiotool to print the mipmap info)

$ oiiotool basecolor_1001.exr --attrib tiff:half 1 -otex basecolor_1001.tx

$ magick identify ./basecolor_1001.tx
./basecolor_1001.tx[0] TIFF 4096x4096 4096x4096+0+0 16-bit sRGB 1.09345MiB 0.001u 0:00.001
./basecolor_1001.tx[1] TIFF 2048x2048 2048x2048+0+0 32-bit sRGB 0.002u 0:00.001
./basecolor_1001.tx[2] TIFF 1024x1024 1024x1024+0+0 32-bit sRGB 0.002u 0:00.001
./basecolor_1001.tx[3] TIFF 512x512 512x512+0+0 32-bit sRGB 0.002u 0:00.002
./basecolor_1001.tx[4] TIFF 256x256 256x256+0+0 32-bit sRGB 0.002u 0:00.002
./basecolor_1001.tx[5] TIFF 128x128 128x128+0+0 32-bit sRGB 0.003u 0:00.002
./basecolor_1001.tx[6] TIFF 64x64 64x64+0+0 32-bit sRGB 0.003u 0:00.003
./basecolor_1001.tx[7] TIFF 32x32 32x32+0+0 32-bit sRGB 0.003u 0:00.003
./basecolor_1001.tx[8] TIFF 16x16 16x16+0+0 32-bit sRGB 0.004u 0:00.003
./basecolor_1001.tx[9] TIFF 8x8 8x8+0+0 32-bit sRGB 0.004u 0:00.003
./basecolor_1001.tx[10] TIFF 4x4 4x4+0+0 32-bit sRGB 0.004u 0:00.004
./basecolor_1001.tx[11] TIFF 2x2 2x2+0+0 32-bit sRGB 0.004u 0:00.004
./basecolor_1001.tx[12] TIFF 1x1 1x1+0+0 32-bit sRGB 0.005u 0:00.004

However, all other mipmaps are still converted to 32-bit float.

Things I tried:

• Using something like --attrib:subimages=all tiff:half 1 does not work and results in the same issue.
• -d half changes nothing and all tiles will be 32-bit anyway (including the root tile)
• -d double will convert all tiles to 64-bit float
• -d uint16 will also convert all tiles to 16-bit, but it won't be float anymore (obviously)

It seems like this is specifically an issue with 16-bit float/32-bit float options/files.

OpenImageIO version and dependencies

OIIO 3.1.13.1 | Windows/x86_64
    Build compiler: MSVS 1937 | C++17/199711
    HW features enabled at build: sse2
    No CUDA support (disabled / unavailable at build time)
Dependencies: BZip2 NONE, expat 2.6.3, fmt 12.1.0, Freetype 2.14.1, Imath 3.1.10, JPEG 80, libdeflate 1.23, Libheif NONE, libjpeg-turbo 3.1.2, LibRaw NONE, libuhdr 1.4.0, minizip-ng 4.0.10, OpenColorIO 2.5.1, OpenEXR 3.3.5, OpenGL, OpenJPEG 2.5.4, openjph NONE,
    PNG 1.6.50, Ptex NONE, Ptex NONE, pystring NONE, Qt5 NONE, Qt6 NONE, Robinmap 1.4.0, TIFF 4.7.1, WebP 1.6.0, yaml-cpp 0.8.0, ZLIB 1.3.1, ZLIB 1.3.1

To Reproduce

1. Create a 16-bit float exr (I used Nuke for testing, but the same issue happens with Substance Painter files)
2. Use maketx or oiiotool to convert it
3. Output will be 32-bit float without the --attrib flag
4. With the --attrib flag only the first tile will be 16-bit while the others will be 32-bit

[SitiSchu]

Not sure if it's intended or a seperate bug, but setting --attrib tiff:half 1 when the input image is 32-bit float still keeps the output image as 32-bit float. Intuitively I would expect it to convert it to 16-bit regardless (Especially since --attrib tiff:float 1 will turn 16-bit float inputs into 32-bit float).

[lgritz]

Just to clarify a few things so we all have the same mental model of OIIO's intended behavior.

1. When an OIIO file writer is asked to write a data type that the file format doesn't support, it will silently pick the smallest type supported by the file format, that loses the least amount of range or precision.
2. Although a technical note was once published by Adobe allowing 'half' pixel data in TIFF files, it went practically unnoticed and almost no TIFF-reading software (that isn't powered by OIIO) reads these files correctly.
3. In light of (2), the default behavior of OIIO's TIFF writer is that if asked to write half data to a TIFF file, it will not do so, since it is so likely to not be read correctly by other software. In light of (1), that means it ends up being promoted to float, since that's the type that TIFF data type that will not clip the half data to [0-1] LDR range.
4. Attribute "tiff:half" set to nonzero is a hint to the TIFF writer to not take this precaution, and allow writing half data to a tiff file. It is not a request to write the data as half, but rather it means "IF a request is made to write half, do it, and the user understands that most software probably can't read it correctly."
5. There is no recognized attribute called "tiff:float", it is not hint recognized by the TIFF writer, just like how "tiff:uint8" is not a recognized attribute, and "tiff:pelican" is not a recognized attribute.

Aside: TIFF does not support "arbitrary named metadata" like OpenEXR does, so when an image is written to a TIFF file and it has metadata that don't correspond to known TIFF tags, OIIO just silently drops them, since there isn't a way to store them in the TIFF file. Thus, "tiff:float" does nothing. But since in general, an attribute "<formatname>:blah" is interpreted not as true metadata, but rather as a hint to the <formatname> writer, I wonder if it should produce an error, or a warning, if it is not a recognized hint?

OK, on to your original question:

I tried this sequence:

oiiotool --create 512x512 3 -d half -o half.exr
oiiotool half.exr -d half -attrib tiff:half 1 -otex half.tx

and you are definitely correct -- only the first (highest res) MIP level is half, and the others end up as float, despite the -d and the hint. This is definitely a bug!

---

As another aside, I'm wondering why, if you're starting with an exr source image, you are using TIFF as your texture file format, instead of exr, which should have a much better ability to not lose any data along the way?

[lgritz]

Aha, a workaround:

oiiotool --oiioattrib tiff:half half.exr -d half -otex half.tx

You see, there is a "global" attribute (settable with --oiioattrib) "tiff:half" for all of OIIO that turns this on. That's the one you should really use.

Using --attrib just sets metadata in the top image, and that can override the global one, just for that one file. That's probably not the preferred method anyway, unless you want to set this option for some images but not others, on the same oiiotool command.

There still is a bug with the per-file attribute, definitely. I will fix that. But in the mean time, this should get you unstuck.

[SitiSchu]

Thanks for the quick response!

That's quite interesting, I wasn't aware that tiff had that limitation. With that in mind I do understand why oiiotool defaults to writing 32-bit images then.
In our case it seems like everything can read it anyway so thankfully not an issue. (However, V-Ray explodes when the mipmaps have differing bit-depths, hence this issue)

Personally I think having an error thrown when a unsupported attribute/hint would make sense, especially if arbitrary metadata isn't supported. A warning would work too of course, it still beats silently doing nothing.

The --oiioattrib fixes the mismatch so that's great, thanks for that.

---

We usually convert most textures to 8-bit which exr can't do, so while tiled exr is mildly more memory efficient for 16-bit images, having all converted textures be a .tx might just be simpler than having a mix of both formats.