I still want to consider what @CarVac said about chromatic abberation. Otherwise, I’m going to incorporate it in my proof processing. I went camping with my son this weekend, shot a bunch of images in a rather beautiful fall-colored Saturday morning. I didn’t batch-process in the field, but if I had I would have appreciated the shorter up-time on my tablet, as we had no power for recharging…
Deepskystacker optionally does dcraw -h. They call it superpixel.
I find the easiest way to get the effect of dcraw -h is to compile dcraw.c and use dcraw -h -T -4.
yes, when you are sampling music, you are loosing information. That is, what i would accept. I just want to avoid adding pseudo-information by a machine. But that is, what regular debayering does.
“Superpixel” and less noise and possibly nicer colors (for example the pink peavine flowers) were all reasons why I was experimenting with outputting non-demosaiced raw files and resizing them. Today’s cameras do output very large images and very often one doesn’t need that large of a final image.
Speed of processing to one side, has anyone compared results of “dcraw -h” with outputting the whole non-demosaiced image and resizing using various scaling algorithms?
Oh, if it’s relevant - I think it might be if the goal is to extract as much quality image information as possible - I shot the Japanese knotweed image through a magenta filter in an attempt to even out the amount of light reaching the pixels covered by the red and blue filters vs the pixels covered by the green filters on the bayer array.
Considering that the non-demosaiced data is somehow more ‘pure’ than demosaiced data is simply false. For every pixel on the sensor, there is always some light leaking onto the neighbouring pixels and there is always some aliasing going on. These effects can actually be remedied during demosaicing.
2 Likes
I have played with raw data exported by dcraw's document mode and I would say that down sampling raw data reduces the amount of detail that could otherwise be achieved by demosaicing. Sure, algorithms introduce artifacts and other problems but that goes away as the resolution of cameras increase (or better algorithms are discovered 
). (I have an ancient camera by this forum’s standards, so I have to contend with less than ideal raws.)
I don’t think the audio analogy is an apt comparison. I would liken demosaicing to making a cookie. A completed cookie tastes better than the sum of its parts. 
However, you could technically eat it at any point of the process. I guess I am hungry for a late night snack. 
Where was I…
The raw file is stored the way it is because that is what the sensor and electronics output. Of course, it isn’t the direct output; there is much more going on in the black box that is our cameras, unless you are in the business of knowing that stuff. We know why manufacturers give us access to raw files though. It is so that tinkers like us can do PlayRaws. 
Or we disagree with the appearance in-camera generated JPGs. Or it is that these JPGs were optimized for speed and not for quality, etc.
1 Like
Thank you
Good afternoon! I came to the forum to suggest this method, but I see that I’m not the only one who thought about it. If this has any weight, I would also be happy to see this algorithm in the RT list. In my photo processing process, I eventually bring the final image to a resolution of ~4-5 megapixels, despite the fact that my cameras have 16 and 20 megapixels. Perhaps such an algorithm will avoid some intermediate processes of the demosaic with a subsequent reduction in size, I assume this will also minimize the need to sharpen and give a more accurate color by default. In addition, with a lower resolution, the load on the processor will decrease when using other tools and filters. I think that this is especially important with the advent of more and more megapixel cameras and the spread of pixel shift technology. Thanks!
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.