-
Notifications
You must be signed in to change notification settings - Fork 112
WIP: reduced precision for lanczos_opencv #635
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #635 +/- ##
==========================================
- Coverage 88.10% 88.01% -0.10%
==========================================
Files 29 29
Lines 1908 1910 +2
==========================================
Hits 1681 1681
- Misses 227 229 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
second commit makes it slightly faster: |
|
the output is qualitatively different for Float32 compared to Float64. :( specifically, when i don't know enough about lanczos resampling to fix this in the right way. what i do know though is that this is not a problem if opencv's lanczos implementation is followed more closely (see the last commit of this PR). specifically, so i'm putting this on the back burner for now. below is the output without the last commit. |
using Float32 for Lanczos is ~2x faster and uses ~1/2x as much memory as the current Float64.
this PR currently uses whatever precision was input as the precision the internal calculations are performed with. i could also imagine specifying the type used for internal computations in the type (e.g.
struct Lanczos4OpenCV{T} <: AbstractLanczos end) to separate it from the input.i'm also curious where there is a more clever way to cast
l4_2d_csat compile time so as not to incur runtime penalities.let me know what you think and i'll add some tests and docs.