Home-brew software for LR deconvolution.

[michael.h.f.wilkinson]

I have put together a little command line Linux program that performs LR deconvolution with Gaussian PSFs. The code is really very simple and it is pretty fast (3Mpixel image in a couple of seconds for 50-100 iterations). Just had a quick test on some pretty cruddy data from the summer of 2013 in Tuscany (boiling seeing).

Raw data:

LR Deconvolution sigma= 1.5, iterations= 25

Quite decent given the bad input. I also tested it on an earlier mosaic with artificial blur, and it could recover a result pretty close to the original. I am going to wrap a little GUI around this code, and allow users to control batch processing from in by loading multiple images. I am planning cross-platform portable code which can handle many bit depths and I/O formats.

[tingting44]

nice! thats a big difference 

[Floater]

Michael, as you may have picked up from some of my posts, I'm purely visual (and determined to stay that way, by the way!) so the language/code you use is a foreign tongue to me.

But I have eyes and I enjoy, very much, seeing the images you and others share. They are in a language I understand.

Power to you.

[David Smith]

That is impressive Michael.

[michael.h.f.wilkinson]

Thanks, everybody. Got a Windows command-line version running, and ran it on some data here:

Raw

LR Deconv

Raw

LR Deconv

Looks like it works properly. Might run it on some data on the other machine

[RCompassi]

Very nice indeed!

Give a shout if you need a beta tester!

Cheers

[michael.h.f.wilkinson]

Just wrote a little bash script in Linux and the old laptop is chugging away nicely. A set of thirty or so panes in under 2 minutes, at 70 iterations per pane, or more precisely 49 panes in 2m 6.5s, and that on an old Core Duo at 2.0 GHz. I will post results later.

[Stu]

Looks like it works very well Michael. I'm in the same boat as Floater, a purely visual observer with no aspirations of starting imaging but someone who enjoys seeing the output of others on here. I'm also curious and interested in understanding as much about it as possible.

With that in mind, is there a layman's explanation of what this routine is doing?

Stu

Sent from my iPhone using Tapatalk

[michael.h.f.wilkinson]

Looks like it works very well Michael. I'm in the same boat as Floater, a purely visual observer with no aspirations of starting imaging but someone who enjoys seeing the output of others on here. I'm also curious and interested in understanding as much about it as possible.

With that in mind, is there a layman's explanation of what this routine is doing?

Stu

Sent from my iPhone using Tapatalk

I have posted an explanation here:

http://stargazerslounge.com/topic/228147-lucy-richardson-deconvolution-so-what-is-it/

[Stu]

Thanks Michael. I shall re read that a few times until it sinks in :-)

Sent from my iPhone using Tapatalk

[Mick J]

Thanks Michael. I shall re read that a few times until it sinks in :-)

Sent from my iPhone using Tapatalk

Same feelings here, will have to read & reread a few times, fascinating.

[Photosbykev]

Very nice work Michael. The results are crisp without being over the top

sent from my Sony Xperia Z2

[Stu]

Very nice work Michael. The results are crisp without being over the top

sent from my Sony Xperia Z2

That seems to be the secret, sharp results but very natural looking still. Highly effective

Sent from my iPhone using Tapatalk

[jgs001]

Looks fantastic results Michael. Good work. If you would like me to test it on my mac, happy to oblige.

[michael.h.f.wilkinson]

Cheers guys. For a Mac version I can provide source code plus instructions on how to compile it. I might be able to get it to work on the Mac one of my colleagues, in which case I could distribute an executable. I am not quite sure how to package it for distribution, however

[Cath]

Being a nerdy coder (mainly Windows) I'd be very much interested in seeing the source code Michael

[Pete Presland]

looks very good!

[michael.h.f.wilkinson]

Thanks people!

Being a nerdy coder (mainly Windows) I'd be very much interested in seeing the source code Michael

I will post the code later (that's on my dual boot laptop, I am now on the win8 lappy).

[jgs001]

I can give it a try Michael.. I think I've got the Mac dev tools installed... 

[michael.h.f.wilkinson]

I can give it a try Michael.. I think I've got the Mac dev tools installed... 

Thanks! When I get everything in order I will send you the code.

[NickK]

I have put together a little command line Linux program that performs LR deconvolution with Gaussian PSFs. The code is really very simple and it is pretty fast (3Mpixel image in a couple of seconds for 50-100 iterations). Just had a quick test on some pretty cruddy data from the summer of 2013 in Tuscany (boiling seeing).

Early GPU version - non optimised seems to give 17.1 MB image in 0.4 second for 50 iterations using the existing primitives. Optimisation would be making the PSF a local memory workgroup memory lookup would make it faster still.

[DrRobin]

Great work on the coding Michael. If you need another to test let me know. Sadly I am Windows only for this kind of stuff. We make embedded Linux devices at work (data loggers, routers, that type of stuff) but I don't know it would run on one of those and our Linux server is a tad old.

Robin

[michael.h.f.wilkinson]

Early GPU version - non optimised seems to give 17.1 MB image in 0.4 second for 50 iterations using the existing primitives. Optimisation would be making the PSF a local memory workgroup memory lookup would make it faster still.

This is the kind of workload that GPUs like, typical SIMD parallelism. However, as I tell my students: first get it to work, then get it to work fast. Besides, CUDA machines are not generally that good at double precision math (it is getting better), which is really what I like to use to avoid numerical instability.

In your example, what pixel data type was used?

[NickK]

This is the kind of workload that GPUs like, typical SIMD parallelism. However, as I tell my students: first get it to work, then get it to work fast. Besides, CUDA machines are not generally that good at double precision math (it is getting better), which is really what I like to use to avoid numerical instability.

In your example, what pixel data type was used?

LR really needs double working, as you're hinting at, this was float as a quick metric. I can enable the khr double support for a quick test this morning. ATI isn't much better than CUDA, nor is Intel's own OpenCL support (although their commercial compiler does a far far better job at CPU based optimisation).

I found that GPUs work best with float or float4.. especially as apple's drivers for OpenGL only support specific formats and I'm sharing OpenCL and OpenGL objects.

The annoying thing is the lack of GPU j0 or j1 support so if I wanted to load the kernels with more maths to reduce the size of data (local workgroup memory is very small compared to the images it's processing!

I'll also explore sharpening the stack - so as the stacking continues, it's iterating further - this may allow the reduction of the number of iterations per stack addition..

[michael.h.f.wilkinson]

If you restrict yourself to Gaussian kernels, you can use the recursive filter algorithm by Van Vliet and Young. Because the Gaussian is separable, it works row-wise. This means each local group works on a single row or column