copying channels into multipart exr without metadata

[noidea-man]

I'm trying to use oiiotool to convert some exr1 images into exr2.0 multipart images. My command line arguments look like this currently:
.\oiiotool.exe input.exr --ch R=R,B=B,G=G,A=A -attrib oiio:subimagename rgba --ch B=aov1.B,R=aov1.R,G=aov1.G -attrib oiio:subimagename aov1 input.exr --ch B=aov2.B,R=aov2.R,G=aov2.G -attrib oiio:subimagename aov2 --siappendall -o output.exr

This works well, the resulting image has all of the expected subimages named the way I want, the problem is that it's also copying the input image's metadata completely into every subimage. These are renders coming out of Arnold, so they have a fair amount of metadata by default. I have 30 or so subimages and when I run --info -v -a on it to inspect, it scrolls for minutes and the resulting image sequence will bog down Nuke to a full stop.
Interestingly enough, using openExr's exrmultipart.exe to convert the images has the same result (although somehow even more bloated). Maybe this is expected behavior with multipart files?

I can't seem to figure out how to specify what subimages get metadata and which don't. I want it on the main rgba channels ,but not on any of the subimages. What am I missing?

[noidea-man]

Nevermind! adding --eraseattrib ".*" after every subimage did the trick.
It would be nice if there was a way to not attach "Software" and "Exif:ImageHistory" metadata to each subimage, however. With such a large number of subimages, those strings are crazy long and not terribly useful.

[lgritz]

I understand, you have a good point about that. There is a tension, however, between wanting those to not be repeated in every subimage, but also to preserve the correct history. It's worth noting that the very command you are describing -- merging separate images into a multi-part exr -- is one where those parts may well come to you with different histories.

I think explicitly erasing the attrbs is probably the right approach in this case.

[noidea-man]

That's a very good point I hadn't thought of and I can absolutely see the need for it now. Ultimately, despite their length in my use case those 2 attributes don't really add such a significant amount of bloat that I am too concerned.
I wouldn't mind a flag that forces the subimages to only retain the bare minimum metadata for format compliance or something like that, but after spending the past day with this I don't think it's necessary.

Thanks for the reply!