Crop mode recording (crop_rec.mo) (1:1, RAW/H.264, 25/30/50/60 fps)

[NoCp_Albert]

Test this also now and confirme this Problem also for  5D3-123 on PAL and 50 FPS with MLV and RAW_rec.
With MLV_rec and AutoETTR I get corupted Files with this settings in MLV_view and in the Clips also.
RAW_Rec works fine

[anto]

what is the best resolutionfor to scaling image to 1080p?

shooting in 2,88k (as the Alexa do) we can have a 1080p from a compession of 2 every 3 pixels (2880/1920=1,5=3/2)
in 2,304k we have 1,2 compression ratio.

it's better to choose a resolution that give us a compression ratio more precise (like 1,5) or this isn't a problem shooting in raw? so, more resolution more detail?

[hyalinejim]

Well, why not test it and post the results?

[anto]

unfortunately currently I have only a 50mm f1.8 canon (50€ lens).  i think  could be a more accurate test with good zoom lens, because changing the resolution change the crop.

[Lars Steenhoff]

the 50 mm is fine, just stop it down a bit and you will have trouble finding a significantly sharper lens no matter what the price is.

[panth3r]

did some 50fps testing @ 1920*672 (i am able to record 23 sec with this quality)
@5d MkIII 1.13

additionally a comparison between crop mode raw (right) and no crop mode raw (left) ( both "slomo" mode = 50/60 fps)
with 5dmkIII sigma 105mm. like it! heavy letterboxing though

[RenatoPhoto]

Testing of 3x3 crop module recording at 60 fps with 5D3-123
Test to evaluate the lower noise and higher definition of 3x3 bining recording.
Build: magiclantern-crop3x.2017Jan13.5D3123

For comparison below are three frames from recordings at standard (stretch) 60 fps recording, 3x3 bining, and 1:1 recording.



First thing to notice is that 3x3 bining produces an image that is not zoomed like 1:1 and that it has a reduced height (1920x648).

Now the corresponding crops to see more details of each:



The 3x3 recording shows better definition than the stretched images but not as high as 1:1.
The 3x3 recording shows a little less color saturation.
The 3x3 recording shows less noise.

This 3x3 recording module gives a higher image quality for the situations in which the zoom (3x) cannot be used.  The restricted resolution of 1920x648 can be maxed out to 1920x672 by changing the aspect ratio to almost 5:3.  This gives a usable video of 1920x665.

Here are some sample videos recorded with stretch mode, at 3X3, and 1:1 mode.  The videos where slowed down to 25% speed by twixtor and slightly sharpened.

Stretch

3x3 bining

1:1 Recording

[RenatoPhoto]

@A1lex:
Do you think it is still possible to find new settings for  CMOS/ADTG/Digic that could lead to larger height on the 3x3 bining settings.  Right now it is limited to 672 px height. 
Have you reached then end of possibilities to improve this recording method?
I ask because this seems like a very useful finding and maybe others can explore further if you think there is still room for improvement.

[a1ex]

Yes, there is still a lot of room for improvement, and probably lots of hidden surprises. For example, clicking on g3gg0's signature gives you this. The first post also has some useful hints about where to start, and the big ISO research thread has a lot of information that may be relevant here as well. The mv1080 thread for EOS M is another gold mine, in particular if you want to port this module on other camera models, and may be a little easier to grasp by those with less reverse engineering experience.

BTW, just noticed the latest adtg_gui no longer loads on vanilla crop_rec builds. I can fix it if there is interest in experimenting with this module (though it's highly recommended that one knows what to do if things go wrong, and being able to compile from source is probably a good indicator of such knowledge).

[RenatoPhoto]

Well certainly it would help if adtg_gui  is required to to try some register modifications.  I would do it if I knew what registers and what range to try.
Currently I have loaded Iso_regs and will probably try some of the iso changes..

[a1ex]

The known ADTG/CMOS registers are documented in the source code:

https://bitbucket.org/hudson/magic-lantern/src/iso-research/modules/adtg_gui/adtg_gui.c

Searching for adtg_gui on the forum will give additional tips, and trying to reproduce the existing findings is probably the best way to get started.

Porting to 6D and 500D should be straightforward, see the links from first post. Other cameras may be similar.

[RenatoPhoto]

This is the most straight forward summary of the registers posted by you for 5d3 here (The code on adtg_gui.c just shows how extensive is the information so far obtained.  ):

http://www.magiclantern.fm/forum/index.php?topic=10111.msg145036#msg145036      
April 14 2015   

For 5D3, a configuration that appears to work is:
      
Code: [Select]      
CMOS[1]                 0xB8B           vertical position and size      
CMOS[2]                 0x10E           horizontal position and downsizing factor      
CMOS[6]                 0x170           ISO related? pink highlights without it      
ADTG2[0x8000]           0x5             it's 5 in zoom mode and 6 in 1080p      
ADTG4[0x8000]           0x5             same      
ADTG2[0x8806]           0x6088          without this, you get some weird artifacts      
                                        note: ADTG4[0x8806] should not be changed (default 0x6048)   

[RenatoPhoto]

Also I found this on on Crop_rec code specific to 3x3:

           

Code: [Select]

/* 3x3 binning in 720p (in 1080p it's already 3x3) */
            case CROP_PRESET_3x3_1X:
                /* ADTG2/4[0x800C] = 2: vertical binning factor = 3 */
                adtg_new[0] = (struct adtg_new) {6, 0x800C, 2};
                break;


and this:

           

Code: [Select]

/* 3x3 binning in 720p */
            /* 1080p it's already 3x3, don't change it */
            case CROP_PRESET_3x3_1X:
                if (is_720p())
                {
                    /* start/stop scanning line, very large increments */
                    cmos_new[1] = PACK12(8,29);
                }
                break;

and this on adtg_gui.c:

Code: [Select]

static int crop_mode_reg(int reg)
{
    if (regs[reg].dst == DST_CMOS)
    {
        switch (regs[reg].reg)
        {
            case 1:                     /* CMOS[1]: vertical position and size */
                return (video_mode_resolution)
                    ? PACK12(14,10)     /* 720p,  almost centered */
                    : PACK12(11,11);    /* 1080p, almost centered */

            case 2: return 0x10E;       /* CMOS[2]: horizontal position and downsizing factor */
            case 6: return 0x170;       /* CMOS[6]: ISO related? */
        }
    }
    else if (regs[reg].dst == 2)        /* ADTG 2 */
    {
        switch (regs[reg].reg)
        {
            case 0x8000: return 5;      /* it's 5 in zoom mode and 6 in 1080p; this also overrides ADTG4 */
            case 0x8806: return 0x6088; /* without this, you get some weird artifacts; this should only go to ADTG2, not 4 */
        }
    }

    return 0;
      


So then I realize that I dont know which registers should be changed to try to increase the vertical resolution of the resulting video in 3x3 bining.

I am not a coder so I will leave this to those who have a better understanding of what is going on.

[dfort]

Got the crop_rec module working on the 700D and it was pretty easy to do--or let's just way it was mostly stupid luck. It is working just like on the EOSM, including the vertically stretched 3x3 preview that @rburne noted as needing fixing. In a way it works better than the EOSM because it can do 50p/60p "slow motion" in H.264 and even raw video, though of course it is limited by the SD card write speed but switching to 10bit helps with that.
[EDIT - Just test H.264 and uh, never mind. frame size is 1280x720 and the image is stretched vertically.]

I followed the rbrune pull request for the EOSM which means that it has the same limited options as the EOSM. I'll be doing some tinkering on a 5D3 soon so I'll finally get to see what 1:1, 1x3 and 3x1 does and if it is applicable to the 700D. Anyone have any thoughts on this?

I added new sections for the 700D so it won't break 5D3/EOSM functionality but it looks like several sections can be combined. I'd like to look into these things before making a pull request but if anyone wants to see my work in progress:

https://bitbucket.org/daniel_fort/magic-lantern/branch/crop_rec-700D_experiments

Here are details of how I did it. First of all, this is the important stuff:

Code: [Select]

    else if (is_camera("700D", "1.1.4"))
    {
        CMOS_WRITE = 0x17A1C;
        MEM_CMOS_WRITE = 0xE92D41F0;
       
        ADTG_WRITE = 0x178FC;
        MEM_ADTG_WRITE = 0xE92D43F8;
So where did I find these numbers? I looked at the EOSM numbers:

Code: [Select]

    else if (is_camera("EOSM", "2.0.2"))
    {
        CMOS_WRITE = 0x2998C;
        MEM_CMOS_WRITE = 0xE92D41F0;
       
        ADTG_WRITE = 0x2986C;
        MEM_ADTG_WRITE = 0xE92D43F8;
Ok--where to find CMOS_WRITE. I compiled a version of the iso_research branch to get the adtg_gui module for both the EOSM and 700D so I can see the registers side-by-side, started hunting and got totally lost. Then I remembered dmilligan's advice, look at the code.

adtg_gui.c

Code: [Select]

    else if (is_camera("EOSM", "2.0.2")) // from 1%
    {
        ADTG_WRITE_FUNC = 0x2986C;
        CMOS_WRITE_FUNC = 0x2998C;
    }
...
    else if (is_camera("650D", "1.0.4"))
    {
        ADTG_WRITE_FUNC = 0x178FC; //"[REG] @@@@@@@@@@@@ Start ADTG[CS:%lx]"
        CMOS_WRITE_FUNC = 0x17A1C; //"[REG] ############ Start CMOS"
    }
    else if (is_camera("700D", "1.1.4"))
    {
        ADTG_WRITE_FUNC = 0x178FC; //"[REG] @@@@@@@@@@@@ Start ADTG[CS:%lx]"
        CMOS_WRITE_FUNC = 0x17A1C; //"[REG] ############ Start CMOS"
    }   
Two down two to go. Gee almost too easy. I kept the 650D code in that code snippet because this might get interesting. See how the values are exactly the same as the 700D?

Next, how to find the MEM_CMOS_WRITE and MEM_ADTG_WRITE? Lost again. So I looked up those addresses on the EOSM disassembly. I got 6,146 hits for 0xE92D41F0 but comparing the two disassembly files side-by-side, they were all in the same places on both cameras so I went with the EOSM numbers and it worked. Totally lucked out. Now I know this is not the right way to find these addresses but in the end the only thing that really matters is that it works. Still, it would be nice to learn the right way to do this in order help get other cameras working with crop_rec.

How about the 650D? I got a ROM1.BIN from that camera so I disassembled it. The code is very similar to the 700D but the MEM_CMOS_WRITE and MEM_ADTG_WRITE address seems to be different and it will take some searching to figure it out but it looks doable.

The crop_rec module is one of those Magic Lantern features that you didn't know you needed until you try it out. It also evolved into something that doesn't resemble its name any more. A few days ago a1ex asked if it is time for a rename so if there are any non-coders who know about marketing, here's your chance to contribute to ML development. Just remember there is an 8-character limit on the module's name.

[aschille84]

Wow, great progress!

..so if there are any non-coders who know about marketing, here's your chance to contribute to ML development.

I think a similar function is called center scan mode on Sony cameras

[Danne]

Great find dfort!

[DeafEyeJedi]

Indeed another great performance done by the legendary @dfort!

[RenatoPhoto]

@dfort I am sure many users will be very happy of your findings.  Thanks for your great help.

[RenatoPhoto]

I like crop mode recording but could see it as magic crop module 

[andy kh]

Well done @dfort

[Lars Steenhoff]

Are there any builds with latest unified + crop? 

[Roberto Mena]

Im sorry crop mode has been around for ML for a while now, right? So what's the big deal with this new update?

[Walter Schulz]

H.264 crop mode ...

[Roberto Mena]

Ooooh. Thanks. By the way, how do you guys shoot in crop mode if your moving the camera around its gotta be super hard to frame your subject with so little of the actual image is seen in the camera's LCD screen? Is there a way to shoot in crop mode in camera but the video output to an external monitor would look regular, i.e. non-cropped?

[anto]

same problem (stesso problema?    ) )
I think the better solution is ML greyscale on the 5D and clean out on the external lcd. with 1.2.3 course