PinkDotRemover tool 650D

[TheUnkn0wn]

Guys, may I ask you please to share a build with RAW_TYPE 14. I compiled it by myself, but I cant see any difference: the pink dots pattern is the same. May be i'm doing something wrong.

https://bitbucket.org/theunkn0wn/magic-lantern

[Rewind]

Well, I don't think these raw_type manipulations are exactly the Solution. Pink dots around high contrast edges are still there.
I mean, this method doesn't excludes the focusing pixels from raw stream, it just adds correct hot/dead pixel info, so we can chose whatever soft we want to deal with them. Right?

Also, TheUnknOwn said, that “With raw_type 14 you don't get any image anomalies using Adobe software”. Anyone can confirm that? In my experience, when i change the string in raw.c to #define PREFERRED_RAW_TYPE 14, compile and process with ACR, i see the same pink-green artifacts around high contrast edges:

[TheUnkn0wn]

Well, I don't think these raw_type manipulations are exactly the Solution. Pink dots around high contrast edges are still there.
I mean, this method doesn't excludes the focusing pixels from raw stream, it just adds correct hot/dead pixel info, so we can chose whatever soft we want to deal with them. Right?

Also, TheUnknOwn said, that “With raw_type 14 you don't get any image anomalies using Adobe software”. Anyone can confirm that? In my experience, when i change the string in raw.c to #define PREFERRED_RAW_TYPE 14, compile and process with ACR, i see the same pink-green artifacts around high contrast edges:

Use RAW_TYPE 78 or 99

I missed the focus points in 14

[Rewind]

Use RAW_TYPE 78 or 99

I missed the focus points in 14

These raw_types acts exactly the same (at least for 650D).

Pink dot remover tool gives better results for now.
First crop below shot with older build, cleaned up with pink dot remover tool and processed with ACR.
Second crop was made with RAW_TYPE 78 and then processed with ACR.
As you can see, in the case of using raw_types ACR has to interpolate not only the focusing pixels, but also that green pattern all over the frame, causing the black spot appears like a whole mess of green-magenta stuff. First picture is much cleaner. (I use the mosaic engineering vaf filter, so there's no place to aliasing and moire at these examples, and first one in video looks acceptable and usable, but second is not).

[Rewind]

Foorgol, I have a question:

Using PDR tool in interpolate mode gives an overall good results (it eliminates the consistent pink dots around high contrast edges, which set dead pixel method can't do), but it produces another problem: pronounced somewhat random colorful artifacts in detailed contrasty areas, such this:


Let's say I can live with some quality loss, if so, is there any simple method to interpolate those things hell of a lot? I mean, turn off that judgement algorithm, you've been talking earlier ( http://www.magiclantern.fm/forum/index.php?topic=6658.msg55325#msg55325 ), and just interpolate all of them?
Should I change something in dotData files for example? Or, if there's no way to do this from dotData files, wouldn't it be a good idea to integrate some option in your program, like slider gives a user a possibility to determine how sensitive this decision algorithm is?

EDIT: The positions of these artifacts are not random of course, they belong the same grid. It seems like just something is wrong with the interpolation method. Watching carefully to particular dot, shows that when surrounding is smooth, it interpolates fine, but when the surrounding is some kind of an edge, then fancy colors appears: sometimes green, sometimes magenta or yellow etc. for the same dot.

May be this is something to do with the “finding the minimum gradient” in your PinkDotRemover.java source.
I'd like to dig in and experiment with that, but I need some help: can you guys please point me to the resources on how to build from java?

[mixer2]

@Rewind:
current pdr removes all dots for the defined pattern. there isn't any algorithm that checks, if it should fix the dot, or something like that.
there will be a better algorithm for interpolation in the next version which should lead to much less artifacts. have to talk to Foorgol when we'll finish the new version, that you can try it.

[Rewind]

there isn't any algorithm that checks, if it should fix the dot, or something like that.

Got it. Figured that out already, studying the source

there will be a better algorithm for interpolation in the next version which should lead to much less artifacts

That would be great, we'll be looking forward to that. Guys you rock!

By the way, mixer2, which IDE you'd recommend for java development?

[mixer2]

if you're interessted in the sourcecode you can check the version with the new interpolation algorithm... very unclean so far, but it's already working with much better results if you want to try it -.-
https://github.com/mixer2/PinkDotRemover/tree/ImprovedInterpolation

it's basically the algorithm from this paper:
http://www.tanbakuchi.com/Publications/Papers/2003AdaptivePixelDefCorPub.pdf

about the IDE... i really don't do any java beside pdr. the only reason i installed a java IDE was because Foorgol wrote the pdr in java and i wanted it to be compatible to the eos m. did some java at the university before... but not much at all. so i don't know much about java IDEs. that said i would always use the IDE the other developers of the project also use. imho it's just a good idea if the whole development team has the same environment. on the pdr i work with netbeans, since Foorgol developed it with netbeans. neatbeans is ok... it's fast and it does work. but, for example, on another project i currently work on, that is written in c++, i use eclipse, because all others working on that project do use eclipse. it would be possible to develop both in eclise or both in netbeans... but just use what the others do. for small new java or c++ projects i would use netbeans, because i have it already installed and i prefer it over eclipse.
if you ask what i think would be the best IDE for java development i would suggest giving IntelliJ IDEA a try. i have never used it and don't have it installed, that's why i said i would use netbeans, which i have already installed, for small projects. since i never used it i'm not sure that it is the best IDE for java development, but i do work every day with PhpStorm, which is from the same company, and it's the best IDE i've ever used.

[Rewind]

mixer2, thank you. So much useful info.

[nanomad]

Ok, just confirmed it's not a de-bayering error. The green pixles are burnt into the image

[Rewind]

Aloha, brotherhood )
Bring you some good stuff.

Well, I've studied Foorgol's and Mixer2's source, installed the NetBeans and dig in ) I've spend a couple of nights to do my own research on Bayer pattern, defect correction techniques and that kind of stuff.

I've tried a couple of interpolation methods, they seemed to work fine in some situations, but fail in others, so finally i settled on some form of adaptive interpolation, same as the developers of PDR did.

While the original Tanbakuchi's implementation of an adaptive pixel defect correction seems not working for me (doesn't hold the edges correctly and has too many artifacts in high-frequency areas), this slightly modified method alraedy gives a quite acceptable results: It holds the critical vertical and horizontal edges nicely, has a lot less artifacts and a reduced overall false colorization.

The gif below shows the comparsion between current interpolation method in PDR and my modified adaptive interpolation (200% crop, 1 sec change)


I'm not a programmer, so I don't know your rules here guys. May I or may not share my build? Can we share the knowledge with the developers of PDR or am I just sticking my nose where I don't belong?

Anyways, in conjunction with VAF filter, i've already turned my 650D into the hell of a raw machine )) Now PDR gives me acceptable interpolation quality, modified raw_rec module allows me to shoot stable 1520x636 (1:2.4 cinemascope) for more than a minute, so we are going to shoot our sci-fi short entirely in raw workflow this autumn. That's so damn great!

[mixer2]

@rewind:
nice work! it's open source so you're free to share any builds of it.
it would be great if you could make a pullrequest on github, that it could be included into all future pdr versions.

[foorgol]

Wheeew... a little more than two weeks of vacation and business trips and the good, old PDR-world is not what it used to be anymore :-)

I just flipped through the last pages of the thread and understood that the PDR is not (yet) obsolete. Right? So I keep my promise to release a new version 008 which brings you, compared to the previous official version 007:

  * Better support for "ugly" image resolutions which are not divisible by 4

  * Improved pink dot locations for crop mode and EOSM

  * In-RAW dot removal for videos files (no need to process hundreds of DNGs anymore)

  * Better file list in the GUI, including support for Drag&Drop and deletion of selected files with the Del-key

  * Persistent storage of the selected camera type for the GUI

  * Possibility to provide the cam type as first command line parameter for batch operations


Some of the features were already available in the last debug release. And credit were credit is due: all the GUI and dot location data improvements were contributed my Mixer2. I concentrated only on the in-RAW-removal and on merging Mixer2's pull requests...

Download the binaries here: https://dl.dropboxusercontent.com/u/22843507/MagicLantern/PinkDotRemover__008.zip


I'm looking forward to include an improved removal algorithm in the next release. Again, Mixer2 already contributed a very promising implementation and obviously Rewind is also working on some neat stuff. Perhaps we'll just add a drop-down menu to the GUI so that you can choose the algorithm. That would be the easiest (intermediate?) solution.


Happy dot removing and thanks again to all testers and contributors,
foorgol

[foorgol]

I'm not a programmer, so I don't know your rules here guys. May I or may not share my build? Can we share the knowledge with the developers of PDR or am I just sticking my nose where I don't belong?

I can only second Mixer2's statement: please share your code so that we can merge it with the official releases. If you're familiar with GitHub, issue a pull request; that would be the easiest and preferred way of sharing your code. As an alternative, you can send me your sources and I'll merge them manually.

@Mixer2:
What do you think? Replace my old and busted removal algorithm with yours AND Rewind's and introduce a drop-down box (or radio buttons) to select the preferred method?

[Rewind]

Well, seems to me, i've made a pull request
https://github.com/mixer2/PinkDotRemover/pull/1

But GitHub is still over my head for now, so i'd like to duplicate my code here. Just for clarity sake (not sure, if i did a request right)

Code: [Select]

    protected void interpolPixel(Generic_CFA_PixBuf srcBuf, Generic_CFA_PixBuf dstBuf, int[][] dotList)
    {
        int w = (int) srcBuf.imgWidth();
        int h = (int) srcBuf.imgHeight();
     
        for (int[] dot : dotList)
        {
            int x = dot[0];
            int y = dot[1];       
            if ((x < 3) || (x > (w - 4)) || (y < 3) || (y > (h - 4))) continue;
           
            //Modified adaptive pixel defect correction algorithm from
            //http://www.tanbakuchi.com/Publications/Papers/2003AdaptivePixelDefCorPub.pdf
            //Takes to account only two vectors (horizontal and vertical)
            //Not entirely shure why, but this gives better results in all methods i've tried (both high-frequency false colors and edges treatment)
            //Maybe simply because of squared nature of raster images themselves
           
            // 1. Retrieve vectors from 7x7 kernel
            // d[0] — vertical vector
            // d[1] — horizontal vector
            // index reference:
            //        paper     -3 -2 -1 0 +1 +2 +3
            //        actual     0  1  2    3  4  5
                int[][] d = {
                {srcBuf.CFA_getPixel(x,y-3), srcBuf.CFA_getPixel(x,y-2), srcBuf.CFA_getPixel(x,y-1), srcBuf.CFA_getPixel(x,y+1), srcBuf.CFA_getPixel(x,y+2), srcBuf.CFA_getPixel(x, y+3)},
                {srcBuf.CFA_getPixel(x-3,y), srcBuf.CFA_getPixel(x-2,y), srcBuf.CFA_getPixel(x-1,y), srcBuf.CFA_getPixel(x+1,y), srcBuf.CFA_getPixel(x+2,y), srcBuf.CFA_getPixel(x+3, y)}
                };
           
            // 2,3 — We don't need these stepse because of diagonal af dots arrangement
               
            // 4. Normalizing vectors
                // vertical norm.
                d[0][2] = d[0][1]+((d[0][2]-d[0][0])/2);
                d[0][3] = d[0][4]+((d[0][3]-d[0][5])/2);
                // horizontal norm.
                d[1][2] = d[1][1]+((d[1][2]-d[1][0])/2);
                d[1][3] = d[1][4]+((d[1][3]-d[1][5])/2);           
           
            // 5. Deltas and Weights
            int dVert = Math.abs(d[0][2]-d[0][3]);
            int dHoriz = Math.abs(d[1][2]-d[1][3]);
            int Delta = dVert + dHoriz;
           
            float wVert = 1-((float) dVert / Delta);
            float wHoriz = 1-((float) dHoriz / Delta);

            // 6. Calculating new pixel value
            float newVal = wVert*((d[0][2]+d[0][3])/2) + wHoriz*((d[1][2]+d[1][3])/2);
            dstBuf.CFA_setPixel(x, y, (int) newVal);
        }
       
    }
For those, who wants to try this method, here is the link for the build. It made of latest foorgol's and mixer2's source, so also includes drag&drop support etc.

[mixer2]

@rewind and @foorgol:
your pull request is correct. i just didn't merge it so far, since i'm not completely sure if it will perform better in every case. removing the diagonals may lead to problems with diagonal lines.
i'll test both algorithms in multiple situations and do some further investigations if we can improve the algorithm without removing the diagonals. if there is a way to get best of both worlds we may just use a single algorithm. if each algorithm performs better in some situations we may let the user choose.

[dsagilles]

The pinkDotRemover (v 0.8 and 0.7) doesn't remove pink dots on RAW/DNG files shot with the latest ML for 650d (31.08.2013).

I've try 2 RAW videos in the same condition except ML version :
- Nothing is removed with PDR on the latest version (31.08.2013).
- Pink Dots are removed fine with an older build (08.08.2013).

The pink dots pattern seems to be the same with the 2 versions.

I guess something had been changed recently concerning the RAW module (plus I can't install the old raw module on the latest build : it says it's in "V2" and a "V3" is expected).

[maxotics]

@mixer2, @foorgol Sorry to clutter the thread but I was to make ABSOLUTELY sure your work is greatly appreciated!  As you can see on vimeo.com/maxotics, I'm using PDR every day.  A few days ago I decided I had to make a big decision, focus on the 50D with more resolution and no pink dots, or go with the smaller, less resolution EOS-M with pink dot workflow.  I chose the latter because PDR works great (or I can't see any problems).  My wish list would be a PC exe that automatically detected between crop and non crop mode and did the conversion.  But again, am perfectly happy and wanted to thank you both, and your new musketeer @rewind, again and again and again!

[Fuma]

Anyone else who has problems with PDR with the actual builds(31.08 and 03.09) of ML when Video Crop mode is activated?

[mixer2]

hurm, i don't have an 650d, so i can't find the compatibility problem with pdr and the current 650d release.
if you send me a dng that doesn't work i can investigate and fix it.

[Fuma]

https://www.dropbox.com/s/do6ol4p8veadf2d/000000.dng

[mixer2]

it's crop mode, isn't it? i have no idea why the dot positions moved. maybe they changed something how they calculate the crop position.
try this temporary dot location file, till we know why the dot positions have changed.
http://dl.dropboxusercontent.com/s/by314z0kb8pfvsb/CropMode.txt

[Fuma]

thank you for the quick help,
the ML Version before 31.08. had worked pretty well in crop mode.

[gary2013]

Mixer2,
I am having a problem with PDR not removing all the dots. There is a faint leftover after processing files. Am I doing something wrong or is there something with the latest ver of ML causing the dots to not completely be removed? here is one dng that was processed by PDR-
https://www.transferbigfiles.com/05231aab-4072-4d49-95dc-8c0f979d4a95/zBh_ykiyjkZigXt8I_776g2
Gary

[gary2013]

Mixer2,

I got your reply in the M forum.
Sorry for the double posting.

Gary