Make compatible for 1 channel only & Update frames handling #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… with using just one channel
… Added progress bars for both parallel (in verbose mode) and non-parallel processing.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
see line numbers in old code:
apply_motion_field()
Line 65: simplified expression
In general, we might have to rework how this function deals with "frames" because it includes inherent assumptions.
The way this function is used right now is fine (only in motion_compensate()), but I tried using it outside of ofco and it does not do what would be expected if you want to only apply it to range of frames that does not start from frame 0
I will create an issue on that.
motion_compensate()
line 99&103: made it compatible to use with one channel only, e.g. for when I was recording the green channel only.
Additionally, I cleaned up how "frames" is is used here, because it was a bit confusing. In line 98, frames was already applied to the stack, so after that the variable frames should really just be range(len(stack1)). When adding a reference frame to the beginning of the stack, it should be that as well.
It was not a problem for most cases before, because the code was mostly using len(frames) and not accessing individual values, but it is cleaner this way, I think.
line 120: this did not work in case no external reference frame was supplied and frames does not start with 0
line 130: I included the option to use pool.imap() together with a progress bar. Since it takes so long, I really wanted to know how far in I am. If you think this is a good solution, we might as well use not only in the verbose mode.
The speed is comparable.
line 138: added progress bar to non-parallel mode.
line 163: not sure why this shows up as a change, because you had adapted this earlier
line 165: adapt to using one channel only