The Superpixel method is very straightforward. It takes the four CFA pixels (2x2 matrix) and uses them as RGB channel values for one pixel in the resulting image (averaging the two green values). The number of pixel in the resulting RGB image is one quarter of the original CFA image, having half its width and half its height. This method is very fast. It has virtually no artifacts and is very well suited for demosaicing oversampled images (images where the sensor resolution is considerably higher than the resolution of the optics).
The original feature request was closed due to lack of information, specifically, evidence of benefits over the existing demosaicing algorithms. If an example is provided, the feature request will be re-opened.
If you are asking about GâMIC, I believe I asked about or did this a long time ago for the sake of learning how to process images at a pixel level. You may be able to find it somewhere. I see the utility, but not sure if it is worth adding to something like RT. I recall dcraw having a half mode; maybe use that.
My early PlayRaws on the site used this method or others like it quite a lot, but I got tired of using 5 different techniques and tools to arrive at a result.
PS RT uses both LibRaw and dcraw. If you have the will, you could probably take advantage of the half mode.
I actually thought this was optimal as well and tried doing it in Python. Turns out its not a good idea! You will end up with strong color fringes when a edges partially cover a âsuper pixelâ. An example with your image. Imagine its split in half being dark to the left and bright ro the right. The center column will then have a strong blue cast. Flip the bright and dark and it will have a red cast. Have a thin diagonal strand be properly resolvedâŠ
You will unfortunately get much much better results using one of the softer demosaicing algos like llmse and then do a 2x2 mean.
The superpixel algorithm is, in a way, a demosaicing algorithm. It still guesses colors by assuming that the light at all four sensels in a superpixel is accurately represented by the red, average of the two greens, and the blue value. Thatâs why it can still produce demosaicing artifacts like the one Jakob mentioned.
If the sensor resolution matched the lens resolution then yes that could occur. I have 35MP and none of my lenses can resolve to that fineness. (The RAWs have a diagonal screen)
Now that itâs been mentioned, dcraw -h is the trick that rings a bell for me. BUT dcraw is ancient and doesnât support CR3.
Ultimately a drag-n-drop superpixellator is what Iâm after if inclusion in RawTherapee seems a no-go.
I forgot to mention in my earlier post the reason that I used this method. It was to detect edges using the flaw that Jakob rightly pointed out. Nowadays, I am just lazy and use the green channel of a demosaiced image.
rawproc has the half demosaic algorithm, and (mostly) current libraw, so it should open CR3s and expose them to âhalfâ damageâŠ
I was using it for proof processing, 800x600 renditions that didnât seem to suffer the artifacts, but when I realized it only added maybe a second to processing 100+ images, I just switched my proof toochain to rcd, and then I didnât have to mess with it if I selected a rendition for better/further processing.
I think by definition, a Bayer (or XTrans) mosaic needs to be demosaiced to make RGB triples.
The superpixel @HIRAM refers to is really just the half algorithm, where the four adjacent RGGB measurements are just combined into one RGB triple with the GG measurements averaged. The resulting image is half the size of the original raw array. This has been in dcraw since dirt. Itâs an exceedingly simple algorithm, not really a dimensions-preserving âproperâ demosaic, but it still deconstructs the mosaicâŠ
The problem with the Bayer pattern (well, all colour filter arrays) is that the red, green, and blue pixels are spatially separate so creating a full RGB pixel requires guesswork (demosaicing).
It the image is perfectly monochromatic then perhaps you could skip demosaicing. The half size demosaic would work if there are no image features with details finer than 2 pixels.
For me, 2 pixels is not worth crying over in the preview. Hereâs my iOS app RAWUnravel using Superpixel (dcraw -h) for preview and AMaZE for the final output:
As you can see the working preview has a tinge compared to the AMaZE output. The trade off is the preview only takes two seconds to generate whereas the output is several seconds long depending on your processing power. Nothing compared to the ultra nice tiling methods, but it gets a result albeit an iffy one. I orginally came across superpixel in DeepSkyStacker, which did seem to handle relatively monochromatic star images pretty well.
I AMaZE vs superpixel the only difference in the pipeline? I can see color differences (fingers top), and the blue fringe looks like CA which is then removed.
I benchmarked some algorithms on my travel laptop in Darktable (-d perf). It is not a powerful machine by any means (and it has no GPU), but thatâs what I have handy at the moment.
On a 20 Mp image, RCD takes 0.01s, while AMAzE takes 1.6s. Given that RCD gives reasonable output very quickly, and that it is a significant improvement over superpixel, frankly, I just donât see the point of the latter in practice.
This would be my explanation for @HIRAMâs original question: you can do so much better with existing methods at an imperceptible cost, so why bother with superpixel?
