Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does anyone have problems in training from scratch with GCNet on ImageNet? #10

Open
implus opened this issue May 16, 2019 · 17 comments
Open

Comments

@implus
Copy link

implus commented May 16, 2019

Using the best setting of GC-ResNet50 and train it from scratch on ImageNet, I found it will be stuck in a high loss in the early epochs before the training loss begins to decline normally. Therefore the final result is much lower than original ResNet50. Note that one difference from the original paper is that the GC modules are embedded in each bottleneck exactly as SE does, for a fair comparison.

Does anyone have the same problem?

This may be the case since the authors report the ImageNet results via a finetuning setting, which is not very common when validating models on ImageNet Benchmarks. At least all other modules (SE, SK, BAM, CBAM, AA) are following a training-from-scratch setting.

@lxtGH
Copy link

lxtGH commented May 19, 2019

Did you try to finetune the resnet?

@kfxw
Copy link

kfxw commented Jun 4, 2019

I have the similar problem. When training from scratch, the model converges very slowly.

@ZzzjzzZ
Copy link

ZzzjzzZ commented Jun 4, 2019

I have the similar problem. When training from scratch, the model converges very slowly.

Me too

@xvjiarui
Copy link
Owner

xvjiarui commented Jul 3, 2019

Sorry for the late reply.

At the first place, we don't have enough resources for training from scratch.
Afterwards, we tried train the whole network from scratch on ImageNet. We didn't observe similar issue. I suggested you train it for 110 or 120 epoch to see the finally performance.

Noted that we use the same augmentation method as SENet.

@kfxw
Copy link

kfxw commented Jul 3, 2019

@xvjiarui
Hi! In terms of the fusion setting, did the case you mentioned use the 'add' one or the 'scale' one?

@xvjiarui
Copy link
Owner

xvjiarui commented Jul 3, 2019

We use the 'add' one by default. On the other hand, 'scale' is similar to SENet. Both of them should not have converge issue.

@kfxw
Copy link

kfxw commented Jul 3, 2019

@xvjiarui
Thx for your reply. Btw, would you mind sharing the classification training codes in this repo? That would be of great help.

@xvjiarui
Copy link
Owner

xvjiarui commented Jul 3, 2019

@xvjiarui
Thx for your reply. Btw, would you mind sharing the classification training codes in this repo? That would be of great help.

Our internal code base is used for classification training. We may try to release a cleaned version in the future. But it is not on schedule yet.

The block structure is the same. You could simply add it to your own code.

@taoxinlily
Copy link

Using the best setting of GC-ResNet50 and train it from scratch on ImageNet, I found it will be stuck in a high loss in the early epochs before the training loss begins to decline normally. Therefore the final result is much lower than original ResNet50. Note that one difference from the original paper is that the GC modules are embedded in each bottleneck exactly as SE does, for a fair comparison.

Does anyone have the same problem?

This may be the case since the authors report the ImageNet results via a finetuning setting, which is not very common when validating models on ImageNet Benchmarks. At least all other modules (SE, SK, BAM, CBAM, AA) are following a training-from-scratch setting.

Hi! Did you solve the problem?

@Shiro-LK
Copy link

@xvjiarui
I am also trying to use gc block on classifier such as resnet, vgg16 etc and I would like to be sure that I am doing thing good.
First : in the resnet backbone, we just need to use the global context block before the downsample in the bottleneck/basicblock class
Second : for the global contexxt module, the inplane parameter is the depth of the feature map which will feed the gc module and the plane parameter is equal to inplane//16, is it right ?
regarding the parameter "pool", I suppose "att" is better ? And for the "fusions" parameter "channel add" is also better ? Why this parameter take only a list? I am not sure to understand.

@xvjiarui
Copy link
Owner

For all the yes/no questions, the answers are yes. You are understanding correctly.
The fusions as a list indicate that multiple fusion methods could be used together.

@ma-xu
Copy link

ma-xu commented Feb 28, 2020

For all the yes/no questions, the answers are yes. You are understanding correctly.
The fusions as a list indicate that multiple fusion methods could be used together.
@xvjiarui
Hi, thanks a lot for your great work. I appreciate it. However, I tried to train the network on ImageNet and GC achieves a worse performance than original ResNet. Then I follow the paper that fine-tune the ResNet50 for other 40 epochs using cosine schedule, and the performance is still bad. Could you please share you fine-tuning code, and I can cite your work in my research. Thanks a lot.

@Shiro-LK
Copy link

Shiro-LK commented Mar 5, 2020

@xvjiarui

Hi, Thanks for your reply.
Do you still have the model trained on imagenet with gcblock ?

@xvjiarui
Copy link
Owner

xvjiarui commented Mar 5, 2020

Hi, @13952522076
Sorry for the late reply.
Currently, I am too busy to release that part of the code.
If the issue is overfitting, you are suggested to adopt the augmentations in the original paper as well as the drop out on the gc block branch.

@xvjiarui
Copy link
Owner

xvjiarui commented Mar 5, 2020

Hi, @Shiro-LK
The models are not available for now. You will be informed when I train them again.

@ma-xu
Copy link

ma-xu commented Mar 5, 2020

Hi, @13952522076
Sorry for the late reply.
Currently, I am too busy to release that part of the code.
If the issue is overfitting, you are suggested to adopt the augmentations in the original paper as well as the drop out on the gc block branch.

Thanks a lot for your reply. Looks like not the issue of overfitting (train loss vs. val loss). Anyway, appreciate your work and it helped a lot. 😺

@atnegam
Copy link

atnegam commented May 31, 2022

@ma-xu Hello, excuse me, has the problem been solved?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants