Canon 6D

[DOP]

Without the need to stretch the video, the max resolution in 60 fps is 1688 x 754, if you want to use that mode for 16:9 aspect ratio raw recording, you end up with 1340 x 754 @ 60fps.

Tried this out and the results are significantly better than the typic ML 720p. The aliasing is almost entirely gone and similar to the 1824x1026 30fps mode. However, there is a large crop top and bottom which make this exact result unusable for me. Is there a way to get these results without the vertical crop?

[baladev]

Thank you for the information, Levas, as always..

Inspired by anamorphic video preset on EOS M, I've decided to investigate a similar one we have on 6D. Since I mostly film in 16:9, I was interested in maximum resolution that would give me this proportions. Since our preset's maximum vertical resolution is 1842, I calculated that 1088 horizontal resolution would give me 16:9 video after stretching (1088*3=3264). So, I set 1088x1842 with 1:2 aspect ratio chosen (to get maximum vertical resolution). I also filmed a sample in normal full frame 1824x1026 for comparison. After stretching the anamorphic sample, this is what I got:




Here I over imposed the anamorphic sample over the 1824x1026 one, I also colored the anamorphic frame in orange, so it's easier to see.
I's clear that anamorphic takes only a crop of the sensor, but it is a large crop, considerably larger than what you would be able to film continuously with in x5 mode. I calculated crop factor, and it's only ~ 1.7 (1 and 2/3), slightly bigger than Canon's aps-c crop factor, so not too bad and better than at least X3 crop we get in x5 mode.

If you wonder how resolutions compare, here are illustrations of both:
1088x1842 anamorphic



1824x1026




I know Levas said that 1842 is the maximum vertical resolution we can get on 6D without corrupted frames. EOS M can film up to 1998 vertical , continuous at 1944. I tried it yesterday and I saw a couple pink frames in the footage (are pink frames same as corrupted?), so I need to investigate further. I will report back.

[Levas]

Is there a way to get these results without the vertical crop?

Unfortunately not. 60fps in 16:9 with full sensor width (1824 pixels) is not possible.
Horizontal resolution, vertical resolution and fps are the factors in play for what is possible.
If you want faster fps, you have to sacrifice horizontal or vertical resolution.
If you want more horizontal resolution, you have to sarcifice vertical resolution or fps.
If you want more vertical resolution, you have to sacrifice horizontal resolution or fps.
Already made a compromise by lowering horizontal resolution to 1688 pixels wide, to get some more vertical resolution.
Couldn't get any lower then 1688, weird stuff happened when testing, otherwise a 1440 x 810 @ 60fps (16:9 aspect) was possible, but somehow 1688 seems to be as low as we could get on 6d for now.

Another thing, horizontal resolution takes less resource of the cam then vertical, since horizontal is readout with 4 columns at one time.
So you can sort of say that you have to sacrifice 4 pixels of horizontal resolution, to get 1 pixel extra vertical resolution.
That's the reason why you see all these high resolution wide crop ratios 1:2.40 and such in crop modes on the different cameras.

Another thing to have in mind is that the 6D sensor reads 4 horizontal pixels at once, and the 5d3 sensor does 8 horizontal pixels at once (So more complex sensor, which can read twice as fast).
This means basically that the 6d can do the same as the 5d3, but only at half the resolution or half the frame rate 

[Levas]

I know Levas said that 1842 is the maximum vertical resolution we can get on 6D without corrupted frames. EOS M can film up to 1998 vertical , continuous at 1944. I tried it yesterday and I saw a couple pink frames in the footage (are pink frames same as corrupted?), so I need to investigate further. I will report back.

I do have a working 1688 x 1996 @ 25 fps mode   I probably can squeeze out some more vertical resolution if I lower the 25 fps to 24 fps. Will probably give about 1688 x 2080 @ 24 fps.
What do you prefer, 24 or 25 fps ?

Edit: Pink frames can be considered as corrupted, or can you fix them in post ? I think all frames that can not be fixed in post, can be count as corrupted frames 

[DOP]

Unfortunately not. 60fps in 16:9 with full sensor width (1824 pixels) is not possible.
Horizontal resolution, vertical resolution and fps are the factors in play for what is possible.
If you want faster fps, you have to sacrifice horizontal or vertical resolution.
If you want more horizontal resolution, you have to sarcifice vertical resolution or fps.
If you want more vertical resolution, you have to sacrifice horizontal resolution or fps.
Already made a compromise by lowering horizontal resolution to 1688 pixels wide, to get some more vertical resolution.
Couldn't get any lower then 1688, weird stuff happened when testing, otherwise a 1440 x 810 @ 60fps (16:9 aspect) was possible, but somehow 1688 seems to be as low as we could get on 6d for now.

Another thing, horizontal resolution takes less resource of the cam then vertical, since horizontal is readout with 4 columns at one time.
So you can sort of say that you have to sacrifice 4 pixels of horizontal resolution, to get 1 pixel extra vertical resolution.
That's the reason why you see all these high resolution wide crop ratios 1:2.40 and such in crop modes on the different cameras.

Another thing to have in mind is that the 6D sensor reads 4 horizontal pixels at once, and the 5d3 sensor does 8 horizontal pixels at once (So more complex sensor, which can read twice as fast).
This means basically that the 6d can do the same as the 5d3, but only at half the resolution or half the frame rate 

Good info, thank you. I assumed there was some kind of relationship like that.

So you're saying that there was "weird stuff" happening at 1440 x 810 @ 60fps? What type of stuff? Corrupt frames, buggy ML behaviour?

To clarify, what is the best 16:9 60fps resolution we can get without losing vertical? Just the ones in your presets that result in lots of aliasing?  I don't mind if the resolution is lower since the raw is crisper than the default h.264 and can be upsized pretty cleanly but I don't want to lose any FoV or have aliasing.  I've played around a bit but it's time consumer and I know you've done lots of great work in this area so probably easier to ask. Apologies for all the questions, just trying to wrap my head around it all and keep track of all the different options / configurations.

[baladev]

I do have a working 1688 x 1996 @ 25 fps mode   I probably can squeeze out some more vertical resolution if I lower the 25 fps to 24 fps. Will probably give about 1688 x 2080 @ 24 fps.
What do you prefer, 24 or 25 fps ?

Oh sweeeeet! Bloody genius. Could we have both? If not, 1688 x 2080 @ 24 fps please.
2080 vertical would give 3698x2080 vs 3264x1842 we have now in 16:9, and only ~1.5 crop (like Sony APS-C) not bad at all.
If my math is correct for 16:9 it would be 1232x2080 anamorphic, which is 61.5Mb/s at 24f, which I think is close to the writing speed limit we have. In x5 mode maximum res. I was able to get continuous recording with was 2000x1124, which gives 56.2Mb/s at 25 frames. I use Sandisk Extreme Pro.

Pink frames can be considered as corrupted, or can you fix them in post ? I think all frames that can not be fixed in post, can be count as corrupted frames 

No, you definitely can't fix them in post..
I was referring to your original post, in which you said you couldn't get higher res than 1842 without corrupted frames, I was wondering if you meant pink frames or something else..

So, anamorphic preset works in x5 zoom mode, even though we don't set it, right?

.. also, is it possible to control the area that's being captured somehow? Would be great to move the region to the middle of the frame to capture the sharpest part of a lens. The bottom part is very distorted with wide angle lenses especially.

[Levas]

Fine-tuned the 1x3 mode a little
1632 x 2052 @ 25fps
1632 x 2144 @ 24fps 
Both are for use in normal 1080P non zoom mode.
When activated, be sure to press the 'menu' button once, to enter canon menu and press it again to go back to liveview, this way all registers are set for this preset.
When used in 5x zoom, shuttertime values are messed up and horizontal pixelbinning is not done.



Link to this crop_rec module for 6d:
http://drive.google.com/file/d/1Z7yxSE-zmQET9g-E-YDzKrpfzxlzo3yy/view?usp=sharing Edit, build removed, didn't work as expected.
New build:
http://drive.google.com/file/d/11e8YcImfRmpgi4rWWLUVjp38_7e-duws/view?usp=sharing

For those who are not familiar with 1x3 mode:
1x3 mode is just like normal 1080p mode, but instead of line skipping, each vertical line of resolution is recorded.
So you end up with a weird stretched out frame which needs to be fixed in post.
You need to set up an aspect ratio of 1:2 in RAW video menu to be able to make use of the full resolution of this crop_rec preset.
There are two options in post.

Option 1: For video free from lineskipping aliasing, you can divide vertical resolution by three and adjust it to that, so 1632 x 2144 will become 1632 x 714 of resolution.
By using this method, you should end up with frames free from the lineskipping aliasing , because no lineskipping has happened.
Hint, MLV_App has an option called Transformation, here you can multiply the height of the frames by 0.33, giving you the proper dimensions.

Option 2: For very high resolution video, stretch horizontal resolution by a factor of 3, so 1632 x 2144 will become 4896 x 2144 of resolution.
Ofcourse this doesn't look as good as real 4896 x 2144 resolution, but also not bad, since the vertical resolution is real and the horizontal resolution is from binned pixels.
If you want to end up with 16:9 aspect ratio high resolution, select 1264 horizontal resolution in raw video menu, which will create 3792 x 2144 resolution in post.
Hint, MLV_App doesn't have an option for 3x horizontal stretch, but you can set desired resolution on output settings, so that's where you can set 3792 x 2144 resolution.

Some more info:
First 1688 pixels wide was the lowest I could get, but I only tested in steps of 64 pixels at a time and 1624 didn't work right.
Now I've tested the range within 1688 - 1624 and 1632 pixels horizontal seems to work properly.
If I go lower then 1632 the whole right side of the frame gets slowly flat, like less contrasty and gets a purple tint.
And when I tried to go even lower, there is no image at all, all black Canon liveview and black Magic Lantern Preview, just a whole lot of nothing 

So now 1632 seems to be the horizontal limit and I know which A timer to use for, I could calculate the necessary B Timer value for 25fps and 24fps.
And of course the maximum vertical resolution which comes with that.
When I tried a little more vertical resolution, I started to get 2 corrupted frames at the beginning and the annoying warning messages on display.
When I tried much more vertical resolution, all frames are corrupt, not only the first two ones, but all of them 
The resolutions here should work properly I've seen no corrupted frames, but can't hurt to test some more.

[Danne]

Can you share code. Are you getting corrupted frames in 1x3 binning or corruption free?

[Levas]

From the few times I tested today, they were corruption free 
Will send the source to you today.

[mvrck]

Does the 1x3 mode compensate for the lack of an AA filter in the 6D? I mean, does it hide the aliasing as well as when used on AA-filtered cameras?

[Danne]

Does the 1x3 mode compensate for the lack of an AA filter in the 6D? I mean, does it hide the aliasing as well as when used on AA-filtered cameras?

Pretty much yes.

[baladev]

1632 x 2052 @ 25fps
1632 x 2144 @ 24fps

I'm speechless. I will be all over this soon, testing and reporting back.

but instead of line skipping, each vertical line of resolution is recorded.

For video free from lineskipping aliasing

Sorry, but isn't this a contradiction? Or am I missing something?
My understanding is that the difference between 1X3 mode and x5 zoom mode is that the latter one records everything, all lines and columns and the former one bins the columns? Neither should produce aliasing? And in my experience don't, or maybe very small, definitely no funny false color pixels along high contrast edges.

I know the option 1 you described is used by many, but in my opinion this isn't the best if the highest details are needed because it throws away 2/3 of vertical resolution. I prefer stretching video three times horizontally. This doesn't have such a big impact on the final image, since human eyes resolve more resolution horizontally than vertically.

Levas, thank you so much for this, you are a stud!

I myself, after testing all different kinds of raw recording options, decided for myself to stick with these two modes:
- full frame option when no crop is required and I need the most stable option (haven't tested 1x3 enough to trust it as much, for me it's still bleeding edge for now). But, it produces an occasional moire and false colored pixels.
- 1x3 When I need the best resolution and the cleanest picture free from artifacts and can re-shoot. Pushes hardware much harder at the highest resolutions, fastest cards are must. Final files are larger and require more processing times.

Danne - I haven't tested this new edition of crop_rec from Levas, but the previous one I tested quite a bit at 1088x1842 (max vertical res. for this version) and never got corrupted frames, apart from the customary 2nd pink frame, which I get on my 6D in full frame mode as well.

[Levas]

Does the 1x3 mode compensate for the lack of an AA filter in the 6D? I mean, does it hide the aliasing as well as when used on AA-filtered cameras?

But downside is, the standard Canon liveview is not working with this crop_rec preset, so instead you'll see a liveview image created by magic lantern, which has a slow refresh rate and is lower resolution compared to Canon's liveview.
So the 1x3 method is a nice option to have, but not usable for all types of video shooting, because of the lack of proper liveview.

[Levas]

@Danne

Here is the most important part of the source:

Code: [Select]

static inline uint32_t reg_override_1x3_24FPS(uint32_t reg, uint32_t old_val)
{
    switch (reg)
    {
        /* raw resolution (end line/column) */
        case 0xC0F06804: return 0x87e01ba; //1632 x 2052 - 24 fps
       
        case 0xC0F06824: return 0x1ce;
        case 0xC0F06828: return 0x1ce;
        case 0xC0F0682C: return 0x1ce;
        case 0xC0F06830: return 0x1ce;
       
        case 0xC0F06010: return 0x1d0;
        case 0xC0F06008: return 0x1d001d0;
        case 0xC0F0600C: return 0x1d001d0;
       
        case 0xC0F06014: return 0x8f5; //24 fps for 1x3

        case 0xC0F0713c: return 0x87e;
        case 0xC0F07150: return 0x87e;
       
    }

    return 0;
}

Most important here is that there needs to be enough room between the values of the B-timer, register 6014 and the vertical resolution in 6804.
6014 = 0x8f5 and vertical resolution in 6804 is '87e'.
The vertical resolution always needs to be less then the value of 6014, in this case the vertical resolution value is 0x8f5 - 0x87e = 0x77 lower then B-timer value.
I've tried raising the resolution to 0x88e, which means there is only a difference of 0x67 between B-timer and resolution, but that gave me corrupted frames.

Another important thing, if I remember correct, is that my crop_rec presets got more stable when I use the same value for registers 713c and 7150 as the value for vertical resolution in 6804
In this case 6804 = 0x87e01ba
So 87e for vertical resolution and I use these exact same values for 713c and 7150.
What also works for register 713c is using vertical value from 6804 +1, so in this case 0 x 87f also works.
And sometimes it helps to lower the 7150 a little. It's a bit of trial and error but works for me.

How does this part look in your 1x3 code ?

[Levas]

Sorry, but isn't this a contradiction? Or am I missing something?
My understanding is that the difference between 1X3 mode and x5 zoom mode is that the latter one records everything, all lines and columns and the former one bins the columns? Neither should produce aliasing? And in my experience don't, or maybe very small, definitely no funny false color pixels along high contrast edges.

You are right in saying that both 1x3 and 5x zoom mode both are free of aliasing (or at least the aliasing caused by line skipping).
I think I said the same in the lines you quoted, but maybe I've written it down in a way that it is not proper English 

[dfort]

Can you share code.

Will send the source to you today.

How about using Bitbucket to share code?

Yesterday I made a fork of Danne's repository and put in the crop_rec module from Levas in it just to see if works. Next step is to merge the two crop_rec sources along with any additions so the 6D will work alongside the other cameras that are already ported to Danne's bleeding edge branch.

Once the dust settles it would be great to clean it up and merge into the main repository.

Speaking of dust settling -- Levas just posted the settings for 1x3 so we should add that to the mix.

[baladev]

Just a real quick update..
A couple of short takes, 2 minutes each at 1264x2144 (for 16:9). Continuous, 57.5 Mb/s. Second frame is pink (normal for my cam), no corruption apart from that. But, noticed vertical lines in both takes, different patterns in each take. Here are screenshots from both videos:

[Levas]

  That's exactly the weird stuf when I go too low in horizontal resolution.

I remember this happening before with earlier crop_rec modes which where not in 5x zoom mode.
This never happens in the 5x zoom mode, let me check some stuff, maybe I can make it work in 5x zoom mode, with binning.

[Levas]

Had some time to quickly alter the presets for use in 5 x zoom mode.
Normally in 5 x zoom mode, there is no horizontal pixelbinning done.
Due to recent discovery, we know which registers to alter.
https://www.magiclantern.fm/forum/index.php?topic=16516.msg212472#msg212472

So I made both presets for use in 5 x zoom mode, because we're moving to 5 x zoom, we get 8 pixels of extra resolution with the same register settings 
Added the 8183 and 8184 registers and used values for binning, seems to work over here, but as proven before, I'm not that good in testing 

Here's the new build (same place as the previous build, so it's replaced with the new one)
http://drive.google.com/file/d/11e8YcImfRmpgi4rWWLUVjp38_7e-duws/view?usp=sharing

Happy testing 

The vertical line issue Baladev posted, is not always very obvious to see on camera screen and seems to get worse over time the camera is on in that mode.
It's best seen on screen when you see a tonal change on the right side of the frame, as in Baladev first example, the right side has a purple haze showing.
These lines get worse over time this crop_rec is activated, not sure if it can show up in 5 x zoom, but never saw it happen in 5 x zoom before...

[Danne]

Check power timing regs regarding subtle corruption. I had similar issues but changed things around in here. SOmething was erased as well but some quick comparing should make things obvious:
        /* assuming FPS timer B was overridden before this */
        int fps_timer_b = (shamem_read(0xC0F06014) & (0xFFFF + reg_timing5));
        int readout_end = shamem_read(is_digic4 ? 0xC0F06088 : 0xC0F06804) >> 16;

        /* PowerSaveTiming registers */
        /* after readout is finished, we can turn off the sensor until the next frame */
        /* we could also set these to 0; it will work, but the sensor will run a bit hotter */
        /* to be tested to find out exactly how much */
        adtg_new[4]  = (struct adtg_new) {6, 0x8172, nrzi_encode(readout_end + 1 + reg_timing1) }; /* PowerSaveTiming ON (6D/700D) */
        adtg_new[5]  = (struct adtg_new) {6, 0x8178, nrzi_encode(readout_end + 1 + reg_timing1) }; /* PowerSaveTiming ON (5D3/6D/700D) */
        adtg_new[6]  = (struct adtg_new) {6, 0x8196, nrzi_encode(readout_end + 1 + reg_timing1) }; /* PowerSaveTiming ON (5D3) */

        adtg_new[7]  = (struct adtg_new) {6, 0x8173, nrzi_encode(fps_timer_b - 1 + reg_timing3) }; /* PowerSaveTiming OFF (6D/700D) */
        adtg_new[8]  = (struct adtg_new) {6, 0x8179, nrzi_encode(fps_timer_b - 5 + reg_timing2) }; /* PowerSaveTiming OFF (5D3/6D/700D) */
        adtg_new[9]  = (struct adtg_new) {6, 0x8197, nrzi_encode(fps_timer_b - 5 + reg_timing2) }; /* PowerSaveTiming OFF (5D3) */

        adtg_new[10] = (struct adtg_new) {6, 0x82B6, nrzi_encode(readout_end - 1 + reg_timing6) }; /* PowerSaveTiming ON? (700D); 2 units below the "ON" timing from above */

        /* ReadOutTiming registers */
        /* these shouldn't be 0, as they affect the image */
        adtg_new[11] = (struct adtg_new) {6, 0x82F8, nrzi_encode(readout_end + 1 + reg_timing4) }; /* ReadOutTiming */
        adtg_new[12] = (struct adtg_new) {6, 0x82F9, nrzi_encode(fps_timer_b - 1 + reg_timing4) }; /* ReadOutTiming end? */



I checked my code and there´s plenty room between 6014 and 6804.
Are these regs vital? Never use them in 1x3 binning:

Code: [Select]

        case 0xC0F06824: return 0x1ce;
        case 0xC0F06828: return 0x1ce;
        case 0xC0F0682C: return 0x1ce;
        case 0xC0F06830: return 0x1ce;

My experience with 713c and 7150 is somewhat random. They don´t need to be matched at all. I can do this:

Code: [Select]

        case 0xC0F0713c: return 0x79f + reg_713c;
case 0xC0F07150: return 0x50b + reg_7150;Still good. If I lower 7150 too much pic freezes or corruption but not really getting any better closing in on 713c.

[Levas]

        adtg_new[8]  = (struct adtg_new) {6, 0x8179, nrzi_encode(fps_timer_b - 5 + reg_timing2) }; /* PowerSaveTiming OFF (5D3/6D/700D) */
        adtg_new[9]  = (struct adtg_new) {6, 0x8197, nrzi_encode(fps_timer_b - 5 + reg_timing2) }; /* PowerSaveTiming OFF (5D3) */

Hmm, these are indeed a little different, -5 instead of -1, will check if that brings new possiblities.

Are these regs vital? Never use them in 1x3 binning:

Code: [Select]

        case 0xC0F06824: return 0x1ce;
        case 0xC0F06828: return 0x1ce;
        case 0xC0F0682C: return 0x1ce;
        case 0xC0F06830: return 0x1ce;

Not sure if they are vital, but as far as I know they work together with the A timer, the four registers are always 2 values lower then A timer registers in Canon standard modes.
So I always put them in my presets, 2values lower then A-timers,  not sure if they do much though 

[Danne]

Hmm, these are indeed a little different, -5 instead of -1, will check if that brings new possiblities.

They are different because I changed them at one time due to corruption.

[baladev]

Ran some tests with the new crop_rec module. Can't see thin vertical stripes anymore but the thick pink area on the right is still there. Seem to be of random width, sometimes thinner, sometimes thicker. Same resolution 1264x2144 at 24f. Filming indoors (mostly carpet and walls) was getting 56mb/s continuous, pointing the camera outside from a balcony resulted in 65mb/s orange indicator continuous if pointing at low detail objects like houses and roads and which would immediately turn red if pointing at trees. So, it's right on the borderline of what 6D can record.

Here are the processed dng frames, all from different takes. The outdoor ones show the pink area in the shadows/dark places.










.. forgot to add- 2nd frame is dark/corrupted in all takes. In outdoors scenes the 3rd frame has some pink noise on top also, apart from this no corruption.

[Danne]

Try set these regs to following in crop_rec.c. Too bad code isn´t easily accessible since we have testers around:

Code: [Select]

        adtg_new[8]  = (struct adtg_new) {6, 0x8179, nrzi_encode(fps_timer_b - 5) }; /* PowerSaveTiming OFF (5D3/6D/700D) */
        adtg_new[9]  = (struct adtg_new) {6, 0x8197, nrzi_encode(fps_timer_b - 5) }; /* PowerSaveTiming OFF (5D3) */

[Levas]

Made the changes Danne suggested, run the build on my cam and it didn't exploded, so it's safe to test.
Could record a clip with the 1x3 preset, haven't checked the files yet.
https://drive.google.com/file/d/1ltu1i9L2i2TiPiaNfk_oSHeczws6oVsh/view?usp=sharing

@Danne
Here's the original source, it's not that I don't want to share, it's more that it is a big mess inside 
https://drive.google.com/file/d/1mP0SQ7mv_7ff4EyM-evhIJQ-XKzKWXAs/view?usp=sharing

The presets we're testing are called 1x3 and 1x3_24FPS
Should look familiar, 1x3 preset is on line 1107
1x3_24FPS preset is on line 1140