"Boost" previewImage - add multiplying, binning, averaging, histogram stretch

[mattipee]

2x2, 3x3 and 4x4 binning and averaging. multiply 1x, 2x, 4x and 8x. Could probably generalise multiply and histogram stretch to a preview display control (eg brightness/contrast/gamma).

[mattipee]

2x2 avg works great as an alternative to demosaic->greyscale for raw images Custom1 is like 2x2 average, but each pixel gets it's own 2x2, rather than pixelating. Custom2 does the same but 3x3. 3x3 is not appropriate for raw images, must demosaic->greyscale first. 2x2avg w/mul4 is the same as 2x2bin w/mul1. Histogram stretch just takes max pixel value and scales to 255... better to define a white point as either absolute value (same as multiply), or as a %age of pixel value. Also black point. Here's where generalisation might come in. Might not help much for ASI120MM which has a high enough gain but good for PS3Eye, enables higher framerates and still reasonable preview, basically for focussing, but might be nice to have stacking in oacapture too... I'm perhaps confusing oacapture for oalive.

[mattipee]

Just learned about convolution.

• http://docs.gimp.org/en/plug-in-convmatrix.html
• http://lodev.org/cgtutor/filtering.html

Then found this:

• https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4541814/

Looks like my Custom1 filter is an implementation of "digital pixel binning"... "spatial resolution is preserved in the pixel binning process while the details are smoothed by low-pass filtering". Interesting set of algorithms proposed in that last paper that go beyond this.

[openastroproject]

Convolution I knew about, but that last paper is very interesting as I've been struggling for some time with the entire idea of binning colour images and what it really meant given the algorithms used to create the colour image from the raw data.

[openastroproject]

I'm inclined to agree by the way that this stuff is perhaps more deserving of being incorporated into oalive rather than oacapture. To my way of thinking, the display in oacapture is just there to allow the user to do the best job of capturing data for later processing and the way it is set up is biased towards that.

My intention was that oalive should be more of an EAA style application and therefore would warrant more control over the processing of what was on-screen. Potentially they could share a huge amount of code (and there is a ticket for working out how to do that), but using them for different purposes probably means that different UIs are more helpful and intuitive for the user.

To throw another eel into the hovercraft, I can also see that much of the same code might be shared by an all sky camera type application, but again a different UI might be appropriate.

[mattipee]

Indeed, there's more than one way to skin a library. The convenience of adding to oacapture has been a good start for me, though.

While there is a computational efficiency in simple binning or averaging if target resolution is lower and it's easy to code standalone, "digital pixel binning" (as in "Custom1"), as well as multiply (digital gain, I guess) and sharpening which I've also written can all be expressed in terms of a convolution matrix so I intend to simplify some of what I've as a function of a 5x5 kernel.

I've managed to get my head around the paper on adaptive digital pixel binning and will give it a go.

[mattipee]

Given a convolution routine for arbitrary 5x5 kernels, being able to boost the preview and capture the raw still feels like a useful feature for oacapture. Complexity beyond that, I agree oalive or other would likely benefit more.

[mattipee]

I've loop-unrolled convolution for 1x1, 3x3 and 5x5 kernels for efficiency. It all seems to work quite well.

Ignoring the Boost tab and associated configuration.h changes, there's the refactor of updatePreview() and the ImageBuffer class itself, and then the image modification routines.

Can the routines be pulled out into a library first and then you can decide what to do with the rest?

Happy to branch again, cherry pick, and submit self-contained pull requests if you think that's the best way... my branch is a melting pot of various things you may or may not want.

[openastroproject]

I've done as much as I want to with this for oalive for now, and created a new issue to add this functionality to oacapture.