Hi, Lydia, can you please fix the formatting? If you look at the CI clang-format run (look for the red and green highlights) you can see it's just a few lines that you could easily fix by hand if you don't have clang-format set up to run locally.
https://github.com/AcademySoftwareFoundation/OpenImageIO/actions/runs/15058621627/job/42329426760?pr=4763
(I hope that links shows you what it shows me)

Hi, Lydia, can you please fix the formatting? If you look at the CI clang-format run (look for the red and green highlights) you can see it's just a few lines that you could easily fix by hand if you don't have clang-format set up to run locally. https://github.com/AcademySoftwareFoundation/OpenImageIO/actions/runs/15058621627/job/42329426760?pr=4763 (I hope that links shows you what it shows me)

Yes Larry! Already working on a clang-format fix right now!

What I'm more worried about is the bleeding edge gcc14 test that failed? Digging into the log seems to imply that there are pixel differences from a test field that's completely untouched...

The "bleeding edge" failure is unrelated. I just submitted a fix here: #4765

Taking a look at incorporating all the comments after redo-ing the format fix!

Because Lydia and I had talked about this offline, I want to fill in a bit of the motivation here for others who are reading:

It's common in a studio to have tools insert all sorts of metadata into files as they're rendered, etc. But a lot of that are things that SHOULD NOT leave the facility -- like security issues from internal pathnames or network info, or secrets like plot details revealed by sequence or character names. So generally you want to scrub the metadata from the final images before they are shipped to the client or to marketing or whatever.

oiiotool's --eraseattrib is handy for this, but it takes a single regex. But we were thinking that:

1. You may have several patterns to fully describe the metadata you want to be sure not to ship. This could be an unwieldy regex or a cluttered series of multiple --eraseattrib commands.
2. That list of patterns may change over time, and it would be error prone to have to change it in every script that calls oiiotool.
3. That list of patterns may need to be different per show.

We thought a solution to facilitate this might be a version of --eraseattrib that takes a filename that contains a list of regexes, one per line of the text file. So that master list of things to scrub could be maintained in a central place and not need to update every oiiotool-calling script in order to update it. Furthermore, you could have the command say something like

$ oiiotool ready_to_ship.exr --eraseattrib_fromfile /blah/$SHOW/nometadata.txt -o clean.exr

to make a single command that allows per-show customization.

Question for onlookers: Lydia implemented this as a new command, --eraseattrib_fromfile.

An alternate design we discussed was just using the existing command but with a new optional modifier: --eraseattrib:fromfile=1 that causes the subsequent argument to be interpreted as the name of a file containing the regexes, instead of as a regex itself.

Does anybody have a strong preference? Or any other feedback on the basic design?

It's really close. I pointed out one line that is no longer needed.

I'd like to hold this in review for a few days, simply for the sake of allowing others the chance to comment on design of the feature.

Also, before merging, we really should make sure that the documentation mentions this feature.

Sounds good Larry, I was checking the tests and it might have updated the branch to merge, feel free to cancel/ ignore.

Adding a list of todos since there’s a chance that I might not be able to work on this soon:

• remove unneeded line from get_regex_list_from_file
• add documentation for eraseattrib_fromfile
• pending feedback for design

Larry, in re: whether to have a separate command-line option to take the list from the file rather than an immediate argument: is there any precedent one way or the other with existing options, which might argue for consistency in the service of least surprise?

And yeah it's an important thing, I wrote something once (as a shell script, so no one could accuse it of harboring a trojan) to strip out all sorts of stuff from the output of an exrheader command. One doesn't want a camera "notes" field that says "Quicksilver doesn't die in this take" to leak. Even with those precautions though producers wouldn't allow my contact to use it. Maybe they figured that someone could deduce a plot point from the difference between the display and data windows.

Thanks for the feedback, Joseph.

I don't believe that oiiotool has any other commands at the moment that read arguments from files. But maybe it will in the future, so I agree that we want to think carefully about what we establish as the precedent.

Are there other utilities (outside of oiio) that have similar functionality? Ah, the one that popped into my mind for some reason is "rsync", and its man page includes:

            --exclude=PATTERN       exclude files matching PATTERN
            --exclude-from=FILE     read exclude patterns from FILE
            --include=PATTERN       don't exclude files matching PATTERN
            --include-from=FILE     read include patterns from FILE
            --files-from=FILE       read list of source-file names from FILE

And I checked tar (the modern gnu version), which has:

     -T filename, --files-from filename
             In x or t mode, tar will read the list of names to be extracted
             from filename.  In c mode, tar will read names to be archived
             from filename.

So they are using separate commands, and seem to follow a common "--foo-from filename" pattern.

But they don't the kind of "optional command modifiers" that we do, so maybe they didn't consider that part of the design space?

    # Existing command:
    oiiotool ... --eraseattrib pattern ...

    # Design 1: new command
    oiiotool ... --eraseattrib-from filename-containing-patterns ...

    # Design 2: optional modifier
    oiiotool ... --eraseattrib:fromfile=1 filename-containing-patterns ...

I'm mildly preferring the second option, simply because if someday we have many commands we want to operate like this, we don't have to make a completely new command for each instance. We can just make more commands use the same "fromfile" optional modifier. Use of optional modifiers in this way is already a very common oiiotool idioms that users expect.

That's my current thought, anyway. If everybody strongly prefers Design 1, I won't object.

I'm mildly preferring the second option, simply because if someday we have many commands we want to operate like this, we don't have to make a completely new command for each instance. We can just make more commands use the same "fromfile" optional modifier. Use of optional modifiers in this way is already a very common oiiotool idioms that users expect.

I personally prefer the second option as well, for exactly the reasons you've alluded to:

1. Scales better with the (already large) number of oiiotool options.
2. Consistent with prior art for command modifiers.

Your docs are great, thanks.

To do:

• One very minor suggestions about how to do the string comparison on the command name (I made the suggestion via diffs, if you're ok with that, you can just click to accept the change)
• I would like you to back out the unintended whitespace changes in the docs. There's no reason to touch so many lines in this file.
• Let's sit on this until early next week to give people a little more time to think about the design choice and weigh in if they have a preference.

Amazing how far behind one can get on an issue by taking just a single day off. But: I wanted to say I really like design #2, as well.

Lydia, this looks great now, the stray whitespace changes are definitely cleaned up.

It feel like consensus is leaning toward Design 2. We'll discuss in today's TSC meeting, but I suspect that is the way we'd rather go.

Looks great!

I made a couple very minor suggestions about documentation wording and formatting. The diffs should allow you to click to accept them without needing to re-edit and push (assuming you agree with my suggestions).

Hi Larry! Those all looked good, I've accepted the documentation wording updates, cheers.

Sweet! Thanks for the double checking, and for everyone's input on the design of the feature!