Pixel binning patterns in LiveView

[Levas]

Jup
I also needed to adjust CMOS 7 (I did that in camera in the crop_rec menu, I use deltahead 4 for that  , I needed to adjust by 13 decimal increments.)

A little test, I disabled the crop_rec preset and started the camera clean and use 'ADTG Registers' override in debug menu.
Now I go in non zoom video mode and change register 8000 value from 6 to 5 and refresh...Ok, looks a bit messy now.
But I can fix that by overriding CMOS 7, CMOS 7 was 0x0 and changing it to 0x12 in ADTG override function fixes the view.

[Danne]

Ok, will try altering cmos7. I suspect I'll find a non squeezed image if it cleans up but who knows.
By the way. Are you getting the same result if doing it in 4k? I suspect it could behave differently when not maxed out?

[Danne]

An attempt. Result is 4000x696 but 1x1:

Code: [Select]

case CROP_PRESET_4K_3x1_EOSM:
                cmos_new[5] = 0x200;            /* vertical (first|last) */
                cmos_new[7] = 0x500;
                break;

Code: [Select]

     case CROP_PRESET_4K_3x1_EOSM:
adtg_new[0] = (struct adtg_new) {6, 0x800C, 2};
                adtg_new[1] = (struct adtg_new) {6, 0x8000, 5};
break;

Code: [Select]

        case 0xC0F06804: return 0x4a6040a;
        case 0xC0F06824: return 0x4ca;
        case 0xC0F06828: return 0x4ca;
        case 0xC0F0682C: return 0x4ca;
        case 0xC0F06830: return 0x4ca;     
        case 0xC0F06010: return 0x45f;
        case 0xC0F06008: return 0x45f050f;
        case 0xC0F0600C: return 0x45f045f;
        case 0xC0F06014: return 0x405;
        case 0xC0F0713c: return 0x320;
case 0xC0F07150: return 0x300;
Opened up in Mlv App:


Is my eosm the wrong cam to try with?

One thing I can tell you is that changing 800c has no effect while 8000 is set to 5. Could this be the issue? What branch are you using Levas when compiling?         

Following has no effect:

Code: [Select]

adtg_new[0] = (struct adtg_new) {6, 0x800C, 0};

Code: [Select]

adtg_new[0] = (struct adtg_new) {6, 0x800C, 2};

Code: [Select]

adtg_new[0] = (struct adtg_new) {6, 0x800C, 4};
Is it timer related??
If I skip cmos 5 I get only half the image showing but maybe that´s what needs to be stretched?



Edit:

Code: [Select]

A little test, I disabled the crop_rec preset and started the camera clean and use 'ADTG Registers' override in debug menu.
Now I go in non zoom video mode and change register 8000 value from 6 to 5 and refresh...Ok, looks a bit messy now.
But I can fix that by overriding CMOS 7, CMOS 7 was 0x0 and changing it to 0x12 in ADTG override function fixes the view. When you do this you are getting into x3 zoom mode right?




EDIT:
@a1ex. Any thoughts on this? It´s like it´s read in 1x1 mode but still able to record squeezed??
The files from Levas again:
https://drive.google.com/drive/folders/11P6HUC3xNHGNSGLFnV42CctoQjKn9WqY

[Levas]

Eos-M is different and I don't know what's available and what not and how it reacts.
But can you cycle through different zoom modes (1x, 5x and 10x) with eos-m ?
I can change registers that mess with how live view looks (stretched, non stretched etc.), but I can also use the magnify button to cycle through non-zoom, 5x zoom and 10x zoom mode.

And I can get also jagged line free image with value 6 for register 8000. But I have to adjust it with CMOS 7 to work in 5x zoom mode.
So maybe the best approach for now is trying to  get it to work in 5x zoom mode with value of 6 for register 8000 (but not sure if 5x zoom mode is something that exists in eos-m  )

[Levas]

Edit:

Code: [Select]

A little test, I disabled the crop_rec preset and started the camera clean and use 'ADTG Registers' override in debug menu.
Now I go in non zoom video mode and change register 8000 value from 6 to 5 and refresh...Ok, looks a bit messy now.
But I can fix that by overriding CMOS 7, CMOS 7 was 0x0 and changing it to 0x12 in ADTG override function fixes the view.
When you do this you are getting into x3 zoom mode right?

I think that is right, I start in non zoom mode(so 3x3)
After changing register 8000 and CMOS 7, I see a image that looks like horizontal every single pixel is read and it’s vertical stretched, because lineskipping is still on from non zoom mode.

[Danne]

Thanks for checking in. Eosm can do pretty much anything going into zoom modes etc. It can´t go into x5 or 8000, 5 and still keep the stretch mode so I think I have to try fixing the problem in non crop modes right now. I will try my 100D when I get the chance and see if it behaves more like your 6D.

[Danne]

Finally!
I had to put eosm into mv720p and change 6804 accordingly. Then FPS override to 24 and set cam to x5 zoom mode:
Before:


After:


Got damn, this took a while but think it will be a gamechanger. Thanks Levas!!

[70MM13]

wow!
there's so much happening these days, it could make you dizzy!

[reddeercity]

Had at look at this before on the 5d2 , but never notice a difference until now, 
I zoom in 160% on a 3840x1872 in 3xcrop_mode(line skipping) and the lines are cleaner (sharper) then FHD .


160perscent_3840X1872_3xCrop_+FHD_line_skipping.png

Just went in to 3xcrop_mode set ADTG12[100c] 0x05=>0x06 , but I can't clean it up with CMOS[2] CMOS[5] must be others I need to find.
On the bright side , can get 5632x3204 @ 12.3fps (5632x1068) the nice thing about crop_mode  I'm not limited to 416x3=1248 vertical any more
but's that's also causing the problem with CMOS's getting a clean image .
I may have to extend  c0f0713c & c0f07150 for the 3204 line skipping window



5632x3204_M02-2336_frame_67.png
5632x3204_12.38fps_M02-2336.mp4

[Levas]

@Danne, Great you got it working on Eos-m    no jagged lines.

[DeafEyeJedi]

Beautiful collaborations from @Danne & @Levas on achieving this remarkable milestone and indeed it’ll definitely be a game-changer!

[Danne]

Posted a new version for the eosm:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg210108#msg210108

Seemed all that was needed was to set x5 zoom. No need for mv720p  .

[reddeercity]

Some interesting images of the line skipping & pixel binding on 5d2 zoomed in to 3700%
First is the 4k line skipping squeezed & the second is un-squeezed

4096x590 (squeezed 3700% zoom)

No_pixel_stretch_3700zoom.png

4096x1770 (un-squeezed 3700% zoom)

300_precent_Vertical_pixel_stretch_3700_zoom.png

[Danne]

But you could also keep the vertical resolution enlarge the image horizontally to get *interpolated* 5208x2214 (of course, with much lower image quality, compared to a 5208x2214 1:1 readout) or maybe something in-between (likely a better compromise).

Wtf. I need to pay attention. Upsampling seems to be way better than I imagined. Check following file in adobe camera raw. I manipulated the default scale tag to upsample instead of downsample 1x3 footage. 5K output from 1x3 binning. Original file is 1712x2184 Canon EOS m that is. Please tell me if you see any disturbing edges cause I can´t. And where is aliasing?
https://bitbucket.org/Dannephoto/magic-lantern/downloads/1_x3_M10-1218_frame_1.dng

Image sample


100% zoom



By the way. I started using exiv2 for metadata alterations. Exiftool is a bit picky these days with altering tags:

Code: [Select]

find . -maxdepth 1 -mindepth 1 -iname '*.dng' -print0 | xargs -0 exiv2 -M"set Exif.Image.DefaultScale Rational 3/1 1/1"

In 5D mark III we have
"1x3_17fps_1920x3240",

5760x3240 that is...

[dfort]

Let's see if I got this.

Original file in ACR (I've got version 11.1 and the white balance is a bit different but whatever)



Apply some black magic:

Code: [Select]

find . -maxdepth 1 -mindepth 1 -iname '*.dng' -print0 | xargs -0 exiv2 -M"set Exif.Image.DefaultScale Rational 3/1 1/1"
Looks good.



Don't see any focus pixels but ACR tends to smooth them out, let's see what dcraw does--it usually shows all the flaws.

Code: [Select]

dcraw -T 1_x3_M10-1218_frame_1.dng


That's quite amazing -- especially for an EOSM!

[Levas]

Must admit that this example looks very good, but then there is not that much in focus, very small depth of field 
Try to impress me with some example with more depth of field 

[dfort]

...very small depth of field...

Said the guy with the full frame camera. 

What would impress me is if all of the various cameras could be merged into Danne's experimental branch. You can do 1x3 on the 6D, right?

[Danne]

Except the much higher resolution gained with 1x3 binning I´d say it´s also a clear winner regarding aliasing, resolutionwise. 5k 3x1 do look alright too:
Masc already put in the upsampling factor into Mlv App so any 1x3 binning footage should now be upsampled automatically. Great!

Test image done in haste and on free hand so include a sloppy factor into these images. Feel free to share your own findings.

Motif:


mv1080p 1736x1160


5K 3x1 24fps


1x3 1704x2176

[Levas]

@Dfort
Gotta love low depth of field 

I can do 1x3 on 6d.
I don’t know about Danne’s experimental brand.
If I have a link to the source of the crop_rec, I can see if I can fit some 6d presets in.

[Danne]

Branch has been reposted at least ten times 
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959

Post is old but links are updated.

[70MM13]

this is so great that my friend is buying an eos m just for this!

he's absolutely new to magic lantern, so I'm wondering if you guys can make a really clear and easy to follow guide for absolute newbies to get this working on their cameras?

I have a feeling that there will be a lot more like him now!

excellent work!

[Danne]

Not the easier preset to work with. Gonna be badass on 5D3.
With lowered res it's working with eosm. Start off something like this:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg210418#msg210418

[theBilalFakhouri]

I am wondering how 1x2 Binning will look like if we got it. @a1ex do you have any idea? Will we lost a color channel? What the color pattern ( a.k.a Bayer channel?) on the sensor that will be when using 1x2 Binning?

[Levas]

The second example of Danne looks more familiar with the results I'm getting with stretching footage on the 6d.

Curious if Alex can come up with something brilliant to unstretch the horizontal binned files.

If somehow the raw file can be reconstructed to a new raw file according to the binning pattern, then you have a good starting point:


After that, I would say that the middle pixels can be left alone and that the outer ones(left and right one of each three binned pixels) have to be somehow averaged with one or more neighbours(outside the 3 binned pixels it is in) in the same color channel. That would give a raw file that probably best approach the original one.
Only thing is, we need someone with the skills to write something that can do this 

[IDA_ML]

5k 3x1 do look alright too:

Danne,

No, they don't ! It's not only aliasing that spoils the game with 5k 3x1.  Look at the color noise and the color artefacts in your 5k 3x1 example and compare them with the 1x3 shot which is so much cleaner.  If you film other scenes, e.g. landscape videos with a lot of fine detail, the difference will be much more obvious and I am sure, you will not like the 5k 3x1 result.  At least I didn't.

I also performed several tests and in my experience and honest opinion, the 1x3 sampling method is the way to go.  You got it working on the EOS M already and Bilal got it working on the 700D several months ago.  If it could be implemented also in other cameras with proper aspect ratios and hopefully full-sensor readout, that would be a real game changer whenever ultimate FHD video quality is aimed at.  This is already the case with the 5D3.

By saying that, I do not mean that we should totally abandon the 4k and 5k 3x1 modes.  In certain situations (brightly lit scenes with not so much fine detail in them), they are perfectly usable - very stable and provide longer recording times at high resolutions.  They work well with Dual ISO too.  You get even slightly cleaner footage when using Dual ISO.  Also preview is better.  So, it's nice to have these modes too.