Original discussion: http://www.magiclantern.fm/forum/index.php?topic=10111.msg118232#msg118232
I wanted to split the topic, but that would make the original discussion harder to follow, so I'm just copying the relevant parts here.
Quote from: Audionut on June 07, 2014, 03:09:59 PM
Finally finished stuffing around, and here is a good bunch of results. Enjoy!
https://www.dropbox.com/sh/ktc2kyabmozjofq/AAC7kSBnzX3E5cwoLn9nrsbYa
From the above data, I'll try to guess the
pixel binning factors from LiveView (and I'll ask SpcCb to double-check what follows):
My quick test, at ISO 6400:
gain read noise ratio (compared to 5x)
720p: 1.43 14.79 14.74
1080p: 0.88 14.75 9.07
5x: 0.097 23.64 1
Numbers from Audionut:
gain read noise ratio (compared to 5x)
ISO 100:
720p: 73.48 6.93 11.9 (note: it's very hard to tell how much is read noise
1080p: 53.78 6.54 8.7 and how much is Poisson noise from a nearly straight line)
5x: 6.15 5.98 1
photo: 5.11 6.77 0.83
ISO 200:
720p: 44.87 7.22 14.4
1080p: 27.50 6.76 8.84
5x: 3.11 6.26 1
photo: 2.58 7.08 0.83
ISO 400:
720p: 22.50 7.34 14.6
1080p: 13.94 6.90 9.05
5x: 1.54 6.70 1
photo: 1.27 7.61 0.82
ISO 800:
720p: 11.40 7.77 14.6
1080p: 7.07 7.32 9.06
5x: 0.78 7.32 1
photo: 0.66 8.60 0.85
ISO 1600:
720p: 5.80 8.78 14.7
1080p: 3.54 8.34 8.98
5x: 0.394 9.94 1
photo: 0.324 11.10 0.82
ISO 3200:
720p: 2.91 10.82 14.9
1080p: 1.81 10.45 9.23
5x: 0.196 14.75 1
photo: 0.166 16.28 0.85
ISO 6400:
720p: 1.41 14.81 14.7
1080p: 0.87 14.67 9.06
5x: 0.096 23.90 1
photo: 0.082 30.09 0.85
ISO 12800:
720p: 0.71 29.69 14.2
1080p: 0.44 29.44 8.8
5x: 0.050 58.40 1
Raw buffer sizes (active area):
- photo mode: 5796x3870
- 1080p: 1932x1290
- 1932x672 stretched (covers roughly 16:9 in LiveView)
Ratio between photo mode and 5x zoom: 0.83. If the 5x zoom captures a little more highlight detail, it's OK. The difference may be also because LiveView uses electronic shutter, while photo mode uses mechanical shutter. So, I'll use the 5x zoom as reference for the other LiveView modes.
From the above data, I now have very strong reasons to believe that 5D3 does a
3x3 binning in 1080p, and a
5x3 binning in 720p (5 lines, 3 columns).
(if you shoot 720p on 5D3, the desqueezing factor - to correct the aspect ratio of your footage- is therefore
exactly 5/3 = 1.67x)
A possible 3x3 binning (and easy to implement in hardware) would be to average each sensel and its 8 neighbours of the same color (considering the two greens as separate colors, as in the well-known four-color demosaicing algorithms). This binning scheme can be easily extended to 720p (5x3), but might cause some interesting artifacts on resolution charts.
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/5d3-lv-binning-cell-v2.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/5d3-lv-binning-cell-720p-v2.png)
A more complex 3x3 binning (very unlikely to be implemented in hardware, since it requires complex logic and knowledge about each pixel's color) could be:
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/bad/5d3-lv-binning-cell.png)
(I'm showing it just for completeness, but I think the first pattern is the much more likely to be used).
If anybody could shoot some
resolution charts in LiveView (silent pictures in 5x, 1080p and 720p,
without touching the camera - I need more than pixel-perfect alignment), I can verify if these patterns are indeed the correct ones or not. If you don't use a remote release, you can take this test with the "Silent zoom bracket" option from the latest raw_diag to avoid camera movement.
Side note: the registers that control the downsizing factors are:
- Horizontal: CMOS[2], which also controls the horizontal offset; you can select full-res (1:1) or downsized by 3
- Vertical: ADTG 0x800C (2 for 1080p, 4 for 720p and 0 for zoom, so it should be the downsizing factor minus 1; other values are valid too)
Other cameras: I don't have much data, but from what I have, the binning factor seems to be 3. For example, the data from 50D (dsManning) looks like this:
gain read noise ratio (compared to photo)
ISO 100:
1080p: 7.67 5.34 3.4
photo: 2.26 6.15 1
ISO 200:
1080p: 4.20 5.48 3.85
photo: 1.09 6.52 1
ISO 400:
1080p: 2.04 5.89 3.4
photo: 0.60 7.97 1
ISO 800:
1080p: 1.04 7.30 3.4
photo: 0.31 10.94 1
ISO 1600:
1080p: 0.53 10.32 3.5
photo: 0.15 16.12 1
ISO 3200:
1080p: 0.53 10.45 nonsense :)
photo: 0.08 38.06 1
and from 500D (Greg):
gain read noise ratio (compared to photo)
ISO 100:
photo LV: 7.38 6.34 3.3
photo: 2.23 6.82 1
From the resolution charts (the first one I could find was this (https://scontent-a-dfw.xx.fbcdn.net/hphotos-prn1/t31.0-8/1622320_452213114909478_1345754329_o.jpg)), most cameras (except 5D3) show artifacts as if they were skipping lines, but not skipping columns.
Therefore, I believe the binning pattern looks like this:
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/5d2-lv-binning-cell.png)
but I'm waiting for your raw_diag tests to confirm (or reject) this theory.
Edit: confirmed on EOS M and 5D Mark II. From visual inspection, this method appears to be used on most other Canons.
An interesting conclusion is that 5D3 does not throw away any pixel in LiveView. Then you may wonder, why binning a full-res CR2 by 3x3 in post is cleaner? Simple: binning in software will average out
all noise sources, while binning in the analog domain (like the 5D3 does) will only average out the noise that got introduced before binning (here, the shot noise and maybe a small part of other types of noise), but cannot average out the noise that gets introduced after binning (here, the read noise, which is quite high on Canon sensors).
Therefore, at high ISO (where the shot noise is dominant), the per-pixel SNR on 5D3 1080p is improved by
up to*) log2(sqrt(9)) = 1.58 EV, compared to per-pixel SNR in crop mode. On the other cameras (3x1 binning), per-pixel SNR is improved by
up to log2(sqrt(3)) = 0.79 EV.
So, the noise improvement from the better binning method is
up to 0.8 EV at 1080p (ranging from 0 in deep shadows to 0.8 in highlights). That's right - throwing away 2/3 of your pixels will worsen the SNR by only 0.8 stops (maybe not even that).
*) If the binning would be done in software, you would simply drop the "up to" - the quoted numbers would be the real improvement throughout the entire picture :)
Quote from: Stedda on July 29, 2014, 02:35:07 PM
I PMd you a link with a Dropbox .zip 100 megs of shots
Some quick results:
5D3, 1080p vs 5x zoom:Source images: 1x.DNG (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/19020006.DNG) and 5x.DNG (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/19020007.DNG); convert to pgm with "dcraw -4 -E *.DNG".
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/1x.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/5x.png)
A few binning methods, applied on the 5x crop image:
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/5x-binned-3x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/5x-binned-1x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/5x-binned-5x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/5x-binned-3x3-tight.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/5x-imresize.png)
Difference between downsized 5x and unmodified 1x:
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/delta-binned-3x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/delta-binned-1x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/delta-binned-5x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/delta-binned-3x3-tight.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/delta-imresize.png)
5D3, 720p vs 5x zoom:Source images: 1x.DNG (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/19020010.DNG) and 5x.DNG (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/19020011.DNG); convert to pgm with "dcraw -4 -E *.DNG".
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/1x.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/5x.png)
A few binning methods, applied on the 5x crop image:
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/5x-binned-3x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/5x-binned-1x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/5x-binned-5x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/5x-binned-3x3-tight.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/5x-imresize.png)
Difference between downsized 5x and unmodified 1x:
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/delta-binned-3x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/delta-binned-1x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/delta-binned-5x3.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/delta-binned-3x3-tight.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/delta-imresize.png)
Debayer method: simply applied white balance and rendered as grayscale; since the image was monochrome, no real debayer was needed.
Binning methods:
1. 3x3 binning of pixels with the same color (the two greens are considered different colors)
2. 1x3 binning of pixels with the same color (1 line, 3 columns, which results in line skipping, as I believe to be done on most Canon DSLRs)
3. 5x3 binning of pixels with the same color (5 lines, 3 columns)
4. 3x3 binning of adjacent pixels (can only be done after debayering)
5. octave's imresize (can only be done after debayering)
Octave scripts, if you want to review the experiment or try it on your own data: 1080p (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-1080p/lv-binning-1080p.zip) and 720p (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/stedda-720p/lv-binning-720p.zip).
I'd say the theory is confirmed (http://www.magiclantern.fm/forum/index.php?topic=10111.msg118232#msg118232) - 3x3 binning in 1080p, 5x3 binning in 720p, averaging pixels of the same color, no line skipping (all pixels are used).
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/5d3-lv-binning-cell-v2.png) (http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/5d3-lv-binning-cell-720p-v2.png)
Wanted: test images for some camera(s) other than 5D3, to confirm the binning method with line skipping.
Still looking for test data for cameras other than 5D3.
Quote from: a1ex on June 07, 2014, 06:53:42 PM
If anybody could shoot some resolution charts in LiveView (silent pictures in 5x, 1080p and 720p, without touching the camera - I need more than pixel-perfect alignment), I can verify if these patterns are indeed the correct ones or not. If you don't use a remote release, you can take this test with the "Silent zoom bracket" option from the latest raw_diag to avoid camera movement.
Is it possible to download somewhere and print resolution chart?
Does it make sence to do it with 6D?
http://www.graphics.cornell.edu/~westin/misc/res-chart.html
Quote from: Walter Schulz on January 21, 2016, 02:27:49 PM
http://www.graphics.cornell.edu/~westin/misc/res-chart.html
thanks
Alex, will it be enough to print it on A4 or A3 is a must?
As long as you get moire on the camera, any size is fine.
EOSM and SL1 ('A' firmware a.k.a. 100D)
https://www.dropbox.com/sh/cj4ztz7bplv0g4m/AADRfBvCElinNgDeCM2gNeFCa?dl=0
The EOSM was no problem but this is the first time using the 100D. I couldn't get the touchscreen working with ML menus so I couldn't get raw_diag to do its thing. Also the 1080p silent picture doesn't look right but I did this three times and it always came out the same. Hope this is what you're asking for.
I just took a look over this, tonight I'll see it closer. Sounds very interesting!
Specially about the question 'hardware or software binning?'.
Heh, the message was taken from an older discussion, where you already answered. But revisiting the topic shouldn't hurt, right?
It never hurts! :D
I remember the original discussion, I thought you are re-lunching it. :)
Added files for 700D
https://www.dropbox.com/sh/cj4ztz7bplv0g4m/AADRfBvCElinNgDeCM2gNeFCa?dl=0
Whatever you find out about Pixel Binning and line skipping also helps with the Focus Pixel Fixer project. :D
Quote from: a1ex on January 21, 2016, 08:52:22 AM
If you don't use a remote release, you can take this test with the "Silent zoom bracket" option from the latest raw_diag to avoid camera movement.
I'd like to shoot some more tests but please refresh my mind. Is raw_diag a module, branch or what? Also, the link to that resolution chart is dead. Is there a recommended chart someone can link to?
http://www.bealecorner.org/red/test-patterns/
Quote from: dfort on June 28, 2017, 05:41:51 AM
I'd like to shoot some more tests but please refresh my mind. Is raw_diag a module, branch or what?
It a module (https://bitbucket.org/hudson/magic-lantern/src/bd8e89d9dccf2d1541bb449efd06bb450cdce153/modules/raw_diag/?at=iso-research) from the iso research branch
It's here as well: http://builds.magiclantern.fm/modules.html
Thanks Walter, David and Alex!
I take it the ISO 12233 Chart is preferred one to use? Anything that creates a moiré pattern, right?
Did some more tests. This time I tried to shoot the pixel binning test using the same chart and settings on the EOSM, 100D and 700D.
https://www.dropbox.com/sh/prilw5vvrl9d0e0/AABbX8xoiU5o_AEZW2vJMXvya?dl=0
Some interesting observations.
The 100D always recorded the second (5x) frame from the raw_diag "Silent Zoom Bracket" blank. I tried the build that is on the 100D forum topic (http://www.magiclantern.fm/forum/index.php?topic=16040.0) along with the posted raw_diag module, building from the @nikfreak bitbucket repository and several combinations including merging the latest unified but it always came up blank. I would have looked into it some more but I need to return the camera which belongs to @DeafEyeJedi. Shot the test on a solid tripod the best I could. I also included those blank frames in case there's a clue in there as to what is going on.
How did you manage to get the test files, then? Manually pressing half-shutter, or remote release cable?
Did the blank picture also appear with manual trigger? If the third picture was OK, you can edit the "script" to take 3 pictures as a workaround (although I'd be interested to find out why it happens). Were there any messages on the console?
There is a memory allocation fix for the silent picture module (where it was missing the first frame on 5D3, iirc) on the raw_fixes (https://bitbucket.org/hudson/magic-lantern/pull-requests/828/raw-fixes-part-5) branch. Maybe it's related.
BTW, I have a feeling ISO might have been too high on these samples (they are quite noisy).
Quote from: a1ex on June 28, 2017, 06:52:50 PM
How did you manage to get the test files, then?
Manually -- yeah, that's a lousy test.
Quote from: a1ex on June 28, 2017, 06:52:50 PM
Did the blank picture also appear with manual trigger? If the third picture was OK, you can edit the "script" to take 3 pictures as a workaround (although I'd be interested to find out why it happens). Were there any messages on the console?
Yes, manual trigger will also give a blank picture on the second trigger. Interesting is that the second picture should be the 5x exposure but it is the same file size as the first, only blank so the "set_lv_zoom(5);" didn't seem to take though LiveView went into 5x before it fired the second shot. I edited the script to take multiple shots in 5x mode and all the subsequent shots were fine. I also played with the delay before the second shot but it didn't seem to make a difference. Putting the camera in 5x mode and shooting a single shot worked fine. Weird. The error message that flashes on the screen is, "Buffer error..." I had to run it several times to be sure because sometimes it wouldn't display the error or maybe I'm too slow.
Quote from: a1ex on June 28, 2017, 06:52:50 PM
BTW, I have a feeling ISO might have been too high on these samples (they are quite noisy).
ISO was set at 200. The noise you see is probably from my printer. I used smooth paper but the print doesn't look very sharp.
Give me a few minutes to set up and I'll upload another 100D test.
100D test reshoot is up. I trashed the invalid tests.
A few notes on the error message.
The full frame is saved normally though there is a message that says "Buffer: 2 frames (90%)" LV zooms into 5x and next message says "Saving 1736 x 699" which doesn't make sense because that isn't the size of the 5x zoom buffer. Next message is "Preparing..." with "Buffer error" below that followed by "Preparing..." with "Capturing frame 1". The next couple of 5x capture frames I added show the normal "Preparing..." followed by "Saving 2520 x 1080..." message.
Hope this helps.
[EDIT] BTW doing a shutter half press to shoot a silent picture would also sometimes trigger raw_diag to save a chart. Thought I'd post this one in case anyone finds it interesting.
(https://c1.staticflickr.com/5/4262/35423573392_b3460178e0.jpg)
(I hope this thread is right place)
Pixel binning patterns are interesting and annoying... I've been thinking about it for a while.
Cameras such as 5D2, 7D, 70D, 100D, they all have the horrible 3x1 binning, and 5D3 has the good 3x3 binning.
So... In my opinion biggest issue with RAW video for me and almost everyone is the massive moire that comes with it,
it ruins the rendering of detail, and we use all kinds of methods to try and avoid it, such as debayering algorithms like AMaZE...
I don't know if this is right place to start this idea, but maybe an algorithm specially optimised for demosaicing 3x1 binned images could be created.
AMaZE is optimised almost perfectly for square pixels, or that have equal vertical and horizontal coverage, but with the 3x1 binning it still looks crap.
I have been experimenting with binning raw images and I've come up with binning_test (https://github.com/ilia3101/MLV-App/blob/master/platform/binning_test/main.c) (github link).
It's inefficient and not too flexible yet, but mainly, it creates 2 binned images from an MLV file... one 3x3 and one 3x1, binning patterns are customisable.
It's most accurate with crop mode/FRSP. I think its a good starting point.
I really care about this because in my opinion the moire is the biggest problem with Magic Lantern RAW video on most cameras,
and I think it would be worth all the time it will take to make this algorithm, as it could potentially bring these crippled cameras up to 5D3 levels..
Here's the difference between how 3x1 and 3x3 bayer images look:
(http://image.ibb.co/hAttfQ/binning.gif) (http://ibb.co/nfxauk)
It shows that 3x3 is significantly smoother(look at roof too).
...another idea is:train a neural network to accurately transform a 3x1 image to look as if it was 3x3 binned.
Neural networks are good at finding subtle connections between values, so maybe it would recreate the 3x3 binning relatively good even with the missing information...
Except I don't know how to do neural networks :-\... something worth looking in to (this might be a better idea than first one)
I don't know really what the aim of this post is, but who thinks its a good idea? Does anyone have any suggestions or input? Can anyone help?
Some random notes:
Input image: https://www.magiclantern.fm/forum/index.php?topic=15088.msg191844#msg191844
pkg load image
system("dcraw 2-normal.DNG");
b = imread("2-normal.ppm");
x = b(700, 500:600, 2); t = 1:length(x);
xf = imfilter(x, [1 0 1 0 1] / 3);
xnf = xf; for i = 1:10000, xnf = imfilter(xnf, [1 0 1 0 1] / 3); end
cla; stem(t, x, 'b'); hold on; plot(t, xf, 'o-r'); plot(t, xnf, '.-g'); axis tight
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/bin.png)
Food for thought: can we recover blue from red?
(same problem as Ilia's, just 1-D and monochrome)
@a1ex
I didn't know how you got 3x1 Binning what the registers to override?
I found a register maybe will fix horizontal stretching in LiveView when using 3x1 which is: C0F11A8C you can stretch the LiveView horizontally to the right and the left. I couldn't test it because adtg_gui doesn't work when using crop_rec or iso_regs in the same time, How can we use them both?
I can get with 3x1 mode 3840x720 (stretch it to get 3840x2160) @ 23.976 FPS but with horrible aliasing and no details at all. I am thinking if
we can do 3x2 Binning (Less aliasing in 3840 and more details) or also 2x2 Binning (Less crop factor) to be used for Monochrome, can we get this?
For testing in adtg you can override register '800c', which also can be seen in adtg if 'known registers' is selected.
That's the lineskipping value, default value = 2 (skipping 2 lines) , use value 0 (No lineskipping) for 3x1 mode.
This way you will have 3x1 mode, although you can't go beyond normal vertical resolution so it probably stops around 1200 vertical resolution (getting more resolution in adtg needs a lot more registers to change).
So this will be the easiest way for testing things in adtg and see what other registers do to the liveview, since you only have to change register 800c to get 3x1 mode.
You can also see for yourself what a lineskipping value of 1 does (3x2 mode), you will loose one of the bayer colors, not sure which one, red or blue, but you can play with the results and see if it is usable for monochrome.
Actually you are talking about 1x3 Binning "800c" for Vertical but 3x1 Binning there is a register for Horizontal maybe a CMOS register?
Little confusing this talk about 3x1, 1x3 :P
But you're right, you're working in 5x zoom mode, so lineskipping is already at value 0 and now you have to enable horizontal pixelbinning.
On 6d that is done by CMOS 6 register.
You can use ADTG and see what value CMOS 6 has in full view mode and 5x zoom mode.
Now you can lock the value of CMOS 6 in full view mode in ADTG module and go to 5x zoom mode, this should give 3x1, right ???
EDIT, found your spreadsheet with crop_rec registers, you probably need to change CMOS 5 on your camera.
Quote from: Danne on January 01, 2019, 11:32:48 AM
Let´s start 2019 with some eosm love. The setting is called:
4K squeeze 24fps
It´s working continuously with 10 bit and build files when set to 2.35:1 through crop_rec submenu that gives files sized to 4000x1704. The files are actually recorded into a squeezed mode(4000x696 or 4000x 568 when 2.35:1 is selected). Thanks to mlv metadata the upscaling is done with the default scale tag so it´s merely a question of opening up the file in Mlv App or acr and the unsqueezing will be done automatically.
To use it enable 'framing' to get a preview in liveview. It is working in regular video mode(NOT x3 zoom mode). Set bitrate to 10bit and ratio to 2.35:1 for continuous recording.
Please report back how it works and feel free to share content recorded.
By the way. Do not miss out on this progress!
https://www.magiclantern.fm/forum/index.php?topic=17695.msg209985#msg209985
Build for download in following post:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959
MLV test file:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/short_M01-0722.MLV
(https://i.postimg.cc/zXmykBqk/Screenshot-2019-01-01-at-11-27-10-png-800px.png)
TODO:
Focus pixel map(dfort is looking into it).
This mode actually also works in mv720p which yield 5x1 squeeze. Will check if it´s actually useful in real life or not.
One minor nitpick: if you zoom in at 1:1 and look at diagonal edges, you will see some jagged lines (as if the columns were somehow reordered).
These artifacts are exactly what I'm talking about in these comments:
/* 3x1 binning (bin every 3 lines, read every column) */
/* doesn't work well, figure out why */
case CROP_PRESET_3x1:
/* ADTG2/4[0x800C] = 2: vertical binning factor = 3 */
/* ADTG2[0x8806] = 0x6088 on 5D3 (artifacts worse without it) */
adtg_new[2] = (struct adtg_new) {6, 0x800C, 2};
if (is_5D3) {
/* this register is model-specific */
adtg_new[3] = (struct adtg_new) {2, 0x8806, 0x6088};
}
break;
I don't remember whether the artifact is present in the 3x1 mode from the bleeding edge 700D crop_rec (https://www.magiclantern.fm/forum/index.php?topic=19300.msg205546#msg205546); maybe Bilal can double-check, if he's still around. The issue is present on 5D3 too, but I wasn't able to fix it there.
Anyway, my suggestion for a 4K stretched mode would be to rotate it at 90 degrees (i.e. take Bilal's 1736x2214 in 1x3 (https://www.magiclantern.fm/forum/index.php?topic=22818.0) and attempt to squeeze it even more, to get larger heights, up to 3478).
Why? That way, you will not skip any physical pixels on the sensor; all Canon cameras I've looked at appear to be able bin pixels horizontally, every 3 columns. Since this camera is not able to bin in the vertical direction, you'll just read out every line.
With the bleeding edge 700D crop_rec, you should get 1440x3478 at 19.2 FPS:
[crop_rec] source: 1736x1160 @ 23.976 fps
[crop_rec] target: 1440x3478 @ 19.194 fps
[crop_rec] ylimit: 1398,3478
[crop_rec] timerA: 528 -> 446
[crop_rec] timerB: 2527 -> 3738
[crop_rec] delta : X-296 Y+2318 [z=1]
From there, you might be able to reduce the horizontal resolution even further; I just don't remember where the hardcoded 1440 limit comes from, and have no way to re-test it atm. For 24 FPS at full height, you need to go down to about 1080 pixels horizontally, but I'm not sure whether the hardware will accept it:
[crop_rec] source: 1736x1160 @ 23.976 fps
[crop_rec] target: 1080x3478 @ 23.976 fps
[crop_rec] ylimit: 1864,3488
[crop_rec] timerA: 528 -> 356
[crop_rec] timerB: 2527 -> 3749
[crop_rec] delta : X-656 Y+2318 [z=1]
(https://a1ex.magiclantern.fm/bleeding-edge/700D/4K-vertical.png)
Expected result: much lower aliasing.
If that works, you can try to go even further; for squeezed 16:9 you would require only 3478 * 9 / 16 / 3 = 652 pixels horizontally. If the hardware accepts it, that should give some half-decent rolling shutter, too.
Happy New Year!
Thank a1ex. Will dig more into this later on. 1x3 is very nice but it comes with the price of much shorter recording times.
Anyway. I started out with squeezing it 5x and yes, would give x5 the height. Also gonna look further into this.
Happy new year!
Edit: squeeze 1x3 mode more. Yes that would be much better probably. On 5D3 this probably would be a game changer...
Quote from: Danne on January 01, 2019, 01:57:18 PM
1x3 is very nice but it comes with the price of much shorter recording times.
That's true, but keep in mind Bilal is correcting the image by shrinking it vertically (e.g. 1736x2214 -> 1736x738), so his result is going to be better than a plain 1:1 readout at 1736x738 (it would be an oversampled image). 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).
My suggestion is to apply this procedure on a 1440x3478 1x3 readout, or 1080x3478 if the hardware accepts it, then crop it to e.g. 652x3478 in mlv_lite and correct it to 1956x3478 in post. That way, you'd get a vertical 3.5K 16:9 (interpolated) requiring about 50-60 MB/s at 24p (i.e. likely continuous with the UHS hack),
without skipping any physical pixels on the sensor.
Then, it might be interesting to try some smarter interpolation algorithm (such as the one in cr2hdr (https://www.magiclantern.fm/forum/index.php?topic=7139.msg84062#msg84062), or something tweaked specifically for this kind of readout). I'm sure it won't match a plain 1:1 1956x3478 readout (which is doable at 16.462 FPS), but it might be worth trying.
Now, whether the interpolated 1956x3478 is any better than 1080x1920, that remains to be seen (and I'd say it largely depends on the upscaling algorithm).
Of course, if you only need 2.35:1 or wider at 24p, without rolling shutter constraints, then just stick with Bilal's settings. The 1736x2214 1x3 readout will give a 2.35:1 output between 1736x738 (oversampled) and 5208x2214 (upsampled); the sweet spot is probably somewhere in-between, depending on the upscaling algorithm.
Great description/explanation. Will be an interesting journey to see where this leads.
Already tried the method Alex describes long time ago.
You would think that horizontal stretching gives the best results, since horizontal, pixels are binned. Sounds a bit like anamorphic shooting with a 3x squeeze, right...
But unfortunately the results are really bad, not sure why, probably has to due with how the binning is done.
I did get the best results with lineskipping and stretching the image 3 times.
Still wasn't really happy with the end result..both rescaling with 'cubic' and 'zinc(lanczos3)' give poor results in my opinion, but as Alex said, maybe there is a more proper way to rescale this kind of stuff.
Here's a quick side to side comparison viewed at 100% pixel level, the left is 1624x2070 stretched to -> 4872x2070 and the right is 5120x610 stretched to -> 5120x1830
(https://farm5.staticflickr.com/4825/32682240208_5f5a3c0415_o.png)
The 5120x610 stretched to 5120x1830 doesn't look that bad, but the stretching is really visible in stuff that has a certain angle to it, probably everything with straight line at 45 degrees look horrible :P
Quote from: a1ex on January 01, 2019, 01:39:43 PM
One minor nitpick: if you zoom in at 1:1 and look at diagonal edges, you will see some jagged lines (as if the columns were somehow reordered).
I believe those jagged lines are happening when you're recording all horizontal pixels in non-zoom mode.
If you're using the same settings in 5x zoom mode, those jagged lines are gone.
Not by my computer levas but wouldn't x5 mode simply put this mode into 1×1? No squeeze that is?
Not if you're overriding register 800C (lineskipping)with value 2.
Quote from: Levas on January 01, 2019, 03:56:51 PM
Here's a quick side to side comparison viewed at 100% pixel level, the left is 1624x2070 stretched to -> 4872x2070 and the right is 5120x610 stretched to -> 5120x1830
If you happen to still have the original files, mind sharing them? A still CR2 from a similar scene could be interesting for simulating this kind of binning, too.
Edit: here's a quick simulation with a resolution chart:
binning-modes.html (https://a1ex.magiclantern.fm/bleeding-edge/lv-binning/binning-modes.html) (18.5 MB)
Edit: received the original files, thanks, will check them later.
hm, 1x3 mode seems to be the better bet. Thanks for sharing visuals. Very revealing.
Just started with squeeze modes so gonna take some time to fully get what and how to do this the best way. @Levas. I can not get these squeeze modes to work with x3 mode or setting 8000 to 5 so feel free to share whatever you get working with less jagged edges.
Published a new build which now includes both 4k 3x1 and 4k 5x1 24 fps. Both settings will work straight out of the box in Mlv App thanks to masc swift follow up which now includes 5.0x height increase. DOne automatically thanks to mlv metadata fully working with crop_rec.c code.
So:
"4K 3x1 24fps",
"4K 5x1 24fps",
Runs in regular non crop mode.
As usual downloads here:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959
Fabulous stuff. Thanks for sharing the resolution charts re: binning-modes @a1ex. That was a fun read through!
Agreed 1x3 modes seems to be the sweet spot @Danne!
Nice stuff happening on the Binning mods! Here is some samples showing all different Binning mods in 700D the Primary photo is 1x1 Full-Resolution LiveView 5208x3478 1x1 and the other are scaled, stretched to to original size of Full-Resolution LiveView then I cropped the image on specific area to show the details difference between them:
1x1 Readout 5208x3478
(https://i.ibb.co/3zWWLPN/1x1.png) (https://imgbb.com/)
1x3 Readout 1736x3478 Upscaled to 5208x3478
(https://i.ibb.co/mHqkw6M/1x3.png) (https://imgbb.com/)
3x3 Readout 1736x1160
(https://i.ibb.co/3B7FLK8/3x3.png) (https://imgbb.com/)
3x1 Readout 5208x1160 Upscaled to 5208x3478
(https://i.ibb.co/WWWVj7d/3x1.png) (https://imgbb.com/)
5x3 Readout 1736x696 Upscaled to 1736x1160
(https://i.ibb.co/tzmGqbp/5x3.png) (https://imgbb.com/)
So 1x3 Binning is the sweet spot between 1x1 and 3x3 readout and 3x1 is the worst here unlike Levas results on 6D? And also 1x3 Binning mod will give more details if we upscaled it otherwise stretching it down (the vertical) will not give that details only will clear the aliasing and moire issues. Of course 5x3 Binning is out of planet Earth.
Original DNGs: Download (https://drive.google.com/open?id=1xEXC_CeQiW9vNNzl22kI5PyWyT78iqPf)
Note: Full-Resolution LiveView gives brighter exposure compared to all other mods not sure why (in bleeding edge crop_rec).
I am assuming if we get smart algorithm to re-scale 1x3 readout to the original size, will we get same details as 1x1? or maybe more close to it?
Sorry for off topic, but you are talking here :P
Danne started a discussion with this post about a 4K preset (squeezed) for the EOS-M
https://www.magiclantern.fm/forum/index.php?topic=9741.msg209998#msg209998 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg209998#msg209998)
@theBilalFakhouri
I see jagged lines in your 3x1 readout.
I can record in 3x1 with and without these jagged lines.
I use a value of 6 for the 8000 register and a value of 2 for 800C register:
8000=6
800C=2
And I use the 5x zoom mode with the above settings.
Levas. Would you mind sharing two movie files. One with squeezed registers in non cropped mode, the other one with same settings but in x5 mode. I try exactly what you describe but output is not the same when in x5 mode.
Here are two example DNG's.
Both are recorded with the same crop_preset, the one with the jagged lines is in non zoom and the normal one is in 5x zoom.
https://drive.google.com/drive/folders/11P6HUC3xNHGNSGLFnV42CctoQjKn9WqY?usp=sharing (https://drive.google.com/drive/folders/11P6HUC3xNHGNSGLFnV42CctoQjKn9WqY?usp=sharing)
Screenshot comparing both DNG's:
(https://farm5.staticflickr.com/4813/46573940471_df48773efa_o.png)
That is very strange and also the solution to the issue with jagged lines. Could you share the full set of registers you used here? It should be doable for the eosm as well.
Also would be nice with the actual MLV files.
Ok, now the fun part, I changed the 8000 register in the crop_preset I just used from value 6 to 5.
And after re-adjusting CMOS 7, I have no jagged lines in either non zoom and 5x zoom mode ???
So conclusion for now I guess:
The jagged lines appear only in non zoom mode when register 8000 has value 6 (but the jagged lines don't show up in 5x zoom)
When register 8000 has value 5, there aren't jagged lines in any mode, non zoom and 5x zoom.
For crop_presets on the 6d I use:
CMOS 6 for controlling horizontal binning on or off. (On the 700d and probably most other cameras this is done with CMOS 5)
CMOS 7 for adjusting which vertical part of the sensor is read out and needs finetuning depending on resolution setting, otherwise you get the purple hazy preview/recordings
Register 800c for controlling vertical lineskipping, 0 for no line skipping, 2 for reading every third line.
Register 8000 for controlling jagged lines I guess :P (trial and error between value 5 and 6)
All other registers like shutter blanking are done automatiically by a piece of code from Alex which all others are using too and values for resolution and A and B timers are done as usual.
I still would prefer the full register code, number and all. Could you upload your version of crop_rec.c that you knw will produce non jagged edges?
Don´t you have the exact registry changes for the dng files you uploaded somewhere?
I use following registers:
case CROP_PRESET_4K_3x1_EOSM:
cmos_new[5] = 0x200; /* vertical (first|last) */
cmos_new[7] = 0xf20;
break;
case CROP_PRESET_4K_3x1_EOSM:
adtg_new[0] = (struct adtg_new) {6, 0x800C, 2};
adtg_new[2] = (struct adtg_new) {6, 0x8000, 5}; /* added to test Levas non jagged edge version out */
break;
switch (reg)
{
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;
}
return 0;
Uploading MLV's (can take a few minutes), one with jagged lines and one without jagged lines, both recorded with the same crop_preset.
It's done with crop_preset '5K' in the crop_rec.c file.
All in the same folder as previous DNG's:
https://drive.google.com/drive/folders/11P6HUC3xNHGNSGLFnV42CctoQjKn9WqY?usp=sharing (https://drive.google.com/drive/folders/11P6HUC3xNHGNSGLFnV42CctoQjKn9WqY?usp=sharing)
It's from a very old template.
Also changed some stuff to fix shutter times for the right video mode the crop preset is made for:
Line 182:
/* helper to allow indexing various properties of Canon's video modes */
static inline int get_video_mode_index()
{
return
(crop_preset == CROP_PRESET_HD100) ? 3:
(crop_preset == CROP_PRESET_HD75) ? 3:
(crop_preset == CROP_PRESET_HD50) ? 3:
(crop_preset == CROP_PRESET_2K) ? 1:
(crop_preset == CROP_PRESET_ULTRA_HD) ? 1:
(crop_preset == CROP_PRESET_4K) ? 1:
(crop_preset == CROP_PRESET_5K) ? 1:
(crop_preset == CROP_PRESET_FullRes) ? 1:
(crop_preset == CROP_PRESET_1x3) ? 1:
(crop_preset == CROP_PRESET_HD2) ? 3:
(crop_preset == CROP_PRESET_3x3_1X) ? 1:
4;
}
corresponds to this table at line 545:
/* from SENSOR_TIMING_TABLE (fps-engio.c) */
/* hardcoded for 6d */
const int default_timerA[] = { 0x27f, 0x2d9, 0x21f, 0x27F, 0x27f };
const int default_timerB[] = { 0x63f, 0x493, 0x61b, 0x31f, 0x334 };
const int default_fps_1k[] = { 25000, 29921, 29978, 50000, 59964 };
As you can see in the upper piece of code, I set preset '5K' to value 1, so now the rest of Alex's code takes the A and B timer values from column 1 in the table shown in the second piece of code.
Counting starts with column 0, so column 1 means A timer = 0x2d9, B timer = 0x493 and FPSx1000 = 29921 (Default values for Canon 6d in 5x zoom mode)
Thanks Levas. Let´s compare: In short from your crop_rec.c:
case CROP_PRESET_5K:
cmos_new[6] = 0x0;
cmos_new[7] = 0xc+ delta_head4;
break; case CROP_PRESET_5K:
adtg_new[11] = (struct adtg_new) {6, 0x8000, 6};
adtg_new[12] = (struct adtg_new) {6, 0x800C, 2};
break;static inline uint32_t reg_override_5K(uint32_t reg, uint32_t old_val)
{
switch (reg)
{
/* raw resolution (end line/column) */
case 0xC0F06804: return 0x2800520; // 5472x3604 5x zoom;
case 0xC0F06824: return 0x535;
case 0xC0F06828: return 0x535;
case 0xC0F0682C: return 0x535;
case 0xC0F06830: return 0x535;
case 0xC0F06010: return 0x537;
case 0xC0F06008: return 0x5370537;
case 0xC0F0600C: return 0x5370537;
case 0xC0F06014: return 0x2fe; //8fb;
case 0xC0F0713c: return 0x280;
case 0xC0F07150: return 0x27f;
}
return 0;
}QuoteWhen register 8000 has value 5, there aren't jagged lines in any mode, non zoom and 5x zoom.
If understanding correctly you change registry 8000 to 5 so this changes:
case CROP_PRESET_5K:
adtg_new[11] = (struct adtg_new) {6, 0x8000, 5};
adtg_new[12] = (struct adtg_new) {6, 0x800C, 2};
break;This will totally mess up my bag over here and put liveview into som messy x3zoom. But with you the magic non jagged edges thingy appears? This works in both non crop mode and in x5 mode giving the squeezed 3x1 footage?
EDIT:
Your Mlv files opened up into Mlv App and height set to 3.0x verifies your findings. Totally amazing. It´s 4k the right way with a very reduced overhead.
Jup :)
I also needed to adjust CMOS 7 (I did that in camera in the crop_rec menu, I use deltahead 4 for that ;D , 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.
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?
An attempt. Result is 4000x696 but 1x1:
case CROP_PRESET_4K_3x1_EOSM:
cmos_new[5] = 0x200; /* vertical (first|last) */
cmos_new[7] = 0x500;
break;
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;
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:
(https://i.postimg.cc/PJYVmx35/Screenshot-2019-01-02-at-22-47-42-png-800px.png)
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:
adtg_new[0] = (struct adtg_new) {6, 0x800C, 0};
adtg_new[0] = (struct adtg_new) {6, 0x800C, 2};
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:
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
(https://i.postimg.cc/4dsdcJ6b/Screenshot-2019-01-03-at-00-35-00-png-scaled.png)
(https://i.postimg.cc/tg07Xd7c/Screenshot-2019-01-03-at-00-35-11-png-scaled.png)
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 ??? )
Quote
Edit:
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.
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.
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:
(https://i.postimg.cc/d08m2mXM/Screenshot-2019-01-03-at-01-44-14-png-scaled.png)
After:
(https://i.postimg.cc/v8Xh2hmb/Screenshot-2019-01-03-at-01-44-22-png-scaled.png)
Got damn, this took a while but think it will be a gamechanger. Thanks Levas!!
wow!
there's so much happening these days, it could make you dizzy!
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 .
(https://i.ibb.co/N3hq1K3/160precent-3840-X1872-3x-Crop-FHD-line-skipping-croped.png) (https://ibb.co/g718vJ7)
160perscent_3840X1872_3xCrop_+FHD_line_skipping.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/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
(https://i.ibb.co/v3rntYX/5632x3204-M02-2336-frame-67-small.png) (https://ibb.co/QPqw5dD)
5632x3204_M02-2336_frame_67.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/5632x3204_M02-2336_frame_67.png)
5632x3204_12.38fps_M02-2336.mp4 (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/5632x3204_12.38fps_M02-2336.mp4)
@Danne, Great you got it working on Eos-m :D no jagged lines.
Beautiful collaborations from @Danne & @Levas on achieving this remarkable milestone and indeed it'll definitely be a game-changer!
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 :P.
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)
(https://i.ibb.co/x37kv8w/No-pixel-stretch-3700zoom-small.png) (https://imgbb.com/)
No_pixel_stretch_3700zoom.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/No_pixel_stretch_3700zoom.png)
4096x1770 (un-squeezed 3700% zoom)
(https://i.ibb.co/ZB1K4mH/300-precent-Hoz-pixel-stretch-3700-zoom-small.png) (https://imgbb.com/)
300_precent_Vertical_pixel_stretch_3700_zoom.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/300_precent_Vertical_pixel_stretch_3700_zoom.png)
Quote from: a1ex on January 01, 2019, 02:13:12 PM
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(https://i.postimg.cc/WpyWPqM4/Screenshot-2019-01-12-at-18-56-21-png-800px.png)
100% zoom(https://i.postimg.cc/mgfmPxpf/Screenshot-2019-01-12-at-18-56-40-png-800px.png)
By the way. I started using exiv2 for metadata alterations. Exiftool is a bit picky these days with altering tags:
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...
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)
(https://farm8.staticflickr.com/7863/31774683167_b49589c8ca.jpg) (https://flic.kr/p/QpPyhX)
Apply some black magic:
find . -maxdepth 1 -mindepth 1 -iname '*.dng' -print0 | xargs -0 exiv2 -M"set Exif.Image.DefaultScale Rational 3/1 1/1"
Looks good.
(https://farm8.staticflickr.com/7873/32841341148_68424af809.jpg) (https://flic.kr/p/S35sxN)
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.
dcraw -T 1_x3_M10-1218_frame_1.dng
(https://farm5.staticflickr.com/4892/31774828777_566d0cda59.jpg) (https://flic.kr/p/QpQizt)
That's quite amazing -- especially for an EOSM!
Must admit that this example looks very good, but then there is not that much in focus, very small depth of field :P
Try to impress me with some example with more depth of field ;)
Quote from: Levas on January 12, 2019, 08:10:14 PM
...very small depth of field...
Said the guy with the full frame camera. :P
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?
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:
(https://i.postimg.cc/sXgwbxrP/Screenshot-2019-01-12-at-21-51-33-png-800px.png)
mv1080p 1736x1160
(https://i.postimg.cc/SRV1J9fv/Screenshot-2019-01-12-at-21-43-29-png-800px.png)
5K 3x1 24fps
(https://i.postimg.cc/wTfbzhvt/Screenshot-2019-01-12-at-21-43-17-png-800px.png)
1x3 1704x2176
(https://i.postimg.cc/763WrdGD/Screenshot-2019-01-12-at-21-44-31-png-800px.png)
@Dfort
Gotta love low depth of field ;D
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.
Branch has been reposted at least ten times 8)
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959
Post is old but links are updated.
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!
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
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?
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:
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/5d2-lv-binning-cell.png)
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 :P
Quote from: Danne on January 12, 2019, 09:50:39 PM
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.
Quote from: Levas on January 13, 2019, 11:36:37 AM
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:
I really dig the unbining idea. I need to understand more the bining theory and need some visual examples.
As far as I know, the Canon's do horizontal binning the following way:
You have a standard Bayer pattern.
And on a horizontal line, each chunk of 6 pixels is readout and all 3 red pixels are averaged to 1 value and all green pixels are averaged to one value etc. etc.
(https://farm5.staticflickr.com/4807/45823558585_c1131e5af3_o.png)
To unbin this binned image I was thinking to do something like this:
First you're gonna stretch the raw file by a factor 3 in horizontal direction, so copy each red/green pair 3 times, and in the next line, copy each green/blue pair three times.
So for example in a red/green line, you end up with each 6 pixels having 3 times the same green value and 3 times the same red value.
In each 6 pixel block, you can keep the values of the pixels in the middle, So pixel 3 and 4 in a chunk of 6 are already good.
The green pixel on the left side of a chunk of 6 has to averaged with the green neighbour pixel in the chunk of 6 pixels that are on the left side.
The green pixel at the right end of a chunk of 6 pixels, has to be averaged with a neighbouring green pixel on the right side of the chunk of 6 pixels.
Looks like this:
(https://farm5.staticflickr.com/4846/39774053463_19345a20e7_o.png)
Not sure if this is clear enough ?
Also not sure if this is gonna give better results :P
But if anyone can do this, I'd love to find out how the end results look.
I think it is a bit wrong. Look at the 1st post of this thread. a1ex showed the 5d3 and all other (lower) camera bining methods. The averaging is done not exactly by 6 raw line pixels but a next pixel for every color (R,G+1 for first line and G,B+1 for second line). 5D3 is a complete another story with 3 by 3 binning.
I thought about what you've showed above and the algo you proposed, and according to the initial and the end values and their differences this is very inaccurate approach. Anyway after averaging the information is lost forever and it is impossible to recover it except only very basic cases.
Well... I'm gonna think about it more, but... maybe a1ex could suggest, does it worth a try or not.
regards
bb
You're right, it's not done in chunks of 6 pixels, there is a shift for the other color channel.
The suggested algo does indeed not approach the original raw data, but that's never possible, like you said, the data is lost forever.
I expect that such an algorythm or any variation on it, can give better results in the pixelated aliasing that happens on round curves or straight lines.
And indeed curious if Alex has any ideas, did a great job with dual-iso.
Found a different pinning mode on the 5d2 in 3x crop_mode (5x zoom)
ADTG12[100c]0x01
This give a vertical squeeze similar to 3x5 in 1:1FHD(720p mode on other cams)
Tried to correct the W/B & colors , bad black levels plus other issue -- all blue channel it seems
In 3x crop_mode 5632x514
(https://i.ibb.co/XSqrqWS/M11-1730-frame-1-5632x514-small.png) (https://imgbb.com/)
M11-1730_frame_1_5632x514.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M11-1730_frame_1_5632x514.png)
Un-squeezed @ 167%
(https://i.ibb.co/DbsPG0g/M11-1730-frame-1-5632x856-167precent-vertical-small.png) (https://imgbb.com/)
M11-1730_frame_1_5632x856_167precent_vertical.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M11-1730_frame_1_5632x856_167precent_vertical.png)
the original dng's -- 5632x514
(https://i.ibb.co/6nqM35x/M11-1730-frame-1-5632x514-no-color-correction-small.png) (https://imgbb.com/)
M11-1730_frame_1_5632x514.dng (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M11-1730_frame_1_5632x514.dng)
Exported DNG from MLV App with 167% vertical stretch
(https://i.ibb.co/BzHT9g4/M11-1730-frame-1-5632x857-167precent-vertical-no-color-correction-dng-small.png) (https://imgbb.com/)
M11-1730_frame_1_5632x857_167precent_vertical.dng (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M11-1730_frame_1_5632x857_167precent_vertical.dng)
Looks indeed like there is missing a color channel.
I think you did a lineskipping factor of 1 in 5x zoom mode.
That would cause the missing color channel, you're only reading the Blue/Green pixel lines.
If that's the case, the unsqueezing factor should be 2 instead 1.67
Yea , your right -- I just check it that even better , now if I can get all the channel working .
5632x1028 from 5632x514 with 200% vertical stretch
(https://i.ibb.co/ZVpfYjp/M11-1730-frame-1-5632x1028-200precent-vertical-small.png) (https://imgbb.com/)
M11-1730_frame_1_5632x1028_200precent_vertical.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M11-1730_frame_1_5632x1028_200precent_vertical.png)
can we use it for black and white if we don't get the other color channel? just sayin..
Quote from: reddeercity on January 16, 2019, 03:26:31 AM
Yea , your right -- I just check it that even better , now if I can get all the channel working .
5632x1028 from 5632x514 with 200% vertical stretch
(https://i.ibb.co/ZVpfYjp/M11-1730-frame-1-5632x1028-200precent-vertical-small.png) (https://imgbb.com/)
M11-1730_frame_1_5632x1028_200precent_vertical.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M11-1730_frame_1_5632x1028_200precent_vertical.png)
No way to get 3 channels with 2x stretch I think, unless you make the camera do a really complex binning pattern.
Ilia is right, you will never get 3 channels by using a lineskipping value of 1.
You always end up with 2 color channels, you are reading only the green/red pixel lines, or only the green/blue pixel lines, because of the lineskipping value of 1.
This post from Alex is still interesting, I'm not sure if it is possible.
But it would be cool to explore if their is some sort of way to create decent images out of 2 color channels instead of 3.
Quote from: a1ex on December 02, 2017, 11:59:48 AM
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/bin.png)
Food for thought: can we recover blue from red?
An interesting pixel binning mode found by mistake by Danne & Masc on the EOS M.
Quote from: masc on February 17, 2019, 06:20:57 PM
(https://i.ibb.co/DYPX2K7/M17-1808-frame-1.png) (https://i.ibb.co/Tc8ngcn/M17-1809-frame-1.png)
Test images:
Quote from: masc on February 17, 2019, 10:01:05 PM
Okay. Done. Here you are: https://www.dropbox.com/s/70ig9z535kixmk0/binningtest3.zip?dl=0
Quote from: a1ex on February 18, 2019, 08:50:45 PM
Pretty interesting binning pattern. It is, indeed, 3x3 readout with line/column skipping, i.e. using only one pixel out of 9. However, it has an additional property - every two columns are adjacent. This results in... even more moiré!
(https://a1ex.magiclantern.fm/bleeding-edge/lv-binning/binmode-3x3-rcskip-extrememoire.png)
Details: extreme-moire.html (https://a1ex.magiclantern.fm/bleeding-edge/lv-binning/extreme-moire.html)
Also confirmed the following binning pattern for the regular 1080p 3x3 mode on EOS M, likely used in most other Canons, with the same test code, on these test images (https://www.magiclantern.fm/forum/index.php?topic=9741.msg212227#msg212227). No write-up for this one yet.
Quote from: a1ex on January 21, 2016, 08:52:22 AM
(http://a1ex.magiclantern.fm/bleeding-edge/lv-binning/5d2-lv-binning-cell.png)
Ok found something :D
Danne told me how he got the ugly moire, (3x3 with horizontal pixel skipping and vertical line skipping).
And I can get it on the 6d too.
On 6d it has to do with 1x zoom and 5x zoom mode.
If you are in 5x zoom mode, no horizontal pixel binning is done.
In 5x zoom, when you alter 2 CMOS registers and the 800c lineskipping register and the 8000 register, to transform 5x zoom to normal full sensor view...you get the ugly moire.
So got me thinking, what crop_presets I made for 5x zoom mode which uses full sensor view...Oh no, the 1x3 readout mode :o
Remember this post:
https://www.magiclantern.fm/forum/index.php?topic=16516.msg210005#msg210005 (https://www.magiclantern.fm/forum/index.php?topic=16516.msg210005#msg210005)
I kept thinking about it, why does unstretched horizontal footage looks that bad, it's made of pixelbinned data where is al that moire coming from...
Well now we know, the example you see there is made in 5x zoom mode, so no horizontal pixelbinning was done there :P
Did some testing with a new 1x3 mode in 1 x zoom, and stretching that 3 times horizontal looks way better 8)
Getting late now, but maybe I can do some outdoor tests tomorrow, with some nice trees with breaches and stuff.
That's great @Levas, Maybe there is a register to control Binning Pixels? One of the ADTG registers? or maybe one of the CMOS registers that we don't know what's doing like CMOS 8? of course this only a guess, it will be cool if you or Danne start overriding and finding which registers control the Binning process (mv1080 vs x5 registers values), I don't have my cam to do that :P
Better late then never, here is some 1x3 footage from the 6d, stretched 3x horizontal to get 5K.
It's not bad, but once you compare it to a photo taken from the same scene, you see that this movie example is far from 5K :P
It's still a lot better then what I got before, now I'm using a setting that actually bins horizontally.
Here's the folder with the 5K movie clip and 3 JPG, one photo, one frame from the movie clip(1x3 stretched 3x horizontal) and one frame from a 3x3 movie blown up 300%.
https://drive.google.com/drive/folders/11_1RjTOQZPnhgJpxOQOp6xGSqbsnzSL2?usp=sharing (https://drive.google.com/drive/folders/11_1RjTOQZPnhgJpxOQOp6xGSqbsnzSL2?usp=sharing)
Horizontal? Care yo share source?
Sure, uploaded the source in the same folder:
https://drive.google.com/open?id=11_1RjTOQZPnhgJpxOQOp6xGSqbsnzSL2 (https://drive.google.com/open?id=11_1RjTOQZPnhgJpxOQOp6xGSqbsnzSL2)
First I had better results with stretching vertical, but that was because I was doing 1x3 without pixelbinning...didn't know that :P
So with horizontal stretch I got real bad results, lots of moire.
Now I'm doing 1x3 with pixelbinning and the results are better.
Quote from: theBilalFakhouri on February 19, 2019, 11:23:01 PM
That's great @Levas, Maybe there is a register to control Binning Pixels? One of the ADTG registers? or maybe one of the CMOS registers that we don't know what's doing like CMOS 8? of course this only a guess, it will be cool if you or Danne start overriding and finding which registers control the Binning process (mv1080 vs x5 registers values), I don't have my cam to do that :P
I guess that there is a ADTG register that controls the pixelbinning, probably one of these, haven't done any testing, but these look interesting as differences after pressing the magnifying button to go from 1 x zoom to 5 x zoom mode
https://docs.google.com/spreadsheets/d/1iapLI7UrgfCJGwPSFsyhYeKl8fSTY4RVXvDR7MiaOp4/edit#gid=591036118 (https://docs.google.com/spreadsheets/d/1iapLI7UrgfCJGwPSFsyhYeKl8fSTY4RVXvDR7MiaOp4/edit#gid=591036118)
Cool. Will check out during next week.
I think I found the registers for binning.
When I'm in 5x zoom mode, and I lock the values of ADTG2 [8183] and ADTG2 [8184] and go back to 1x zoom. I get really bad moire.
Value for 8183 and 8184 in 5x zoom are '0'
Normally in 1x zoom they are:
8183 = 0x35 (53 in decimals)
8184 = 0x3b (59 in decimals)
Not sure what those values mean in 1x zoom...but I'm curious what standard values for 8183 and 8184 on the 5d3 are, which does vertical binning.
Still have a little hope for vertical binning as on the 5d3 is just a register setting :P
Comparison, at 200%.
Above, normal horizontal pixelbinning.
Below, no horizontal pixelbinning (Register 8183 and 8184 set to value 0).
(https://farm8.staticflickr.com/7923/46473098014_4d159c1814_o.png)
Wow. Good catch dude. think you nailed it:
Tested on my eosm(mcm rewired mode):
adtg_new[18] = (struct adtg_new) {6, 0x8183, 0x21};
adtg_new[19] = (struct adtg_new) {6, 0x8184, 0x7b};
(https://i.postimg.cc/prHD3Sbm/Screenshot-2019-02-24-at-15-09-47-png-800px.png)
Zeroed:
adtg_new[18] = (struct adtg_new) {6, 0x8183, 0x0};
adtg_new[19] = (struct adtg_new) {6, 0x8184, 0x0};
(https://i.postimg.cc/1XrpSKsJ/Screenshot-2019-02-24-at-15-09-52-png-800px.png)
Keep looking maybe we can even eliminate focus pixels?
That's Great! Something is happening here, I hope we are not far away from vertical pixel binning but maybe also it is not that simple , we will see :D
Very nice find!
Quote from: Levas on February 24, 2019, 01:18:19 PM
... I'm curious what standard values for 8183 and 8184 on the 5d3 are
# same in 25/30/50/60p; same as EOS M
700D/1080p24.log:57631: 1.216.977 Evf:000179b0:91:01: [REG] ADTG:[0x81830021]
700D/1080p24.log:57638: 1.217.004 Evf:000179b0:91:01: [REG] ADTG:[0x8184007b]
# same in 1080p crop modes
700D/x5.log:1364: 4.437.292 Evf:000179b0:91:01: [REG] ADTG:[0x81830000]
700D/x5.log:1371: 4.437.319 Evf:000179b0:91:01: [REG] ADTG:[0x81840000]
# same in 25/30/50/60p; not set in x5
5D3/1080p24.log:17153: 1.178535 Evf:00011754:91:01: [REG] ADTG:[0x81830038]
5D3/1080p24.log:17167: 1.178565 Evf:00011754:91:01: [REG] ADTG:[0x8184002d]
# same in 25/30/50/60p and 640x480 crop 50/60p; not set in x5; same as 600D
60D/1080p25.LOG:14717: 1.987841 Evf:ff2c98b4:91:01: [REG] ADTG:[0x81830025]
60D/1080p25.LOG:14730: 1.987874 Evf:ff2c98b4:91:01: [REG] ADTG:[0x81840021]
# large value?
1100D/720p25-full.LOG:1077: 0.479142 Evf:ff2dbc54:91:01: [REG] ADTG:[0x818301c7]
1100D/720p25-full.LOG:1078: 0.479177 Evf:ff2dbc54:91:01: [REG] ADTG:[0x818401c0]
# same in 25/30p; not set in x5
5D2/1080p24.log:27234: 0.533919 LiveViewMg:ffa35de8:91:01: [REG] ADTG:[0x1183003c]
5D2/1080p24.log:27261: 0.534003 LiveViewMg:ffa35de8:91:01: [REG] ADTG:[0x1184003a]
# close to 1100D?
500D-dm-0009.log:14833:5C89C> LiveViewMg:ff22f9b4:91:01: [REG] ADTG:[0x118301c6]
500D-dm-0009.log:14836:5C933> LiveViewMg:ff22f9b4:91:01: [REG] ADTG:[0x118401c0]
Thumbs up @Levas! 8)
Thanks for the numbers Alex.
https://docs.google.com/spreadsheets/d/1iapLI7UrgfCJGwPSFsyhYeKl8fSTY4RVXvDR7MiaOp4/edit#gid=1718744807 (https://docs.google.com/spreadsheets/d/1iapLI7UrgfCJGwPSFsyhYeKl8fSTY4RVXvDR7MiaOp4/edit#gid=1718744807)
Register 5D3 5D2 6D EOS M / 700D 60D 500D 1100D
8183 / 1183 0x38 (56 dec) 0x3c (60 dec) 0x35 (53 dec) 0x21 (33 dec) 0x25 (37 dec) 0x1c6 (454 dec) 0x1c7 (455 dec)
8184 / 1184 0x2d (45 dec) 0x3a (58 dec) 0x3b (59 dec) 0x7b (123 dec) 0x21 (33 dec) 0x1c0 (448 dec) 0x1c0 (448 dec)
Resolution 5760 x 3840 5616 x 3744 5472 x 3648 5184 x 3456 5184 x 3456 4752 x 3168 4272 x 2848
The register values of the fullframe camera's are close to each other, as is their resolution.
EOS M / 700D are just weird :P small 8183 value, big 8184 value.
And both 500D and 1100D have really hit values, why ?
Where is the logic :-\
Something I don't understand very well, How does Binning pixels happen? For example in 5D3 it is binning the whole pixels in the sensor to 1920x1280 in video mode so it uses the whole pixels , should this mean that the camera do 5760x3840 @ 24 FPS ? But downscaled to 1920x1080?
How this process works if it reads the whole pixels? And we know the sensor speed is slow . . Short question:
What the difference between Full-Res LiveView in 1x1 sampling (It uses all the pixels in the sensor without Binning) and the Binned 3x3 mode (it uses all pixels too, but with Binning and it can do it in much higher frame rate 30 FPS compared to 7.4 FPS).
What is the pipeline here for each mode?
@a1ex Can you explain? :D
First post. TLDR - pixel binning happens in analog domain. It's not done digitally.
Pixel readout clocks (FPS timer A and B) are applied after binning.
Pixel binning mode will affect timer A limit on some models, but not by much (it won't change the order of magnitude). IIRC it doesn't happen on 700D, but need to double-check. It does happen on 5D3, e.g. in 3x3 it accepts 398, but in 5x3 it can't go lower than 410.
Quote from: Levas on February 27, 2019, 08:26:21 PM
Register 5D3 5D2 6D EOS M / 700D 60D 500D 1100D
8183 / 1183 0x38 (56 dec) 0x3c (60 dec) 0x35 (53 dec) 0x21 (33 dec) 0x25 (37 dec) 0x1c6 (454 dec) 0x1c7 (455 dec)
8184 / 1184 0x2d (45 dec) 0x3a (58 dec) 0x3b (59 dec) 0x7b (123 dec) 0x21 (33 dec) 0x1c0 (448 dec) 0x1c0 (448 dec)
Resolution 5760 x 3840 5616 x 3744 5472 x 3648 5184 x 3456 5184 x 3456 4752 x 3168 4272 x 2848
The register values of the fullframe camera's are close to each other, as is their resolution.
EOS M / 700D are just weird :P small 8183 value, big 8184 value.
And both 500D and 1100D have really hit values, why ?
Where is the logic :-\
Isn't it typical for Canon cams to combine several fields (of arbitrary bitlenght) in one register, like it usually on every microcontroller is? Then you shouldn't analyze the whole register value but the value of each bit or field inside. If the whole is "big" or "small" would mean nothing, as the bits at different
positions would have different meaning. But then it would be nice to find out what is the organization of the fields in a reg. Not trivial.
I don't know a big extent of the ML code but so far only seen a combination of two 16-bit words in one 32-bit reg. Anywhere are smaller fields used? Several 8-bit or even smaller, down to 1-bit fields?
Levas, already tried the values from 5D3 on your 6D? :)
Quote from: ArcziPL on March 10, 2019, 11:48:03 PM
Levas, already tried the values from 5D3 on your 6D? :)
First thing I tested :D
Didn't work, did some more testing at the time, there seems to be some headroom in it, changing the registers by one or two values didn't do much, when changing enough, you get either part of your frame bright and another part stays normal or the whole frame becomes bright. When going to 5x zoom you'll see bright and dark columns.
Couldn't find any logic in it.
Quote from: Levas on March 11, 2019, 10:14:16 AMchanging the registers by one or two values didn't do much, when changing enough, you get either part of your frame bright and another part stays normal or the whole frame becomes bright. When going to 5x zoom you'll see bright and dark columns.
Couldn't find any logic in it.
That's exactly how it would behave if my theory is true, i.e. the register content would consist of a several independent fields. I'd suggest to change single bits in these regs, then maybe changing pairs of neighbouring bits or each nibble (upper and lower half-byte) separately -- it would be great to find out how they are organized. On DIGIC 5 cams these registers
seem to be 8-bit wide.
I'll try on my cams.
It's really weird. After playing with these two regs on 700D there are vertical stripes appearing, which stay even after returning to the original values, and then they slowly vanish, which takes several seconds.
But zeoring both in non-cropped mv1080 indeed looks like disabling column binning, as artifacts appear on vertical lines.
Found 3 different column/pinning mode on the 50D with cmos[4]
1.67x vertical
3.0x vertical
4.5x vertical
currently , with can't embed photo's anymore ( or I should say there's no button to embed in post)
so I loaded the photo on my bitbucket downloads
cmos[4] 0x40c -> 0x2B
This looks right with 1.67x vertical stretch , un-stretch frame M21-2361_frame_1.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M21-2361_frame_1.png) , stretch frame 1.67XVertical-M21-2361_frame_1.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/1.67XVertical-M21-2361_frame_1.png)
1568x1764
(https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M21-2361_frame_1_small.png) (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/1.67XVertical-M21-2361_frame_1_small.png)
cmos[4] 0x40c -> 0x25
3.0x vertical stretch , un-stretch frame M21-2357_frame_75.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M21-2357_frame_75.png) ,
stretch 3.0XVertical-M21-2357_frame_75.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/3.0XVertical-M21-2357_frame_75.png)
1568x3168
(https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M21-2357_frame_75-small.png) (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/3.0XVertical-M21-2357_frame_75_small.png)
cmos[4] 0x40c -> 0x34
4.5x vertical (450%) , Un-stretch frame M22-0003_frame_100.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M22-0003_frame_100.png)
stretch frame 4.5XVertical-M22-0003_frame_100.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/4.5XVertical-M22-0003_frame_100.png)
1568x4752
(https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M22-0003_frame_100_small.png) (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/4.5XVertical-M22-0003_frame_100_small.png)
Attn: Mod. , if you want to change the formatting please go ahead.
These registers controls also line skipping beside 800c
ADTG 8007
ADTG 8008
I didn't find something useful about them
Also these
8075
8076
I think I found a 2x pixel binning mode on 5d2 in 5xzoom
playing around with cmos[0] 20f --> 60f
Still pretty rough at this point would more reg to clean the edges
So I stated off at 2144 (default 5xzoom) it pushed it to the left and cut off 366 columns to end up with 1778
(https://i.ibb.co/RpMs3Fd/RAW-001-small.png) (https://imgbb.com/)
1778x1075_RAW-0011.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/RAW-0011.png)
So I resized the horizontal by 200% (1778*200% = 3556)
(https://i.ibb.co/3MBDrnm/RAW-001-1x2-pinning-small.png) (https://imgbb.com/)
3556x1075_RAW-001_1x2-pinning.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/RAW-001_1x2-pinning.png)
Just seeing if there a better way to get full HD image in like 3x3 but in 5xzoom for full 16x9 HD :D
Edit:
Default 5xZoom (2144x1074)
(https://i.ibb.co/Ydwy4nL/M19-1805-frame-1-small.png) (https://imgbb.com/)
So It looks like that cmos[0] reg is giving me the full width view in 5xzoom , everything on the right is now viewable
it looks I my be on to something here , need to that a deep dive and see what I do with this .
edit#2:
wondering if I possible found sRAW1 mode (10 megapixel/3861 × 2574 pixels) eos5dm2/specifications.htm (http://web.canon.jp/imaging/eosd/eos5dm2/specifications.htm)
seems awfully close 3556 to 3861 :o
Yes I can get the full width view with
CMOS[0] 0x207->0x607 in
5xzoom on 5d2
I pushed the raw size horizontally to 2752 with the reg set 0x607 and it the full view
width , will close 5504(H) still not prefect by no means there some stair steps lines
but , could be useful .
(https://i.ibb.co/NZhM1fk/M19-2358-frame-20-small.png) (https://imgbb.com/)
2752x2034_M19-2358_frame_20.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M19-2358_frame_20.png)
(https://i.ibb.co/g4xfbp3/M19-2358-frame-21-small.png) (https://imgbb.com/)
5504x2034_M19-2358_frame_21.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/M19-2358_frame_21.png)
I get around 15fps with 2752x2034 , 1x3 is still more efficient at
[email protected] .
It's interesting that cmos[0] & cmos[2] can control pixel binning .
Great find, i hope its not uncompressed mlv thats limiting findings, with eos M its impossible to record uncompressed in such resolutions because of camera card reader/writer speed limitation and lossless was a saviour for this camera.
It seems ADTG2[8000] controls Horizontal Binning/Skipping but only in 1x3 mode, ADTG2[8000] default values is 0x6 in mv1080, tweaking it to 0x5 provide two things:
1x3 Mode with Horizontals Pixel Skipping
Let's set 1x3 mode from ADTG2[800C], 0x2 to 0x0, then tweak ADTG2[8000] from 0x6 to 0x5 back and fourth, you get Horizontals Pixel Skipping/Binning game:
https://youtu.be/nC5QMrPvYI0
Like Magic
You can't re-bin Horizontal Pixels by ADTG2[8183], you can do the experiment using ADTG2[800C] and ADTG2[8183] without ADTG2[8000], but a quick note, if a register like ADTG2[8000] related to sensor sampling and Binning/Skipping has two effects at once, it might other registers related to Sensor Sampling/Binning/Skipping also have more than one effect, maybe.
I think Levas found out about how reg 8000 affected binning when playing with 3x1 presets. Anyway. 0.6 seems the correct one at least with 1x3 binning:
(https://i.postimg.cc/XNGWHNKD/Screenshot-2020-07-22-at-15-14-10-png-scaled.png)
0x6
(https://i.postimg.cc/CdTmJsCY/Screenshot-2020-07-22-at-15-14-21-png-scaled.png)
0x5
(https://i.postimg.cc/1zJ7P6Sc/Screenshot-2020-07-22-at-15-14-28-png-scaled.png)
I remember Levas solved Jagged-Lines issue in 3x1 Mode by tweaking ADTG [8000] in x5 mode on 6D, I couldn't solve it back then, but now I have tried again and now it re-solved "Jagged-Lines" for 3x1 on 700D by making these changes:
8183 from 0x21 to 0x0
8184 from 7b to 0x0
When I tweak ADTG [8000] from 0x6 to 0x5 on 700D, I forced into 1x3 Mode, I can't stay in 3x3 when changing ADTG [8000] from 0x6 to 0x5, so I can't get Horizontals Pixel Skipping in 3x3 unlike the 6D? like the examples you posted above . .
Examples above are for eosm:
case CROP_PRESET_anamorphic_rewired_EOSM:
case CROP_PRESET_anamorphic_rewired_flv_EOSM:
case CROP_PRESET_anamorphic_rewired_100D:
adtg_new[2] = (struct adtg_new) {6, 0x800C, 0 + reg_800c};
adtg_new[3] = (struct adtg_new) {6, 0x8000, 6};
adtg_new[17] = (struct adtg_new) {6, 0x8183, 0x21 + reg_8183};
adtg_new[18] = (struct adtg_new) {6, 0x8184, 0x7b + reg_8184};
break;
Investigating pixel binning on the 5d2 in 3x3 mode with cmos[0], I found out that cmos[0] changes
the pixel binning in 3x3 from 3 line skipping to 1.67 "aka" 720p 60" mode on my 5d2
cmos[0] 0x20b ->60b , because cmos[2](0xe) I can increase the horizontal from 1880 to 2456x940(24.03fps) = 2456x1566 , see image below , frame exported from mlv app.
(https://i.ibb.co/YfH87m5/RAW-044-small.png) (https://imgbb.com/)
5d2_2456x940_RAW-044.DNG (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/RAW-044.DNG)
(https://i.ibb.co/8dM7CFy/VRAM115-small.png) (https://imgbb.com/)
(https://i.ibb.co/6b4c3R5/1-67-pixel-7-22-2020-M22-2318-frame-1-small.png) (https://imgbb.com/)
5d2_1.67_pixel_7-22-2020_M22-2318_frame_1.png (https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/1.67_pixel_7-22-2020_M22-2318_frame_1.png)
There needs to be more reg's (atdg to cleanup the edges) but this interesting , FYI it is full view there no crop factor .
This close to the 3x1 but instead of even third line it's 1.67 or so it's I guess it's 5x3 if it was 1880 but horizontal is in 1:1 mode so 5x1 ?
maybe better just to keep it 5x3 :-\
I'm doing some tests and I think to have found something interesting about the binning...
To double check it, I would like to play a bit with some settings to the the cmos registers.
Since I'm using the latest eos-m Danne release and the Adtg module is not included, is there an alternative way to adjust those registers without recompiling ML?
I've seen similarly called registers inside the page: Movie -> presets -> advanced
Can anyone confirm if they are exactly the same?
Thanks!
The adtg module can be downloaded seperate:
https://builds.magiclantern.fm/modules.html (https://builds.magiclantern.fm/modules.html)
The adtg module is at the bottom of the page, I think it would work with the build you're using now.
But you can't use it while enabling high resolution modes or other crop_rec presets, best to turn them off while using adtg module.
High resolution crop modes use overriding registers just as you can do with the Adtg module, so when using both at the same time you're not really sure if your adtg override settings are set or not.
And in case of weird shit, be prepared to pull the battery to prevent bricking your camera :P
Thanks Levas!
I already entered that page but I missed the module from the list. Now I got it!
I'm gonna install the module following your suggestions for doing the tests. :)
As soon as I am ready, I'll share my results here and I would be pleased if you and the other experienced guys can comment on them. :-\