Make Projector batch aware

[dxoigmn]

What does this PR do?

The current Projector is not batch/tuple aware, which is necessary for attacks on datasets where input images have different shapes (e.g., COCO). This PR makes it so.

Type of change

Please check all relevant options.

• Improvement (non-breaking)
• Bug fix (non-breaking)
• New feature (non-breaking)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Testing

Please describe the tests that you ran to verify your changes. Consider listing any relevant details of your test configuration.

• make test

Before submitting

• The title is self-explanatory and the description concisely explains the PR
• My PR does only one thing, instead of bundling different changes together
• I list all the breaking changes introduced by this pull request
• I have commented my code
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have run pre-commit hooks with pre-commit run -a command without errors

Did you have fun?

Make sure you had fun coding 🙃

[mzweilin]

Do you have a plan for modality-aware?

[dxoigmn]

Nope.

[mzweilin]

Do you think it's better to make it a dictionary so that it's more easily configurable in Hydra? Like that in Enforcer:

MART/mart/attack/enforcer.py

Line 100 in 70e62d9

def __init__(self, constraints: dict[str, Constraint] | None = None) -> None:

[dxoigmn]

I think that should live in another PR.

[dxoigmn]

My read of the Projectors class is that they need a wholesale redesign because there's a lot of mixing of functionality instead of focusing on composition.

[mzweilin]

I have made a shared modality-batch-aware mechanism in #115 for Initializer, Projector and Composer.

[dxoigmn]

I have made a shared modality-batch-aware mechanism in #115 for Initializer, Projector and Composer.

Okay. Is the idea that this PR should be updated to use that? I also saw there was an opportunity to DRY the logic but wanted to wait until after we get everything merged. I'll try to read through what you wrote though.

[dxoigmn]

@mzweilin: I think it's better to merge this now than wait for the generic dispatch to be done since it updates the tests to conform to the existing interface.

[mzweilin]

LGTM