Hi, I used the dataset and code you provided to make adversarial examples. Running the program, the correct rate of the adversarial samples is 100% (q=100), but the adversarial examples are sent back to the network for classification, and half of the adversarial examples do not change the original correct classification results.I don't know if you or anyone else has this problem.

Hi, thanks for your work. It is very interesting. But I have a question about mathmatical definition of DCT in your paper: What are the meanings of parameters ‘u, v, k, m’ in the formula? Looking forward to your reply, thanks!!!

Hi @RjDuan Thank you for your work.

While creating components in following code, RGB channels of the images are being treated as YCbCr channels. If this observation is correct, could you please let me the reason behind re-naming RGB channels to YCbCr channels. Or someone should actually convert an image from RGB to YCbCr color space. https://github.com/RjDuan/AdvDrop/blob/35ceeb0e1c4b258bf3995302fbce9f13b39860f0/infod_sample.py#L72

Thank you.

After I ran python infod_sample.py, it ran normally in the beginning. However, there occurred this error when iter is 48:

Step:  100   Loss:  7.811537265777588   Current Suc rate:  0.2
Step:  110   Loss:  7.403205871582031   Current Suc rate:  0.2
Step:  120   Loss:  7.0217485427856445   Current Suc rate:  0.2
Step:  130   Loss:  6.647172451019287   Current Suc rate:  0.2
Step:  140   Loss:  6.154144763946533   Current Suc rate:  0.25
Current suc. rate:  0.303125
Iter:  48
Traceback (most recent call last):
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/PIL/I                          mageFile.py", line 237, in load
    s = read(self.decodermaxblock)
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/PIL/P                          ngImagePlugin.py", line 896, in load_read
    cid, pos, length = self.png.read()
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/PIL/P                          ngImagePlugin.py", line 162, in read
    length = i32(s)
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/PIL/_                          binary.py", line 75, in i32be
    return unpack_from(">I", c, o)[0]
struct.error: unpack_from requires a buffer of at least 4 bytes for unpacking                           4 bytes at offset 0 (actual buffer size is 0)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "infod_sample.py", line 191, in <module>
    images, labels = normal_iter.next()
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/torch                          /utils/data/dataloader.py", line 435, in __next__
    data = self._next_data()
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/torch                          /utils/data/dataloader.py", line 475, in _next_data
    data = self._dataset_fetcher.fetch(index)  # may raise StopIteration
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/torch                          /utils/data/_utils/fetch.py", line 44, in fetch
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/torch                          /utils/data/_utils/fetch.py", line 44, in <listcomp>
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/torch                          vision/datasets/folder.py", line 151, in __getitem__
    sample = self.loader(path)
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/torch                          vision/datasets/folder.py", line 188, in default_loader
    return pil_loader(path)
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/torch                          vision/datasets/folder.py", line 170, in pil_loader
    return img.convert('RGB')
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/PIL/I                          mage.py", line 904, in convert
    self.load()
  File "/home/miniconda3/envs/pytorch17/lib/python3.8/site-packages/PIL/I                          mageFile.py", line 243, in load
    raise OSError("image file is truncated") from e
OSError: image file is truncated

Can anyone help me?

Thanks a lot.

Hi, as you said in your paper (Section 3.4 Quantization) --- 'As the quantization table q should be integers during the optimization'. Do you think the data type of q table really affects the results? I mean what will happen if the elements in the q-table are float numbers. Thanks!

I downloaded the data set, ran the code, and encountered the following error： RuntimeError: The size of tensor a(7) must match the size of tensor b (20) at non-singleton dimension 2

An interesting work. A minor bug was found in the implementation of phi_diff which did not follow the equation 6 of original paper. phi_x = torch.tanh((x - (torch.floor(x) + 0.5)) * k) * s

Hi, I run your code and save the adversarial and original images. But I found that the size of adversarial image(such as 12.5KB) is bigger than original images(such as 12.4KB), is it reasonable？ Then I calculated the type of color of adversarial and original images， the adversarial image has more colors than original image. It seems violating the article.

Hi, thanks for your interesting work! I have two questions about the paper.

1. It seems that you borrow the pipeline of JPEG compressor, which aims to compress the image without much quality degradation. From your paper, AdvDrop applies DCT and other operations in 'RGB' space while JPEG does image compression on 'YCbCr' space. Am I right? If I am right, why do not you do information drop in 'YCbCr' space? what is the difference?
2. In your code, you use torch.floor( ) to process the quantized block which is inconsistent with the Figure 5. Do you think the torch.floor() should be replaced by torch.round() or have you tried torch.round() before?

Hi @RjDuan Thank you for excellent work. I have a question regarding initialization and update of Q-table.

(1) In paper, you have mentioned that Q-table is initialized with value of 1 and values are gradually increased during optimization (reference line: after Eq-1 in the paper).

However, in the code Q-table is being initialized with a user-provided value e.g. 40 https://github.com/RjDuan/AdvDrop/blob/35ceeb0e1c4b258bf3995302fbce9f13b39860f0/infod_sample.py#L52

(2) Eq-7 in the paper states that q is updated as follows: $\quad q^{'} = q + \text{sign}(\nabla_{q} \mathcal{L}(x^{'},y))\quad \text{s.t.}\quad||q^{'}-q_{\text{init}}||_{\infty} < \epsilon$

Could you explain if Eq-7 corresponds correctly to the relevant part of the code: https://github.com/RjDuan/AdvDrop/blob/35ceeb0e1c4b258bf3995302fbce9f13b39860f0/infod_sample.py#L108-L110

I have noted following perceived inconsistencies: a) Negative sign is being used in the update of q-table in code, while Eq-7 uses + sign. b) Eq-7 with $\ell_{\infty}$ norm suggests that maximum allowable difference in q-table is $\epsilon$ or $\mathrm{q_size}$ i.e. $\mathrm{max}(q^{'}-\mathrm{q_size}) \le \epsilon$, however, code part just keeps each entry of updated q-table in the range of [5, q_size] i.e. $\quad 5 \le q^{'} \le \mathrm{q_size}$

Could you help me clear the above mentioned confusions. Thank you!