Add frame extractor for wildfire

[x0s]

This PR aims at importing the frame extraction into the repository used for training models.

Until now, Frame Extraction was mingled with annotation process. This PR improves encapsulation by modularizing the frame extraction. We will be able to choose different frame extraction strategy for training (not only annotating). This is important feature because we will build/train our models on top of what we show to them (the frames)

This is an ongoing PR. It is important to no have duplicate code, so I consider importing this new class into the other repository.

I provide some graphs illustrating the current workflow, the new one I suggest (big picture and isolated).

This PR does not primarily aim to change behaviour but when covering with tests, I discover an issue that should be fixed:

• Number of frames created can be lower than number registered in labels.csv See Commit

Isolated, it enables to change extraction strategy independently of the annotation process:

Here is an example how to use this new object:

    frame_extractor = FrameExtractor(path_to_wildfire,
                                     'jean_lulu_with_seq_01.states.csv',
                                     strategy='random',
                                     n_frames=2)

    labels = (frame_extractor.run(path_to_frames)
                             .get_frame_labels())

So far we use this naming convention:

• states.csv: a state is a subsequence of a video composed of frames with constant targets (fire presence, position, confidence and exploitability) : dim=(n_states)
• labels.csv: contains extracted frames with the corresponding targets: dim=(n_states x n_frames/state)

Todo list for this PR

• Isolate FrameExtractor (from states to labels+frames)
• Cover with test

Further work for VideoSplitter (to be postponed because the team is currently abundantly annotating)

• Refactor AnnotationParser
• Make AnnotationChecker output checkedStates in addition of checkedLabels

Any feedback is welcome,
Cheers,

---

Current workflow:

Suggested workflow:

[codecov]

Codecov Report

Merging #48 into master will increase coverage by 1.36%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #48      +/-   ##
==========================================
+ Coverage   83.80%   85.17%   +1.36%     
==========================================
  Files          18       19       +1     
  Lines         704      769      +65     
==========================================
+ Hits          590      655      +65     
  Misses        114      114              

Impacted Files	Coverage Δ
pyronear/datasets/wildfire/__init__.py	100.00% <100.00%> (ø)
pyronear/datasets/wildfire/frame_extractor.py	100.00% <100.00%> (ø)

[frgfm]

Thanks a lot for the PR! Very useful feature, only imports in the test to move to the header, some package requirements to make more flexible, and a fixture file that could be put in a gist.

Thanks again!

[x0s]

Thanks for adding a new feature, but I think that's beyond the scope of this PR. That would be better to create a new PR for it. You may be adding it because we are very slow in reviewing then merging it onto master. Anyway, I think we are close to merging it.

I provide you with feedback here:

• Please follow the PEP8 convention for variables
• Please follow the Type ints convention this PR is introducing (to increase stability of the code/ documentation: to answer for instance: what types this function is to expect ?)
• None is neither False nor True so if you want it to test if a variable contain None, it is better practice to test it explicitly: if variable is not None: / if variable is None:
• Please provide documentation in the dosctrings, this is lacking in run() and _write_frames()
• If you add a new feature, it is important to cover it with test cases. As you can see, adding this feature decreased covering of this PR One may expected to test for possibles values (None , differents sizes and some pathological cases: one dimension provided when 2 are expected for instance)
• Please provide a more detailed example illustrating when we need to speed up the code and why resizing would be a good solution.

Answering these could be done in another PRs i guess

[frgfm]

@MateoLostanlen could you take a look at @x0s comment on the frame_extractor please?

[frgfm]

All good!