Deconvolution algorithm #26
Conversation
We first extract some information from the image - width, height etc., convert to luma and compute gradients. Then, for each pixel (x,y), we compute rho = xcos(theta) + ysin(theta). After a few more transformations and finding the bins with highest values, we generate the resulting image.
Preliminary Hough transform implementation
It is used to improve contrast in images and works by performing enhancement on small 'contextual' regions or neighborhood of each pixel in the given image.
Adaptive Histogram Equalization
Laplacian filter
Fix the horizontal kernel of Sobel filter.
* Mean filter version 1
| import Prelude as P | ||
|
|
||
| -- | Supplementary function needed to blur an image and test the algorithm. | ||
| randomBlur :: Image VS X Double |
There was a problem hiding this comment.
Anything that is needed for testing, suppose to live in the test suite
There was a problem hiding this comment.
@lehins Okay sir, so this should be in the usage section in the documentation?
There was a problem hiding this comment.
Yes you could move it to function documentation as an example. In that case I'd also recommend collapsing the big example (note ====__Examples__):
-- ====__Examples__
--
-- <<images/frog.jpg>> <<images/frog_deconvolve.jpg>>
--
-- Usage:
-- >>> u0 <- readImage' "images/frog.jpg" :: IO (Image VS RGB Double)
-- ...
In order to check out the affect, run stack haddock --open
There was a problem hiding this comment.
@lehins Okay sir, will change it.
| -- >>> let us = iterate (deconvolve p d) d -- Iterative deconvolution | ||
| -- >>> u1 = us !! 1 -- one iteration | ||
| -- >>> u2 = us !! 20 -- twenty iterations | ||
| -- >>> let output = makeImage (rows u0, cols u0 * 4) |
There was a problem hiding this comment.
This is an extremely inefficient way to concat images together, try using leftToRight function
There was a problem hiding this comment.
@lehins Sure sir, sorry I was unaware of that. Will change it.
There was a problem hiding this comment.
@lehins Sir, I tested the code using leftToRight and I think that the computation time is more or less same as compared when using the previous technique. Please let me know if you would like me to replace the current version. I'm very sorry for the delay in addressing the PR's, was a bit engaged in my academic activities. I will now take up the PR's one by one and will try to address all the issues as soon as possible.
There was a problem hiding this comment.
the computation time is more or less same
Without some numbers/benchmarks I will not believe that.
You probably aren't noticing the difference because deconvolution is an expensive operation and 20 iterations take long time. The operation of concatenation of 4 images the way you have it implemented in the example on its own will be much slower than if you use leftToRight, so I do still recommend you change it.
No worries on the delay. There isn't a particular rush on any of this, especially considering that GSoC is over. Congrats on a successful project. ;)
There was a problem hiding this comment.
@lehins I think I might be doing something wrong. I implemented it like :
let output1 = leftToRight u0 d
let output2 = leftToRight output1 u1
let output3 = leftToRight output2 u2
Okay sir, I'll try to give you the compile time for both cases. Thank you very much sir!!
There was a problem hiding this comment.
You are doing it right.
It's not the compile time that's important, but the runtime :)
If you'd like to benchmark the difference, you'll have to isolate that operation of concatenation from deconvolution. Best way would be to simply read one image and try to concatenate 4 copies of it together using both approaches and record the time.
There was a problem hiding this comment.
@lehins Very sorry, I actually did mean runtime but wrote compile time instead. Okay, I'll try to record the time.
| -> Image VS RGB Double | ||
| -> Image VS RGB Double | ||
| -> Image VS RGB Double | ||
| deconvolve p d u |
There was a problem hiding this comment.
This algorithm isn't restricted to RGB images only. Also restricting to Edge might be a bad idea, so let's have it available as another argument.
There was a problem hiding this comment.
@lehins Okay sir, just one thing. I'll try my best to address the feedback on all my PR's asap but I've lectures and lab sessions today so won't be able to work on them before night time. Hope you understand. Thank you!
There was a problem hiding this comment.
@lehins Sorry sir, I didn't exactly understand. Do you mean that I should take input images as Image arr Y ?
There was a problem hiding this comment.
No, what I meant is, it should be more polymorphic. deconvolve is the opposite of convolve, so look at it's type signature and you'll see there is no reason it shouldn't be almost the same:
convolve :: (Array arr X e, Array arr cs e) =>
Border (Pixel cs e) -- ^ Approach to be used near the borders.
-> Image arr X e -- ^ Kernel image.
-> Image arr cs e -- ^ Source image.
-> Image arr cs e
So, try to fix up the code so the type signature is:
deconvolve :: (Array arr X e, Array arr cs e) =>
Border (Pixel cs e) -- ^ Approach to be used near the borders.
-> Image arr X e -- ^ Blurring Kernel.
-> Image arr cs e -- ^ Image that is being deconvolved.
-> Image arr cs e -- ^ Image from previous iteration of deconvolution
-> Image arr cs e -- ^ Deblurred image
De-convolution is used to correct the systematic error of blur (loss of contrast in smaller features) in images. This particular variant is used when no information about the distortion (blurring and noise) is known.
Sample output :
Leftmost : Original image
Next Right : Blurred image
Next Right : De-convolved (1 iteration)
Rightmost : De-convolved (20 iterations)