specialize imrotate for 0, 90, 180, 270 degrees#79
specialize imrotate for 0, 90, 180, 270 degrees#79johnnychen94 wants to merge 4 commits intoJuliaImages:masterfrom johnnychen94:jc/rotate
Conversation
Codecov Report
@@ Coverage Diff @@
## master #79 +/- ##
==========================================
+ Coverage 88.56% 89.12% +0.56%
==========================================
Files 7 7
Lines 271 285 +14
==========================================
+ Hits 240 254 +14
Misses 31 31
Continue to review full report at Codecov.
|
|
I believe this PR is ready for review and merge |
|
is it type stable? was it before this PR? |
timholy
left a comment
There was a problem hiding this comment.
This looks good except for concerns about non-inferrability. I suppose an alternative would be to write specialized functions (rotate90, rotate180, rotate270) for specific rotations.
| @test_nowarn imrotate(img, π/4, axes(img)) | ||
| @test_nowarn imrotate(img, π/4, axes(img), Constant()) | ||
| @test isequal(channelview(imrotate(img,π/4)), channelview(imrotate(img, π/4, Linear()))) # TODO: if we remove channelview the test will break for Float | ||
| @test isequal(channelview(imrotate(img, π/4)), channelview(imrotate(img, π/4, Linear()))) # NaN != NaN |
There was a problem hiding this comment.
The meaning of this comment is unclear. Do you mean that you wanted to write == but instead have to use isequal?
|
Thanks for the comment, I'm already aware of the type stability issue, I'll come back and try to fix that later when I finished the upgrading of Augmentor.jl made by @Evizero (for my own research interest) |
|
BTW, 360 ° seems to be missing. |
| # 2. typemax(Int16) is 32767, we choose 32760 to make sure the | ||
| # discretization result of pi/2 is exactly pi/2 (or 90°) | ||
| max_num_angles = 32760 |
There was a problem hiding this comment.
Although the same goes for the current code, why don't you use 32768?
There was a problem hiding this comment.
Well... It's like I randomly chose the first number I found that meets the requirement, and I feel this choice doesn't matter for image processing tasks.
| θ = round(Int, 180*floor(mod(θ, 2pi)/pi*max_num_angles)/max_num_angles) | ||
| tform = recenter(RotMatrix{2}(θ/180*pi), center(img)) |
| elseif θ == 90 | ||
| idx = StepRange.(axes(img)) | ||
| perm_img = PermutedDimsArray(img, (2, 1)) | ||
| return view(perm_img, idx[2], reverse(idx[1])) | ||
| elseif θ == 180 | ||
| idx = map(i->1:1:length(i), axes(img)) | ||
| return view(img, reverse(idx[1]), reverse(idx[2])) | ||
| elseif θ == 270 | ||
| idx = StepRange.(axes(img)) | ||
| perm_img = PermutedDimsArray(img, (2, 1)) | ||
| return view(perm_img, reverse(idx[2]), idx[1]) |
There was a problem hiding this comment.
any reason to not use some of the tools in base?
https://docs.julialang.org/en/v1/base/arrays/#Base.rot180
https://docs.julialang.org/en/v1/base/arrays/#Base.rotl90
https://docs.julialang.org/en/v1/base/arrays/#Base.rotr90
There was a problem hiding this comment.
I don't think @johnnychen94 want to reallocate the memory and relocate the elements.:smile:
There was a problem hiding this comment.
True, and there won't be type stability issues if we collect them and return an Array; but that would be slower than views.
I don't have a good fix in mind for this at the moment.
|
BTW, I think it is better to round the rotation matrix instead of quantizing the angle. |
|
That sounds promising to me! |
|
It seems a bit dangerous to specialize on an approximation for an irrational number. Maybe it would be better to have a degree based version of Otherwise, I would really appreciate something like this. It's absence was duly noted when attempting something AoC2020 Day 20: https://adventofcode.com/2020/day/20 |
|
|
|
I'll let @johnnychen94 decide what to do here, but I put all the tests from this PR into #149 and they pass. |
Uh oh!
There was an error while loading. Please reload this page.