Hi everyone
I am Jacek Gozdz (cuniek), author of DCB demosaicing (using different account and email, as old one is down).
For few last years (yes, years!) I was thinking about an algorithm that would resolve moire. I called it HBMR, and did the basic math for it but could not find time to actually test it. Time is passing and I decided to share my thoughts with You. Maybe someone will code it and check if it works? Maybe someone knows it is worth nothing? Share Your thoughts and knowledge.
I wrote a short pdf explaining it. I tried to keep it simple and compact. It is just a hypothesis! I dont know if it works! Thanks for every input.
And I think the only way to undo it is to create a higher resolution image that can contain the frequencies you need to create. This is possible with the red and blue channels in a RAW file, because those are under-sampled, but the green channel is not so easy.
@HIRAM It is one-dimensional, but technically there is no window. I fit sine function into RAW data and then look for another sine function that fits the same points but has greater frequency. The latter should, that is my assumption, represent original signal in moire area better.
Answering Your question - after chcecking initial results, I was planning to do it multi-dimensional and merge results. Maybe even cross-channel and multi-dimensional.
@HIRAM I dont have any code, therefore no. That’s the whole point of this post. I dont have time and skills to code it and check if it works. If anyone is willing to code it I would be most grateful. Maybe I could even start experimenting having a working foundation.
@HIRAM here is an updated version of my pdf with additional section of pseudocode (at the end). I did what I could to find all the exceptions (division by zero etc.) but I am pretty sure there is a lot of things that would have to be corrected to make it work.
If working, it should create a proper green channel, enough to see if there is any point in putting more effort to it.
But of course there had to be a mistake in my pseudocode. A single, important, letter in last line. Here is corrected version to avoid confusion. hbmrcode.pdf (37.2 KB)
@Jacek_Gozdz and @Iain i am certainly interested in this and would love to come back to cooperative work (some dt stuff pending here like opencl for color equalizer, …) so my timeframe would be not-before-july.
Let’s say, Jacek hypothesis is correct and we can detect moire-affected regions by this tool.
How could we make use of it?
I don’t think we can tune pre-demosaiced rgb data in a meaningful way so the demosaicers behave fine. Anyone with better ideas? Maybe some “pre-blurring”?
In dt we could create a “moire-mask” (like the one we have for details …) but would that really help?
I don’t think we currently have a good tool in dt handling/correcting/diminishing moire effects. So what would be the way to correct?
@hannoschwalm If my hypothesis is 100% correct, than it would be possible to recreate proper data, getting sharp, true-to-life, and moire free image. Once again - if I am 100% correct.
So about the correct place in the processing pipeline, for sure before demosaicing. Also likely before we do other stuff on raw data like highlights reconstruction (not so important i guess) but for sure before we do raw chromatic aberration correction.
That would mean best place would be an additional module … I will take care of that and we will see if it’s leading to something. @Iain - would you be able to do a prototype? :-))
About pipeline - the way I designed it, it should be done during demosaicing. The best way to start would be to make it a separate demosaicing method. If working, it should be part of demosaicing module, and work locally, replacing data created by demosaicing algorithm. Or built into DCB.
In this case I could also chceck influence of white balance and CA correction, as they can be easily turned off,
