LabVIEW
Interpolate Pixel
@Andrey_Dmitriev wrote:
wiebe@CARYA wrote:
Well, that's not fair if you don't show the code 😉.
Unfortunately you didn't read my message thoroughly — the link was provided:
Re: Strange deviations of the intensities with IMAQ Flat Field Correction VI.
Also attached to this message (sorry for off-topic) and this time downgraded to LV2018 (but 64-bit only), full C code inside.
OK, didn't make that connection.
But the zip shows IMAQ vs DLL, not plain LV code...? I thought we where comparing LV vs C here?
Your "Flat Field Image - Prepare.vi" call steals CPU from the IMAQ benchmark, as it runs in parallel of the benchmark.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
EDIT: Not sure if you want to get 1 interpolated value from a pixel map, or interpolate the entire image. If it's the entire image, read on.
For larger images, you can use 2D FFT to resize (interpolate or decimate).
The trick there is that the amplitude needs to be adjusted by the resize factor.
I think this might be faster, but only at some point. The interpolation will be different, definitely not linear. Maybe better, maybe worse.
Another benefit is you can resize with any factor. After all, interpolating between pixels doesn't result in 2X the width\height. It actually resizes each dimension with (x-1)*2+1...
I'd have to dig if you're interested.
Here's what I have:
Guess as it is, it only grows the size.
If you don't have doubles as input, you'll loose a lot of the gain.
wiebe@CARYA wrote:
But the zip shows IMAQ vs DLL, not plain LV code...? I thought we where comparing LV vs C here?
Your "Flat Field Image - Prepare.vi" call steals CPU from the IMAQ benchmark, as it runs in parallel of the benchmark.
Oh, good catch, you're perfectly right! On the other hand, this Flat Field Image - Prepare takes just a few milliseconds (3-5 maybe on my PC), so it doesn't affect the overall results much, maybe just a few percent. I just overseen this small issue, sorry about that.
I feel myself slightly uncomfortable to bother everyone with non 2D Interpolation-related things, but anyway, in general, we're comparing different methods that lead to exactly the same functionality, but if you need to compare LabVIEW vs. C - why not? In the attachment — more or less correct comparison (if I've missed something, please don't hesitate to correct me). I increased the image size to 8192x8192 pixels to avoid the for-loop in the benchmark.
And it's still three times faster than LabVIEW:
And here is not so much room left to improve:
We can do this parallel, but in C - as well, so the overall ratio will remain (as long as memory's throughput will allow). Again, its not an advertising to rewrite everything in C, or ultimate statement "C is faster!", no, no, no at all, but in some cases you can win.
Andrey.
PS
And please take a note, I haven't used FMA (Fused Multiply–Add) Instruction Set here, which could improve C code a little bit 😉
@altenbach wrote:
Looks loosely based on this old code. I doubt you would need that much orange. I'll try a few things.
I actually didn't base it on anything.
Also that code has a bug: It assumes that 
@paul_a_cardinale wrote:
@altenbach wrote:
Looks loosely based on this old code. I doubt you would need that much orange. I'll try a few things.
I actually didn't base it on anything.
Also that code has a bug: It assumes that
rounds down; but it really rounds to nearest.
Nearest-neighbor interpolation is still interpolation 😁.
Faster Too!
Replacing the detour via DBL multiplication with a LUT approach, gives me about 3-7x speedup over the original code.
(Since the LUT is quantized to U8 values, it does not really need to be very big)
I'll attach some code later.
For example, the following 8x expansion takes about 100microseconds on my laptop (same result as yours). I am sure there is some slack left:
The LUT cosntant is created as follows:
wiebe@CARYA wrote:
@paul_a_cardinale wrote:
@altenbach wrote:
Looks loosely based on this old code. I doubt you would need that much orange. I'll try a few things.
I actually didn't base it on anything.
Also that code has a bug: It assumes that
Nearest-neighbor interpolation is still interpolation 😁.
Faster Too!
That was my starting point. I wanted something more accurate.
To be extra fancy, it should take into account gamma (that would probably slow it down to a crawl).
@paul_a_cardinale wrote:
Also that code has a bug: It assumes that toI32 rounds down; but it really rounds to nearest.
My old code only convert to I32 after rounding to -Inf. No bug.
@paul_a_cardinale wrote:
To be extra fancy, it should take into account gamma (that would probably slow it down to a crawl).
In my code, all you probably need is a nonlinear LUT to take gamma into account, but I have not tried that.
