Harry24k / adversarial-attacks-pytorch

PyTorch implementation of adversarial attacks [torchattacks].
https://adversarial-attacks-pytorch.readthedocs.io/en/latest/index.html
MIT License
1.79k stars 337 forks source link

[QUESTION] Why the input must have a range of [0, 1]? #145

Open youyinnn opened 1 year ago

youyinnn commented 1 year ago

❔ Any questions

Hi, thanks for the excellent work. I want to know where this constraint comes from.

https://github.com/Harry24k/adversarial-attacks-pytorch/blob/c4da6a95546283992a3d1816ae76a0cd4dfc2d8b/torchattacks/attack.py#L72

BrianPulfer commented 1 year ago

Hi all! I am also wondering the same. Many publicly available models are trained with some pre-processing of the input that puts the tensors in much wider ranges (e.g. [-3, 3]). It'd be nice to attack the model without making the pre-processing a part of the model itself (also pre-processings might not be differentiable).

rikonaka commented 1 year ago

Hi @youyinnn and @BrianPulfer , first, the doc of torchattacks already mentions that each input must be limited to [0, 1] (I know a lot of people don't like to read documents, me too 🤪). And, in version v1.2, almost 3 years ago, the author gave this mandatory limit description

https://github.com/Harry24k/adversarial-attacks-pytorch/blob/39d378c4aa833f3c0d3ea10f58ba0352e3145d3b/torchattacks/attacks/fgsm.py#L16

commit id: 39d378c4aa833f3c0d3ea10f58ba0352e3145d3b, but most people do not care about it.

Second, and also the most important one, this constraint is to avoid the user inputs the wrong data format, which leads to misleading experimental results, there are many issues asking why the success rate of PGD or other attacks cannot reach 100%, we then spent a lot of time reviewing the torchattacks code and communicating with the users, and eventually realized that the problem was that the users inputs were not typing what we wanted them to. So we restrict the input range directly in the code so that we can remind users to check whether their input meets the requirements.

Third, all code is implemented based on this precondition, and most pytorch-integrated datasets are also in this range, and finally, to standardize the output and input of all attacks, we cannot implement a set of algorithms for each and every range.

By the way, if your code worked good before but this error appeared after the recent update, your previous experimental results should be based on the wrong use on, it is likely that the experimental results is also wrong...

This error will not occur if you use torchattacks correctly from the beginning.

If you have a dataset that is not in this range, it is not difficult to process it. For example, [-3, 3] can be process simply as $(x+3)/6$.

image

The doc.

BrianPulfer commented 1 year ago

Hi @rikonaka,

Thank you for your reply.

I am aware that the input has to be in range [0, 1], my question was: why this is the case? In principle, adversarial attacks can be computed with any tensor. Are there any algorithms that make this assumption?

I fear that for pre-trained models, we can't assume that shifting and scaling the input tensor will result in the same output. For example, in my case: model(x) == model((x+3)/6) definitively doesn't hold. In fact, I think this wouldn't hold in most cases.

The easiest solution I see is trying to make the pre-processing steps part of the model for pre-trained models.

rikonaka commented 1 year ago

Ok @BrianPulfer , you are right, in principle, adversarial attacks can be computed with any tensor, but in practice we restrict this tensor to be between [0,1], this is based on the fact that the pytorch integrated dataset is also this range, which is derived from $D/255$, where $D$ is the original problem space (the value range of the pixel of the image is [0, 255]). This is just a prerequisite, you can also write your own attack algorithm on [-3,3], but it is essentially not much different from [0,1], for a library, we need a unified input and output.

For a pre-trained model, you can add a new conversion layer before and after the model to bring the model back to the [0,1] range, which is not difficult 😜.

answer