WIP: reduced precision for lanczos_opencv#635
WIP: reduced precision for lanczos_opencv#635bjarthur wants to merge 4 commits intoJuliaMath:masterfrom
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.