Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Features as functions #400
This PR removes
@imgfeature def feature_written_for_menpo_image(image): # image will always be a Menpo Image # must return a Menpo Image. @ndfeature def feature_writen_for_ndarray(pixels): # pixels will always be a ndarray of pixels # must return an ndarray of pixels @winitfeature def feature_that_uses_menpos_windowiterator(pixels): # pixels will always be an ndarray. # I have to return the feature ndarray and the centres # from window iterator. This will be used for # correcting masks and landmarks.
The decorators ensure that each of these feature functions can be used in a consistent manor - if you provide a
A nice consequence of this design is that any features we expose from Cyvlfeat can be instantly made usable in the fit framework by simply adding the
This part of the work is fairly small, but it has some large consequences for the fitmultilevel module. Currently there is a lot of machinery in fitmulitlevel that deals with checking and applying features. This is massively simplified in this PR, but it does mean a fairly large change set, so we will need to be vigilant for problems.
This PR is not yet ready, but I need to give something at GOSH my attention for a few days so I thought I would put it up so that people can start reviewing. I've listed what I think needs doing at the end of the PR, and will work through these in the next few days.
Hit me with any questions!
With the above, we have a slight problem - before constrain_landmarks_to_bounds was being implicitly called every time we computed features - now we want to make it explicit. The open question is - should we compute this every time? If so, we should probably make a small wrapper function in fit multilevel that just calls the feature on the image, then constrain landmarks to bounds. This should probably be done in the check features function (after we are happy we have good functions for features, wrap each in the function in a list comprehension and we are done).
added a commit
this pull request
Sep 1, 2014
Sep 1, 2014
1 check passed
The difference in the test is due to a difference in behaviour between this PR and master when it comes to applying a no operation feature in the fit framework.
Historically, landmarks were made to be constrained to bounds after the application of a feature. If the feature was
The new approach on this PR always constrains at the point of feature application, whether the feature is none (