[WIP]Add flow evaluation functions#19
Conversation
|
@zygmuntszpak, I was searching for the standard methods for evaluations, I found out this. My doubt is : Is it a convention to use .flo file, in a standard widely accepted format(as in here), to store the ground truth flow vector or a user may directly pass the ground truth flow vector? Because I am not able to read from these .flo file in Julia. I also referred to OpenCV contrib repository for some idea, they also end up using the .flo file for ground truth flow in the above specified format. So, I also tried to read these .flo file in Julia but couldn't, however in C++ I could. I am still trying to successfully read the .flo files, once it's done will add a commit for the reading function. |
Codecov Report
@@ Coverage Diff @@
## master #19 +/- ##
==========================================
- Coverage 64.8% 61.62% -3.18%
==========================================
Files 7 7
Lines 375 443 +68
==========================================
+ Hits 243 273 +30
- Misses 132 170 +38
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #19 +/- ##
==========================================
- Coverage 64.8% 62.95% -1.85%
==========================================
Files 7 7
Lines 375 386 +11
==========================================
Hits 243 243
- Misses 132 143 +11
Continue to review full report at Codecov.
|
|
@zygmuntszpak I have put the error evaluation functions in the same |
I reckon you can put it in With regard to the ground truth, as far as I can tell we should allow the user to specify the ground truth flow as |
|
@zygmuntszpak I haven't added the test function yet. Once, I am able to parse the .flo files I will add the test. |
|
The last commit adds following :
I have changed the name of evaluate_error function to evaluate_flow_error because there is an identically named function under @zygmuntszpak please review and suggest changes. |
|
I'm really sorry for being so late! I was drafting my GSoC proposal. |
|
I wonder if we shouldn't define an |
|
@zygmuntszpak done |
zygmuntszpak
left a comment
There was a problem hiding this comment.
I had a moment to study the code more carefully and have a few more suggestions. After this, I think we can go ahead and merge. Thank you for your patience and effort.
|
Are the tests passing for you locally? I'm not sure why all of the builds have failed on Travis and Appveyor. |
|
Ok, can you confirm that the tests pass on your machine? If so, then I will go ahead and merge and then work on a separate pull-request to register this package etc. I just want us to be reasonably confident that we don't commit broken code to the master branch. |
|
Yes, the tests are passing on my local machine. |
| @@ -0,0 +1,21 @@ | |||
| [[Libdl]] | |||
There was a problem hiding this comment.
If I make it right, generally, we don't provide Manifest.toml in the repo
the old julia/CI system uses REQUIRE, but in most cases we still keep it to keep track of Project.toml
the new julia/CI system uses Project.toml
| @@ -0,0 +1,2 @@ | |||
| [deps] | |||
There was a problem hiding this comment.
The workflow to generate Project.toml is:
]generate ImageTracking- add packages required for this package
- add packages required in test stage
- there'll be
Project.tomlandManifest.tomlgenerated - create a
[extra]section, and move packages required by test stage only in[deps]section to this section - create a
[targets]section, and write in formatSTAGENAME = ["PKG1", "PKG2"], e.g.,test = ["Test"] - delete the
Manifest.tomland uploadProject.toml
see https://julialang.github.io/Pkg.jl/v1/creating-packages/ for more information
Added end point error evaluation function. Currently, the function evaluates error iff ground truth flow is also provided as an array.