Refactor hflip, vflip functions to allow preallocation

[emilmgeorge]

For #103

[emilmgeorge]

Fixed formatting.

[emilmgeorge]

I benchmarked horizontal_flip with the following code variations:

1. par_par_slicecopy => Row: parallel Iter -- Column: Parallel Iter -- Channel: SliceCopy
2. par_loop_loop => Row: parallel Iter -- Column: HalfLoop -- Channel: Loop
3. par_loop_slicecopy => Row: parallel Iter -- Column: HalfLoop -- Channel: SliceCopy
4. par_seq_slicecopy => Row: parallel Iter -- Column: Normal (Sequential) Iter -- Channel: SliceCopy
5. kornia => (The first code in this PR with the full loop) Row: parallel Iter -- Column: FullLoop -- Channel: Loop

The general trend is that (4) usually comes out on top, followed closely by (3), and then (2), (5) and (1) at the last. In case of larger images (1024x896), the difference between the (4), (3) and (2) is usually small and inconsistent between runs.

Criterion.rs Line chart (open in new tab if in dark mode):

The average time value from the last 1024x896 run are:
(1) 1.3298 ms
(2) 1.2114 ms
(3) 1.2118 ms
(4) 1.2062 ms
(5) 1.2484 ms

Here's the full report generated by criterion:
criterion.zip

Please let me know your thoughts on this or if you have any other ideas to compare.

[edgarriba]

let's keep par_seq_slicecopyas it uses iterators and speed perf seems reasonable ?

[emilmgeorge]

Done.

[edgarriba]

Merging this, actually would be great as a post pr, to verify against known libraries like image-rs

[emilmgeorge]

I tried including image_rs in the benchmark (similar to how it is in bench_resize.rs), but my PC (16GB RAM) does not have enough memory for the full test. It gets terminated by the linux OOM killer before the 1024x896 test. The resize benchmark also crashes midway on my PC.

For 256x224 and 512x448, image-rs performs much worse (eg. 1.0548 ms for image_rs vs 161.53 us for par_seq_slicecopy).

For ref, here's the patch (Let me know if you want me to include it in this PR):
0001-Add-image_rs-to-the-flip-benchmark.patch.txt