Skip to content
Snippets Groups Projects

WIP: Generic trainer

  • Adds a generic trainer class and trainer script
  • Moved the model specific stuff to config files; example config added
  • uses .to(device) throughout

Merge request reports

Pipeline #28997 failed

Pipeline failed for e4dce812 on generic_trainer

Approval is optional

Closed by Anjith GEORGEAnjith GEORGE Apr 18, 2019 (Apr 18, 2019 11:27am UTC)

Merge details

  • The changes were not merged into master.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • @heusch Can you take a look at the GenericTrainer class, many of the model specific stuff is moved to the config file. An example config file in config/generic/oulu_deep_pixbis.py Feedbacks & improvements are welcome.

  • Anjith GEORGE added 1 commit

    added 1 commit

    Compare with previous version

  • That's a good start, thanks.

    Two things I'm concerned about though, and were we should take special care in my opinion:

    1. Not sure that the load model function is generic enough (depending if the model was saved on CPU or GPU
    2. I'm also not fond of the dataset stuff as it is right now. Although the idea of linking that to bob's db interface is great, I'm not really satisified with its current implementation ...

    I'll probably start working on that (I mean, the whole package refactoring) as soon as I'm done with moving MCAE stuff back to the paper package.

    It may be a good thing to discuss on how we see this some time next week ! Anyway, thanks for setting things in motion ;)

    Edited by Guillaume HEUSCH
  • @heusch

    1. Currently, it's moved to CPU while saving (same as the previous trainers), and when you load it back it's loaded to cpu, which is moved .to(device) while training. I haven't tested all the use cases though.
    2. I think there should be an interface which can be usable with bobs db interfaces. I tried a generic loader which can accept a custom function to decide the format that we want to return from the dataset. I could use this stuff with 2-3 different architectures and with different databases just by changing the config file.
    1. I remembered having trouble with provided pre-trained models, I'll check the different use-cases
    2. Sure the interface is needed, and I'm not saying that the current approach is not good (I did not take the time to check it lately though), but I think it could be improved (based on my memories).
  • Anjith GEORGE added 1 commit

    added 1 commit

    • d0a4a73e - Extractor, more configs and fixes

    Compare with previous version

  • Guillaume HEUSCH mentioned in merge request !27 (merged)

    mentioned in merge request !27 (merged)

  • Anjith GEORGE added 2 commits

    added 2 commits

    Compare with previous version

Please register or sign in to reply
Loading