bug: (oiiotool) -d don't work with <subimagename>

[MrLixm]

Describe the bug

Hey there, it seems that the -d flag to change the pixel data type doesn't allow to select a specific subimage to apply its change on. While the documentation states it's possible with -d <subimagename>.*=<datatype> I haven't been able to generate an image with the expected subimage bitdepth encoding.

OpenImageIO version and dependencies

This is the oiiotool executable from the python wheels.

OIIO 3.1.10.0 | unknown arch?
    Build compiler: MSVS 1944 | C++17/199711
    HW features enabled at build: sse2
    No CUDA support (disabled / unavailable at build time)
Dependencies: DCMTK NONE, expat 2.6.3, FFmpeg NONE, fmt 10.2.1, Freetype 2.13.2, GIF 5.2.1, Imath 3.1.10, JPEG 80, JXL NONE, 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, OpenCV NONE, OpenEXR 3.3.5, OpenGL, OpenJPEG 2.5.4, openjph NONE, PNG 1.6.50, Ptex NONE, Ptex NONE, pybind11 3.0.1, pystring NONE, Python3 3.10.11, Qt5 NONE, Qt6 NONE, Robinmap 1.4.0, TBB
    NONE, TIFF 4.7.1, WebP 1.6.0, yaml-cpp 0.8.0, ZLIB 1.3.1, ZLIB 1.3.1

To Reproduce

Here is an oiiotool command to reproduce the bug. The command generates a synthetic images form scratch that is made of 3 subimages that are then written as OpenEXR.

oiiotool.EXE --pattern fill:topleft=.1,.1,.1,0.5:topright=1,0,0,0.7:bottomleft=0,1,0,0.3:bottomright=0,0,1,0.3 2048x1080 4 --pattern checker:width=64:height=64:color1=.2,.2,.2,1:color2=0.6,0.6,0.6,1 2048x1080 4 --over --noise:type=gaussian:seed=666:nchannels=3 --dup --chsum:weight=.2126,.7152,.0722 --chnames luma --chappend --pattern fill:top=250:bottom=0 2048x1080 1 --chnames depth.Z --pattern checker:width=64:height=64:color1=.2,.5,.2:color2=.6,.7,.8 2048x1080 3 --chnames n.r,n.g,n.b --attrib oiio:subimagename normal --siappendall -d half -d subimage01.*=float --compression zips -o image.mpart.exr

the important part of that command is (which I hope is correct):

--siappendall -d half -d subimage01.*=float --compression zips -o image.mpart.exr

running oiiotool --info over it output:

image.mpart.exr : 2048 x 1080, 5 channel, half openexr
    3 subimages: 2048x1080 [h,h,h,h,h], 2048x1080 [h], 2048x1080 [h,h,h]
    channel list: R, G, B, A, luma
    compression: "zips"
    DateTime: "2026:02:13 22:45:37"
    name: "subimage00"
    PixelAspectRatio: 1
    screenWindowCenter: 0, 0
    screenWindowWidth: 1
    Software: "OpenImageIO 3.1.10.0 : A46004A73559108546657EE91C1B400B8752E5D3"
    oiio:ColorSpace: "lin_rec709"
    oiio:subimagename: "subimage00"
    oiio:subimages: 3
    openexr:chunkCount: 1080
    openexr:lineOrder: "increasingY"

where we can see the second subimage have it's only channel still encoded in half

Details

I'm not sure if this is an issue on my side where I missed an argument configuration in the given test command or an actual problem. I tried to have a quick look at the code and I noticed that

OpenImageIO/src/oiiotool/oiiotool.cpp

Line 1120 in bf7bc9c

set_dataformat(Oiiotool& ot, cspan<const char*> argv)

doesn't have any logic related to subimages, while it seems to had in the past (based on git blame). But I'm not familiar with c++, neither oiiotool codebase so I may be missing on some extra logic.

Thanks,
Liam.

[lgritz]

Thanks, there is some kind of oversight there that prevented -d <subimagename.* from working properly. Proposed fix in #5048.

As an aside, there was also a mistake in your example command line: You said -d subimage01.*, but there is no such subimage (at that point). You should name the subimage before you refer to it by name. My patch in #5048 actually will allow this to work (since it perhaps is a common mistake), but in general, the subimages don't have names until you give them, or until you write it to an exr file (because OpenEXR requires it).

[MrLixm]

fantastic thanks a lot !