It is called binning. You can still do that post-post-processing. The benefits are still there: blurry images look sharper because the blur is smaller or averaged out. Certain raw processors have this half-size feature but it is a convenience feature rather than a good one; doing this will leave out the beneficial things that demosaicing algorithms do, so the overall quality is reduced.
No, as I understand it, binning is when we have several sub-pixels of the matrix covered with a single color filter, that is
RRGG
RRGG
GGBB
GGBB
instead of classic
RG
GB
Binning technology is now being actively introduced into smartphone cameras.
In this topic, it is proposed to add to the list of algorithms such that information from 4 sub-pixels is combined into one RGB pixel, while the resolution is 4 times smaller. If we have a 64 megapixel camera, the final image will be 16 megapixels. At the same time, there is no averaging and debayerization. I would like to have such an opportunity in RT. There will just be one more item in the list of algorithms.
Along with the librtprocess demosaic algorithms from RawTherapee, my hack software has a “half” algorithm that I wrote, took about 15 minutes to write IIRC. I use it for my initial ingest of raws, batch-processing a gaggle of them to 800x600 proof jpegs. So with that, my proof resize is actually two-staged: 1) half demosaic, then 2) interpolation resize to the destination. Later, if I’m producing a full-sized rendition for print or whatever, I’ll switch that out for a better algorithm.
Comparing half-demosaiced images to ones demosaiced with “regular” algorithms is a bit wonky, as the resolutions are different. Still, I can see blockiness in the half-images that compel me to not use half demosaic for anything other than proofs.
Here’s a link to the code that does it:
https://github.com/butcherg/rawproc/blob/master/src/gimage.cpp#L3175
1 Like
I am talking about binning as it pertains to image raw/post-processing; see, e.g.: Photo Handling -- IM v6 Examples. Just to be sure, do you mean combining the Rs into one R and doing the same for the G/Bs?
RGRG
GBGB
RGRG
If so, you are missing out on the advanced corrections that demosaicing algorithms make. Take a look at any algorithm; e.g., RCD. There is a discussion to be had what constitutes a good method.
Definitely would like/could use this too.
My phone produces rather good images, but due odd DNG and really non-standard CFA (which quite apparently was made mostly to be pixel binned for output) its a bit hard to use those files to full potential. Also RT I guess cant read/use noise profiles for phones either. Unsure how hard/possible is to implement that.
Anyway, pixel binning would be something I would like too.
@ggbutcher thank you! I will try to build RT from the sources by embedding your code. But I have no experience in this. As I understand it, such an algorithm gives a side effect in the form of a ladder on sharp diagonal lines. But let’s see, I’ll try.
@afre I’m not sure we understand each other. Sorry, maybe this is an auto-translation problem (I’m from Russia). I’ll try to explain in more detail.
All current debayerization algorithms make four full-color RGB pixels from four single-color sub-pixels by interpolation using different algorithms. But at the same time, the actual color resolution is 4 times less.
When I wrote above about pixelshift technology, this is not binning. This mode is available in many cameras with a stabilizer on a shift matrix, in such cameras as Olympus, Panasonic, Sony, Pentax, as well as Hasselblad and Fujifilm in medium format. The camera takes several pictures in a circle, shifting the matrix by sub-pixel distances around the real pixel. Then combines these images into one with a higher resolution. This increases the detail and color resolution.
So my Olympus camera with a 20mp matrix takes 8 pictures and receives an 80mp file. And just an algorithm without interpolation would allow us to get full-color 20mp with real color resolution from these sub-pixel 80mp.
And binding is exactly the technology used in phones (64, 108 mp), where the color resolution is 16 times lower, because 1 pixel consists of 16 sub-pixels = 4R 8G 4B. I don’t know why this technology was invented, but it gives bad pictures. No better than the usual 12-16MP matrices in phones.
@Corwin_Black A modification of Google Camera is installed on my phone and it outputs a DNG raw file. I do not know exactly how it is obtained (computational photography), but it is quite sane and allows you to pull out the maximum detail from the phone camera. In general, I have not met a phone that gives out useful detail of more than 5-6mp.
That’s why I only use it when the destination is a JPEG for web-viewing. The downsize obliterates any deleterious side effects of the ham-handed half demosaic… 
I wish to chime in and make a clarification about this concept, which is repeated in many many websites and forums: to my knowledge with pixel-shift the camera takes several pictures with it’s native Bayer CFA. That means that each picture has half resolution at the green raw channel, and 1/4th resolution at each red and green raw channels.
In other words: given a 10MPx sensor, the green raw channel has a resolution of 5MPx, and each red and blue raw channels have a resolution of 2.5Mpx.
Every and each pixel-shift sub-image will have such very same channel resolutions.
The point with pixel-shift is that 4 images are combined so every and each raw pixel will end up with all 3 channels having valid, real data coming from the scene. This means that each combined raw channel will end up with a 10MPx resolution.
Now, a typical Bayer image will have to be demosaiced so the algorithm guesses the values lacking on each raw pixel. On the other hand, the pixel-shift image doesn’t need to be demosaiced. There’s no need to guess any value, because each raw pixel already has all RGB values.
But on either case, the output image will have exactly the very same resolution (in the previous example, 10MPx), and there won’t be any increase in image resolution: a demosaiced Bayer image will have 10MPx, and a pixel-shift combined image will have 10 MPx (with that example sensor).
The big difference is that a pixel-shift image will be able to resolve lightness and color details much better than a demosaiced image. But again, no increase in total number of pixels.
HTH
1 Like
I understand perfectly well that 80mp pixel-shift is not the same as 80mp of a real matrix, but in practice, it really gives a big increase in detail and even noise reduction. I used this technology as an example, that we have an 80mp source and, bypassing debayerization, combine subpixels into full-color ones, we get a 20mp image with improved color resolution. At the same time, when using other treatments and filters, the PC processor is loaded much less.
@junkhead You didn’t mention pixel-shift until now. 
Doesn’t RT already address it? What is the problem that you are encountering? Sorry, my mind hasn’t been on photography or image processing lately. Perhaps @heckflosse @Thanatomanic could chime in.
I mean, technically there is no reason why we couldn’t add another demosaicer. Even one that reduces the dimensions of the image by binning pixels or ‘subpixels’. If I’m realistic, the actual question is: who is going to code it?
And true pixel-shift files can already be processed by RT with great quality if I may say so.
1 Like
Yea I tried Google Camera, but original supplied with phone is a lot better. Outputs DNG too, just they used some insane version of DNG so very few things work with it. But I solved it.
It only needs to run thru Adobe DNG converter, which puts all DNG parts where they belong and then it can be processed with most stuff. Then I figured out, since its Sony 64 mpix, what will happen if I spoof EXIF to make it look like different Sony 64 mpix (or almost, A7R MKIV).
Turns out, it makes that DNG usable in every possible raw processor and it makes it work remarkably good.
My phone has about 15 mpix of real resolution from 64, basically image halved.
Still quite positive pixel binning would do good even in this case, cleaner SNR probably.