It makes perfect sense and, definitely, the new realese will improve the results in that area.
I already have a pretty effective filter that detects regions with moiré. It has one parameter to control the sensitivity of the detection (actually two, but one will be fixed and won’t be adjustable via the interface). I’m trying out different solutions for guessing the interpolation direction in those areas.
I wouldn’t mind much about sharpness since an artifact free demosaicing admits sharpening better during postprocessing. But, while a lower resolution avoids luminance artifacts, it can lead to false colors around some edges. So there are some cases where extra sharpness is needed, particularly in some diagonals with high frequencies.
There are indeed some things that can be adjusted, although I personally prefer simplicity in interfaces. Depending on the data I collect this days I will decide which parts will allow some degree of user input. Thanks!
Hello @LuisSanz. Thank you for your work. I will take a look at this.
I’m really not a specialist of debayer algorithm so I can tell you what astrophotography needs.
I think that for astrophotography lower resolution is not a good idea. However blue and red fringes in a star is really not wanted too. This is why I think your third point is the best option IMO.
In this case, to better resolution is the best option. Even if noise is present in the picture we have to keep in minde that we will add a lot of picture to really remove noise. So for me that’s not a big deal.
In astrophotogrphy you can divide the image in two areas.
area with objects: stars, nebula, galaxy or anything else
background area: where sharp structures and high resolution are really not needed.
I don’t know if it helps. Let me know if you need more information.
I’m going to start by saying that I’m clearly out of my areas of knowledge, so take my comments with a grain of salt.
I understand sharpness the same as acutance, and like @agriggio, I wouldn’t mind losing some acutance only if there is no lose in perceived «resolution», understanding the later as «independent visual units» (if that definition even exists).
I mean, if there is some loss of contrast but the details (the pixels) remain differentiated from its neighbors, then there’s no problem. We can correct that with many tools.
Whenever there’s a loss of details by means of some kind of blurring or posterization, then that wouldn’t be ideal to me. And perhaps different kinds of image processing ask for different features from the algorithm.
At this point, I agree with @afre that conflicting interests call for some user control: there will be people that needs no color artifacts, but others need no posterization or blurring, and I’m afraid both can’t be offered at the same time.
I’ve done some demosaicing experiments in GMIC to reduce or remove moiré. See:
Something I have tried is estimating the correct colour (difficult with moiré) and then using that to figure out the missing colour values at each pixel.
My in my experiments the best way to get a colour estimate was to demosaic twice, once interpolating green horizontally and once interpolating green vertically, then interpolating the Red and Blue differences. This gives two different moiré patterns. I then take the FFT of both images tiles and select the minimum values from each tile.
However, the colour estimate smears colours and can’t be used in non-more areas.
If it happens to all the crops, it probably has more to do with white balancing or the camera profile my old version of dcraw has. I would disregard it and just focus on the pixel quality.
While I like the simplicity of just selecting the demosaicing algorithm and letting it do its job, I understand this request. A few messages above I offered to do a method with more user control. It wouldn’t be RCD 3 but something else, with the ability to select the methods for finding the directional strengths and for interpolating the missing green pixels.
I’m afraid it might be frightening for the user to have to guess what the different options do. To be more user friendly it could be profiled, with a dropdown for selecting the type of photography and preload some optimal parameters: architectural photography, astrophotography, portraiture, etcetera, and add an extra option “Custom…” for total control.
I think we need more voices in the discussion. Any opinion on this?
From a demosaicing point of view, what I’m trying to do is to estimate the right interpolation direction at any R or B position of the CFA to get the green channel reconstructed. If found correctly, most luminance artifacts and false colors are removed. This suits the vast majority of cases, it’s fast and it keeps the color interpolation as close as possible to the real CFA values captured by the camera, so there is no loss of chrominance detail.
In the original AMaZE implementation, I remember Emil was doing a simple 5x5 variance for each of the horizontal and vertical color differences. The results were smoothed out by a median-like filter to remove outliers and a gaussian convolution. It worked great for most of the cases. If I don’t come up with something better, I will use a similar method.
A different case is when the color aliasing is present in the raw data at a much bigger scale than the tipical 5x5 or 7x7 area used in a local demosaicing. This is rare, but it happens: the images in the topic you link are a great example. Do you still have the raw files? The link to Dropbox is down.
In these cases, even with the correct interpolation direction, a local demosaicing cannot remove the color aliasing. However, while I do believe the tools to fight this should be in every raw developer, I’m not sure they belong to the demosaicing process itself. I think it makes more sense to have a separate filter, like the one you designed, in the UI so that it can be applied independently of the demosaicing algorithm chosen by the user.
As far as the routine in the library goes, I think you need to expose all the parameters needed to shape the behavior for all the envisioned use cases. Then, offer parameter sets in the documentation that application programmers can use to make UI presets in whatever manner they choose. In rawproc, what I’d then do is to expose the parameters directly to the user, then provide documentation about the use cases, and configuration properties that would allow construction of presets. RT/ART would probably be better served with radio button presets like you describe. But your focus would be the algorithm and the parameters required to shape its behavior…
I always thought that was what moiré in regard to RAW files was. It’s an artefact that happens at the capturing stage due to inadequate anti-aliasing filters.
If we want to fight moiré, we should make differences between cameras with and without aa filters. I can post a link to a Pentax-K1 (no aa filter) pixelshift file, where pixelshift combine does not show moiré, but demosaicing shows moiré (false colors). Any interest?
Edit: Having a good pixelshift file would also be great to test the new rcd implemenation, because the pixelshift combined output is more close to the truth.
I’m personally curious if this sort of large-scale moire is indeed less present on x-trans or not. Surely it happens occasionally, if not in the same situations. (diagonal patterns?) Perhaps an x-trans image can be synthesized from a pixel-shift image.
By finding the correct interpolation directions, most of the false colors are removed. But some color aliasing remains since it was captured by the sensor and it’s not a product of the demosaicing itself.
Yes, it happens. If the photos Iain kindly shared had been captured with an X-Trans camera, I’m pretty sure there would have been color aliasing in the raw data.
That’s why I think a filter to deal with high scale color aliasing should be separated from the demosaicing so that any image, regardless of the chosen demosaicing method or the CFA it uses, benefit from it.
Do the open source raw developers have any tool to fight it? The filter @Iain wrote seems to do a good job.
That image is a simple example, but sometimes both interpolation directs give different moiré patterns
I think this is because the underling pattern is a checkerboard rather than lines,
If you look at the example image from my other thread
You can see that the demosaic has largely recovered that pattern. As a result of having correct green pixels the moiré is removed, when interpolating the colour differences.
