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

about label/score normalization #7

Closed
ainnn opened this issue Aug 7, 2020 · 5 comments
Closed

about label/score normalization #7

ainnn opened this issue Aug 7, 2020 · 5 comments

Comments

@ainnn
Copy link

ainnn commented Aug 7, 2020

hey, thanks for your great work.
i viewed code and i found that there's no label normalization, e.g. normalizing scores to range [0, 1]. it's ok not to normalize when train and test on the same dataset or datasets with similar range.
in the paper, table 3 lists 3 datasets (livec, bid and knoiq) which have different score ranges. is it reasonable to use raw scores? or maybe you have normalized scores?
look forward to your reply.

@ainnn
Copy link
Author

ainnn commented Aug 7, 2020

also, i find that the target network contains 5 fc layers in the code, while 4 fc layers claimed in the paper.

@SSL92
Copy link
Owner

SSL92 commented Aug 8, 2020

Actually, we didn't do this normalization in cross database evaluation. This is because the final criterion SRCC calculates only the correlation ratio between two vectors and thus has no relationship with vector scale.
However, it seems to be true that normalizing labels to the same scale in single database evaluation is more reasonable, since we use a fixed lr for training all databases, while it might be better to use different lr for training datasets with different label ranges.

@SSL92
Copy link
Owner

SSL92 commented Aug 8, 2020

Thanks for your kind remind, there indeed exists a little difference about fc numbers from the paper and our code. However, it seems using whether 4 or 5 fc layers doesn't affect the model performance much, this is probably due to the target net has already learned sufficient quality representation in several front layers. You can also change the fc numbers by your own to see if the performance changes accordingly.

@ainnn
Copy link
Author

ainnn commented Aug 10, 2020

Thanks for your reply.
i think it's important to normalize label to get consistent label distribution in cross database evaluation. as for using different lr for training different database, it does not matter because the gradient from L1 loss has nothing to do with the scale.
just a restatement of my ideas, and there's no need to answer. thanks for sharing such a great work.

@ainnn ainnn closed this as completed Aug 11, 2020
@SSL92
Copy link
Owner

SSL92 commented Aug 11, 2020

Our pleasure ; )

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

2 participants