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

DLTK's implementation of DeepMedic underperforms original. #19

Open
Kamnitsask opened this issue Dec 10, 2017 · 2 comments
Open

DLTK's implementation of DeepMedic underperforms original. #19

Kamnitsask opened this issue Dec 10, 2017 · 2 comments
Assignees
Labels

Comments

@Kamnitsask
Copy link

Hello,

Let us note here to the users that DLTK's implementation of DeepMedic is significantly underperforming the original implementation (publicly available at link).

If users seek to evaluate performance of DeepMedic, eg to find the capabilities of the model, compare with other methods, etc, they must use the original version.

Please leave this issue open until the implementation of this version is brought on par with the original.

Thank you,
Konstantinos Kamnitsas

@mrajchl mrajchl self-assigned this Dec 13, 2017
@mrajchl mrajchl added the bug label Dec 13, 2017
@mrajchl
Copy link
Contributor

mrajchl commented Dec 13, 2017

Considering this implementation comes from our group, people might expect the same performance as the original code base. I've pushed a WARNING/Note comment at the top of dltk/models/segmentation/deepmedic with 61afd38 stating:

# WARNING/NOTE
# This implementation is work in progress and an attempt to implement a 
# scalable version of the original DeepMedic [1] source. It will NOT 
# yield the same accuracy performance as described in the paper.
# If you are running comparative experiments, please refer to the 
# original code base in [1].
#
# [1] https://github.com/Kamnitsask/deepmedic

If you want this highlighted better, let me know. Let's keep this thread open until this is resolved.

@Kamnitsask
Copy link
Author

Looks good Martin, thanks. Yes, with the other model implementations looking good on the DLTK paper, users could take for granted that this is polished as well. So lets leave it visible for now that this model has not been mirrored/transferred from the original.

I would leave the issue open for now, to avoid confusion of users. At least that's the approach I take with issues on my project (as "strong warnings" to users), not sure it's standard engineering practice though.

I'll try to make time to look into this myself in the future.

Cheers,
K

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

No branches or pull requests

2 participants