Not all possible uses of OIIO that might trip people up with the SHA are from running oiiotool. I wanted to catch as many possible cases as I could.

IBA functions are presumed to be changing the pixels, otherwise why would you call it? So I erase the SHA in the function that every IBA uses to prep the destination. Note that all IBAs have a src and dst, it's only the dst where we're erasing the metadata. If you really didn't want this to happen, you can always re-copy the metadata from src to dst after doing the IBA operation.

(Side debate: should IBAPrep copy any metadata? I'm already punting, perhaps, by copying anything non-essential. It's possible for other metadata to be made out-of-date by whatever IBA operation is being performed, I suppose.)

Hmmm... I could move those lines adjusting the metadata to be inside the 'if' so that it ONLY happens in that clause where dst is previously uninitialized and it sets it up with a copy of the input spec. Yeah, I'm kind of liking that.  Also, I could make another bit or two in the 'prepflags' that determines if risky metadata is copied.