You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for your code! I have been very interested in one aspect in particular. Many papers' code implementations (including SwinIR, HAT, DAT, and more recently, SPAN) make use of the rgb_mean code that is commented out here.
I have noticed that doing the same with the SPAN code implementation code greatly increases training stability, but breaks compatibility due to its interaction with the network features.
I was wondering if you could explain why you've chosen not to include it in your implementation, and what pros and cons you know of when using it?
Kind regards,
terrainer
The text was updated successfully, but these errors were encountered:
terrainer
changed the title
Signifigance of rgb_mean
Significance of rgb_mean
Jan 26, 2024
Thank you for your code! I have been very interested in one aspect in particular. Many papers' code implementations (including SwinIR, HAT, DAT, and more recently, SPAN) make use of the rgb_mean code that is commented out here. I have noticed that doing the same with the SPAN code implementation code greatly increases training stability, but breaks compatibility due to its interaction with the network features.
I was wondering if you could explain why you've chosen not to include it in your implementation, and what pros and cons you know of when using it?
Kind regards, terrainer
Hi. As far as I know, this operation is used to boost the performance on specific training dataset, such as DIV2K. As I train TTST on remote sensing datasets, therefore I comment this operation.
Hi,
Thank you for your code! I have been very interested in one aspect in particular. Many papers' code implementations (including SwinIR, HAT, DAT, and more recently, SPAN) make use of the rgb_mean code that is commented out here.
I have noticed that doing the same with the SPAN code implementation code greatly increases training stability, but breaks compatibility due to its interaction with the network features.
I was wondering if you could explain why you've chosen not to include it in your implementation, and what pros and cons you know of when using it?
Kind regards,
terrainer
The text was updated successfully, but these errors were encountered: