crop_rec on steroids: 3K, 4K, 1080p48, full-resolution LiveView

[Danne]

Getting some compile error with mlv_rec and mlv_snd in crop_rec_4k branch.

Code: [Select]

Building module mlv_rec...
Updated HGVERSION
[ README   ]   module_strings.h
[ CC       ]   mlv_rec.o
mlv_rec.c: In function 'raw_rec_update_preview':
mlv_rec.c:4160:5: error: too few arguments to function 'raw_set_preview_rect'
     raw_set_preview_rect(skip_x, skip_y, res_x, res_y);
     ^
In file included from ../lv_rec/lv_rec.h:24:0,
                 from mlv_rec.c:76:
../../src/raw.h:148:6: note: declared here
 void raw_set_preview_rect(int x, int y, int w, int h, int obey_info_bars);
      ^
make[4]: *** [mlv_rec.o] Error 1

Don´t have my camera to test but I follow the error and change the line in mlv_rec to below which seems to get rid of the error code for both mlv_snd and mlv_rec.
In mlv_rec

Code: [Select]

raw_set_preview_rect(skip_x, skip_y, res_x, res_y);to this:

Code: [Select]

void raw_set_preview_rect(int x, int y, int w, int h, int obey_info_bars);Or maybe change to:

Code: [Select]

void raw_set_preview_rect(skip_x, skip_y, res_x, res_y);
?

[andy kh]

this is wonderful. need to start looking for a used 5D mark III

[ItsMeLenny]

Well I guess the original 4K trolls are no longer trolls.
But if 4K is possible that must mean 1000fps is as well.

[kaco]

Respect to a1ex and the whole magiclantern team.
No more excuses for not producing world class imagery.

[dfort]

Is it difficult to port to other camera models?

So far, the 3x3 720p mode from crop_rec was ported to EOS M (rbrune) and 700D (dfort). So it shouldn't be that hard...

I'll take that as a compliment!

That reminds me, I should do a pull request for the 700D but it looks like there's more work to do now. How about getting some other cameras up to speed on the crop_rec module? By the way, don't expect 4k on anything other than the 5D3--then again maybe there will be more surprises.

[a1ex]

Yep - my point was that people outside the core team are definitely able to play with this code (as in, it's not pure black magic).

Took this build out for a test (nothing fancy, just taking pictures of the kids with full-res LiveView and pre-recording). Noticed a major limitation (could not set shutter speeds fast enough for daylight) and pushed a fix for that.

After the fix, modes with reduced FPS (4K and full-res LiveView) now have the usual range of 1/4000...1/30 (or 1/60) mapped to 1/15000 to 1/fps. That's right - 1/15000 exposure time with 128ms rolling shutter

Next annoyance was the grayscale preview, which is slow and not working at all in 10-bit. Also, lossless MLVs are not playable in mlv_play. Will look into those.

[hyalinejim]

a1ex,  if you can improve the greyscale preview you will be the king of kings

[Greg]

These are just approximate calculations. You can initially estimate the speed of the sensor.

5D3 22MPx x 6fps = 132MPx/s
4096px x 2560px x 12.5fps = 131MPx/s

7D   18MPx x 8fps = 144MPx/s
70D 20MPx x 7fps = 140MPx/s
6D   20MPx x 4.5fps = 90MPx/s

500D 15MPx x 3.4fps = 51MPx/s 
Btw, my 4 year old smartphone 8MPx x 30fps = 240MPx/s 

More accurate calculations - https://www.magiclantern.fm/forum/index.php?topic=12656.0
Of course we must remember about the speed of writing.

[dfort]

Yep - my point was that people outside the core team are definitely able to play with this code (as in, it's not pure black magic).

My point too. I'd like to get some more people to start playing with the code. There's lots of information in the comments and on the forum that takes the mystery out of what's going on--though some of what you're doing sure seems like pure black magic.

[ilia3101]

@Greg
and the rather slow 5D2: 21.2MPx x 3.9fps = 82.68MPx/s. Does this basically tell us the limit of the sensor? So this calculation works: 82.68/23.976 = 3.45MPx limit at 24p on this camera? So I guess it could do 2560x1320(3.38MPx).
  how does one implement the "Greg's resolution hack" that I've been hearing about?

[vstrglv]

Fantastic! Thank you very much!
One Q about * 1920x960 @ 50p (both 1:1 crop and full-frame - 3x3 pixel binning).
1920x960 @ 50p (3x3 pixel binning) works good, but i can not set 1920x960 @ 50p for 1:1 crop, only 1920X632.
I set Crop mode - 1920 1:1 and 50p in Canon menu.

[nikfreak]

how does one implement the "Greg's resolution hack" that I've been hearing about?

http://www.magiclantern.fm/forum/index.php?topic=19300.msg182149#msg182149

[reddeercity]

@Ilia3101 I'm working on it  , just had some compiling issue with adtg_gui yesterday should have that resolve
today , then I can work off a1ex's links 

[a1ex]

1920x960 @ 50p (3x3 pixel binning) works good, but i can not set 1920x960 @ 50p for 1:1 crop, only 1920X632.
I set Crop mode - 1920 1:1 and 50p in Canon menu.

1920 1:1 tall (meaning "with increased vertical resolution", but couldn't fit that into menu)

[vstrglv]

Thank you! It works good!

[a1ex]

Updated the preview with something a little more usable. It's color (though still low-res and non-realtime) and only drops to grayscale when recording speed becomes critical.

Unfortunately, g3gg0's raw_twk routine doesn't appear to work in LiveView, so we are stuck with (slow) CPU-based previews for now

I can probably get faster previews in 14-bit lossless mode, by configuring the source raw stream as 16-bit (unpacked), since the compression routine accepts 10/12/14/16-bit input. For uncompressed modes, I'm afraid we currently don't have a way to get both unpacked data (for fast previews) and bit-packed (for recording) while in LiveView (so all my previous ideas are currently fiction).

New build posted on the Experiments page.

[mk11174]

Trying to see what the next step is to see if there are any modes 700d can get, first i messed with atdg tool to try to reproduce the 3x3bin mode while in 720p by changing 0x4 to 0x2 on 800c just to understand how the tool works since those values are posted. I then set the tool to show values that have been changed more then twice and screen captured every value for 1080p, 1080p x5 and x10, 720p, 720p x5 and x10, crop mode in 1080p and also photo mode just to track all the values that are changing in case it was needed.

Thats where i am at now though, not sure what values to change though, gets scary when you see the crazy images on live view that make u think u burned sensor out. Only thing i saw that did anything as far as the size was 800c changing to 0x0 makes a zoomed version but its stretched tall. Other then that another one moved the image up and down.

Dont know how to cross reference with the 5d3 cause i see Pack12(?,?)  for example and the values are not like what you see in the tool. So pretty much clueless on where to go from here??

[hyalinejim]

Wow! That's a hell of a lot more useable and the preview is centered which is absolutely kickass.

I get 30 frames in UHD, but 3K is still continuous for me in crop_rec. The preview does drop back to greyscale about 50% of the time in 3K. The colour preview is more detailed and has a higher refresh rate... it's pretty much usable, I think.

[WonkyTuna]

I'm trying it out but unfortunately when I try to watch it on MlRawViewer or export it to DNGs using RAWMagic I'm left with this: https://drive.google.com/open?id=0B1lko58z3g6lRTlKUWc1YzlzOFk. I tried re-downloading the build and formatting my card but I can't seem to get anything out of any of these crop modes...

[squig]

I've found a couple of issues in both builds. The first is nothing major: when you change a resolution in the crop mode menu, say 3K to UHD, you have to exit the ML menu before you can adjust the resolution size in the raw video menu. The other issue is making me pull out what little hair I have left: the lossless compression ratio appears to have a mind of its own, it's like a recalcitrant AI. At one point it was compressing at 51% on the 1st build:



When I loaded the 2nd build it started at 85%:



So I had to scale down to:



After a few seconds of recording the compression went to 70%:



Then when I try to increase the resolution I get this [Expect xxxx frames]:



A battery pull gets rid of the [Expect xxxx frames], but on the 2nd build it reappears when I try to scale up the resolution. So I went back to the 1st build to see if I could record at 3.3K 51% lossless again. Initially I was able to get this setting:



That was a bit much for the card, it stopped recording after a few seconds resulting in the dreaded [Expect xxxx frames]:



Taking me back to square one where I had to scale the resolution back down:



Ideally the compression ratio would either be fixed, or manually adjustable.

[dmilligan]

Ideally the compression ratio would either be fixed, or manually adjustable.

That's mathematically impossible, and not how lossless compression works. The compression ratio you get is totally dependent on the scene, and it's even theoretically possible that the compression results in larger file sizes than the original uncompressed data. This typically happens when you give a lossless compression algorithm data that has very little redundancy (already compressed), or that is not of a type the algorithm is "tuned" for, for example feeding the compressor 10-bit raw data results in the compressed version actually being larger.

For the most part, lossless compression algorithms work by simply eliminating redundant data via more efficient encoding. Take some text for example, encoded using ASCII, each character takes 1 byte to store and therefore all characters have equal weight even ones that are rarely used. However we know that in any particular language there are characters (or even sequences of characters) that typically appear more often than others, so if we gave the characters that appear more frequently, shorter encodings (which subsequently requires less common characters to have longer encodings), then overall we can save space. However if we were to feed random gibberish to such an algorithm, it might actually take more total space the store than the original simple encoding, since the characters with longer encodings are just as likely to appear as ones with shorter encodings.

[squig]

Understood, but from a cinematography perspective; I need to figure out what resolution will give the card enough headroom to write at that resolution continuously at least 90-95% of the time; so far it looks like that's somewhere in the 2.5-2.6K range for 24p 2.39:1, which is still great.

[squig]

2.7-2.8K 2.39:1 looks like the sweet spot for repeatable continuous recording on the Toshiba 1066x card. By "repeatable" I mean repeatable near 100% of the time. Same goes for 3.3K anamorphic scope: 2272x1364 with a 1.5x anamorphic lens.

[GutterPump]

Updated the preview with something a little more usable. It's color (though still low-res and non-realtime) and only drops to grayscale when recording speed becomes critical.

DAMN ! This update is very promising. I did some tests and yes it's more comfy for framing.
Thanks you for all these exciting features A1ex and all the team.

[hyalinejim]

OK, I'm pretty sure that the 14bit lossless compression varies with ISO.

In crop_rec 3K (3072 x 1286 ) I can get continuous recording at ISO 100

But if I whack the ISO up to 6400 I only get eleven seconds.