Messages

Best way to waste money.
The 45MB/s Sandisk is fast enough.

That's not true. Sandisk Extreme Pro 45 MB/s have a write speed around 21.2 MB/s. That's far from enough to shoot continuous 720p.

Yes, something wrong for sure. Have you tried another aspect ratio and/or resolution?

Pink dot remover (v0.8 and v0.7 ) seems doesn't work on the RAW from the latest ML version (31.08.2013).

Don't know what are you talking about. Just tried latest PDR on 31.08 ML build and everything is just fine.

By the way, check out my fork of PDR, it has much less artifacts for now.
Source: https://github.com/Re-wind/PinkDotRemover/tree/ImprovedInterpolation
Binary and some info: http://www.magiclantern.fm/forum/index.php?topic=6658.msg70661#msg70661
PDR rewind 2

The SD controller's bottleneck is around 20-21 MB/s.
I'm using Sandisk Extreme pro series cards. The one marked 95 MB/s does the job right. With those i'm hitting the camera wall, not the card.
1200x496 @24fps for more than 20 secs is not a problem.

Was that you that compiled the release that included that?

Yes, I've just added a couple of figures to Pravdomil's source to get more usable resolutions like 1200:
https://bitbucket.org/pravdomil/magic-lantern-hack/commits/all
and compiled it.

Here is the raw_rec

Use the canon's menu

BTW, while recording using live view i can zoom 5x but 10x make my camera crash immediately, so how can we do the proper focus without zoom in and how to back to normal view after 5x zoom (as above 10x crash)

Just go to Prefs — LiveView zoom tweaks, and switch the x10 off.

...but if this will work on xxD && xxxD I may well get a rebel.

For example, dual ISO works fine on t2i both in photo and video modes

So, basically, I should better leave them alone for now, right? ))

Got it. So, these ROMs will be needed to unbrick the camera? Can I save a couple of them to my PC, and use them later if i brick my camera?
Or better point me to the thread where i can read something about it please.

How one can disable logging on startup? (...ML\LOGS\ROM0.BIN, ROM1.BIN)

The lack of detail in h.264 is what makes you think that way. Just shoot RAW and you'll get the proper detailed motion blur.
Also, take to the account the rolling shutter effect. Because of it, once in a while you unavoidably will come up with some troubles like motion "tearing", but 1/48 is a good start for almost any situation.

Why in the world you would need such a feature? ))
Don't get me wrong, but ML is exactly what we are all about here. Can't recall any situation, when i'd like to switch it off.

Yes ,https://www.dropbox.com/s/tu8tgpbady8oyqp/ML.rar , no hay que usar pinkdotremove.

Yes, https://www.dropbox.com/s/tu8tgpbady8oyqp/ML.rar, do not use pinkdotremove

This method uses RAW_TYPE 78, which marks dead pixels, but produces a full frame grid of green dots, is absolutely not what you want, if you concerned in quality. Later your raw processor interpolates them, but the artifacts are terrible in comparsion with the Pink Dot Remover tool.
http://www.magiclantern.fm/forum/index.php?topic=6658.msg69459#msg69459

Just forget it. Use the latest PDR for now.

Pink dot remover takes aloooot of time...

Latest PDR works directly with RAW files, this is way faster then process every dng individually, also it includes drag&drop support now, so removing pink dots is just a matter of couple of clicks and a few seconds of time.

I need a recommendation on the best cheap ultra wide angle.

Cheap means at least $400, when talking about wide angle.
For example Sigma AF 10-20mm f/4-5.6. I'm using it a lot. Nice glass.

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 Expand

    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.

I'm follow the article here: http://www.thinkdigit.com/Digital-Cameras/Guide-to-using-Dual-ISO-Mode-on_17150.html

Why don't you follow the method author's thread?
http://www.magiclantern.fm/forum/index.php?topic=7139.0

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!

PinkDotRemover (v0.7) only convert .DNG files, not directly .RAW .

Use the debug release. It can process raw files directly:
http://www.magiclantern.fm/forum/index.php?topic=6658.msg62437#msg62437

By the way guys, while Fatpig is AFK, note that the checkboxes for "lossy" and "lossless" compresseion are just swapped around

For now, you can probably use the pravdomil's source to build raw_rec with some features like which are you talking about (different styles of interface including no info at all, black borders around frame during recording etc.)
http://www.magiclantern.fm/forum/index.php?topic=5582.msg57683#msg57683

I'm succesfully using my own slightly modified builds from this source on 550D and 650D. Works nice.

Right-click on your footage in project panel, Interprete footage — Main — More options. This will bring up the ACR with the first frame in the sequence.
Also you can edit ACR settings on any given frame, just go to the Bridge, select all of the dng's, open in ACR, edit whichever dng you want, synchronize, click done. After Effects CC will automatically update the footage. In earlier versions just select "update footage"

Use the builds from Pravdomil's source. This function is already implemented, and i use it successfully on 550d and 650d.
It looks like this: http://www.magiclantern.fm/forum/index.php?topic=5582.msg57683#msg57683

I was just excited after finally finding the address...

Wish I could shake your hand, man.

I do not understand how to properly work with the cr2hdr.exe? 
I drag file .DNG(made using raw2dng of .RAW) on cr2hdr.exe- nothing happens!

cr2hdr is for cr2 files, as its name says )