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

[dfort]

@ibrahim - Off topic, the 600D isn't supported in the crop_rec_4k branch. You will have better luck asking on the Canon 600D / T3i topic.

[mr.smith]

Please tell me.
Do you have plan to add Full-resolution LiveView: 5796x3870 at 24 fps(8bit or 10bit) in the near future?
Or, add normal 4k with 16:9 aspect ratio?
I want to use Magic Lantern normally.
If 16:9 aspect ratio feature has in ML, more people use ML, I think.

[Levas]

4k or higher resolutions in 24/25fps in 16:9 ratio probably never become reality.
Hardware limitations, the sensor can’t be readout that fast.
With current crop_rec options it’s already reading 150Megapixel per second.

See also this post from 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.

[mothaibaphoto]

4k or higher resolutions in 24/25fps in 16:9 ratio probably never become reality.

Never say "never"
Actually, it's a question of porting ML to Digic 6+.

[Levas]

You're right, I forgot to add "On the Canon 5d3" 
Other cams, that's a different story.

[jimiz]

I think , time come a working raw 14 bit 4K without problems and limits also in a 5d4....the price of the 5d4 used will be 50$ ...   

[mvrck]

Something weird happened with the latest March 10th build on my 700D. MLVProducer (3261) couldn't properly remove the focus dots in my footage and was completely incapable of removing false colour artifacts. I switched back to the February 24th build and everything worked correctly with it. I have no idea where the problem could be exactly, but I thought I'd report.

[Kharak]

Something weird happened with the latest March 10th build on my 700D. MLVProducer (3261) couldn't properly remove the focus dots in my footage and was completely incapable of removing false colour artifacts. I switched back to the February 24th build and everything worked correctly with it. I have no idea where the problem could be exactly, but I thought I'd report.

If you read the very first commit change of the build
57614b3:
Raw backend: use (*height)-- adjustment on all DIGIC 5 models
700D, 650D, 100D, M: fine-tuned skip offsets
Allow odd values for skip_bottom
650D/M x5 zoom: skip_top is the same as with regular 1080p or 720p or mv1080crop
700D/650D/M 720p
before: H=727, skip_bottom = 4 => active area y2=723 (real 724)
after: H=725, skip_bottom = 1 => active area y2=724
100D 720p:
before: H=726, skip_bottom = 4 => active area y2=722 (real 724)
after: H=726, skip_bottom = 2 => active area y2=724
650D/M 1080p:
before: H=1190, skip_bottom = 4 => active area y2=1186 (2 white lines at bottom)
after: H=1188, skip_bottom = 0 => active area y2=1188 (no bad lines at bottom)
EOSM movie crop: H=1060, top=28, active area y2=1060, no bad lines at bottom
(unsure about skip_bottom on 100D - to be tested with a silent DNG in movie crop mode)
See also:
https://www.magiclantern.fm/forum/index.php?topic=18443.msg198140#msg198140
https://www.magiclantern.fm/forum/index.php?topic=16054.msg195213#msg195213

In english, it means that the recorded image has been moved a few pixels, so your FPM (Focus Pixel Map) is now invalid. AWPstar has to update his FPM in MLVProducer.

[a1ex]

The MLV metadata contains the offset for this change (so, unless the maps are hardcoded for some particular video mode, things should work). Only the x5 zoom was affected - the top offset in that mode was incorrect on these models (there were two black pixels at the top).

Example metadata from 5D3, with a similar change (just to make sure the focus pixel tools have the metadata for aligning the maps). Before:

Code: [Select]

Block: RAWI
    Res:  1920x1080
    raw_info:
      height           1380
      width            3744
      active_area.y1   60
      active_area.x1   146
      active_area.y2   1380
      active_area.x2   3742
Block: VIDF
    Crop: 1824x300

After:

Code: [Select]

Block: RAWI
    Res:  1920x1080
    raw_info:
      height           1380
      width            3744
      active_area.y1   62
      active_area.x1   146
      active_area.y2   1380
      active_area.x2   3742
Block: VIDF
    Crop: 1824x300

In both cases, it's the crop field that shows what area was recorded from the full-size raw buffer, relative to the first pixel in a silent DNG, which contains the complete raw buffer (caveat: the offsets are not relative to the first active pixel, but to the first - usually black - pixel). That's the metadata to be used for aligning the focus pixel maps.

In this particular case, the recorded area was not changed at all, but the metadata does show some difference. If the focus maps were aligned on the first active pixel (which changed in the metadata), then we have a problem (of not following the spec).

I'm unable to predict the exact metadata from the 700D, sorry. The crop offset might have been changed, or might have not - I have no idea. Please post the relevant lines from mlv_dump -v, as in the above example.

[dfort]

700D

Before:

Code: [Select]

Block: RAWI
    Res:  1920x1080
    raw_info:
      height           1108
      width            2592
      active_area.y1   26
      active_area.x1   72
      active_area.y2   1108
      active_area.x2   2592
Block: VIDF
    Crop: 280x28

After:

Code: [Select]

Block: RAWI
    Res:  1920x1078
    raw_info:
      height           1106
      width            2592
      active_area.y1   28
      active_area.x1   72
      active_area.y2   1106
      active_area.x2   2592
Block: VIDF
    Crop: 280x28

Now for the strange part -- I'm seeing focus pixels too but only on lossless compressed files. Looked at the metadata on the uncompressed footage and it was the same as the lossless compressed. Seems to be a recurring problem.  Stranger still is that my map files were updated in January and should work fine with these files but aren't being accepted by the app developers so that's why we're seeing focus pixels.

[a1ex]

That "could have pixels shifted 8-pixels to the right" sounds fishy. No metadata difference?

One strange notice:

In fact now that I reviewed them I'm not sure why I included Crop in my script, only Pan is needed to line up the focus pixel maps.

Correction: only crop is needed to line up the focus pixel maps (at least in theory). These offsets will match the edmac_copy_rectangle call.

Wait a minute, found the bug. The lossless compression routine uses a different rounding - that explains the 8-pixel offset. Whoops...

Hotfix:

Code: [Select]

diff -r fe4e5f79138f modules/mlv_lite/mlv_lite.c
--- a/modules/mlv_lite/mlv_lite.c
+++ b/modules/mlv_lite/mlv_lite.c
@@ -2494,7 +2494,7 @@
 
             int compressed_size = lossless_compress_raw_rectangle(
                 outSuite, fullSizeBuffer,
-                raw_info.width, skip_x, skip_y,
+                raw_info.width, (skip_x + 7) & ~7, skip_y & ~1,
                 res_x, res_y
             );

Workaround for existing files: panPosX & ~7 will give the correct X offset for existing lossless files, while (panPosX + 7) & ~7 should match cropPosX and should be correct for uncompressed files. Focus pixel maps covering both "original" and "offset by 8" are also a good workaround.

For lossless files where panPosX is multiple of 8, the metadata is correct (both rounding methods will give the same result).


In any case, this not a difference between March 10th and February 24th build. The only difference that could affect focus pixel maps, between these two builds, is the 2px difference in the top optical black bar. Recorded area was not changed in the particular case tested by dfort (which may or may not match the initial report).

[dfort]

Dots be gone 

My map files still work though they are now overkill.

Correction: only crop is needed to line up the focus pixel maps (at least in theory).

Right, corrected that on the post. Though my script is converting Pan to Crop because of a bug that was fixed a while back:

Code: [Select]

##
# Allow for legacy MLV files with cropX, cropY bug
#
cropX=$((panPosX + 7 & ~7))
cropY=$((panPosY & ~1))

Déjà vu.

[vstrglv]

magiclantern-crop_rec_4k.2018Mar10.5D3113 Thank you very much!
One Q: how to set 5796x3870 @ 5p. Only 5784x3870 is available. And what about FPS 5p? Low light or Exact FPS?

[a1ex]

Low light should be fine; however, the two settings (FPS override and crop_rec) are conflicting, as they override the same registers. Use with care - not all settings are working. In particular, the newest shutter speed option doesn't seem to work well with FPS override, regardless of the preset (just tested).

I've started to rewrite the backend to handle both features (and upcoming ones) without conflicts, but didn't get very far.

Easiest workaround: I could add a basic FPS option in the crop_rec submenu (already having that locally, as timer overrides).

[vstrglv]

Thank you Alex for reply.
But in case of 5796x3870 @ 5p,  FPS override must be on. And what about 5796?

[a1ex]

That works with the silent picture module (which saves the entire image, including black borders); mlv_lite needs to start and stop recording at 8 pixel boundaries and skips the black borders; therefore, it crops 6 good pixels from the left and 6 from the right (in this particular case, with skip_left = 138 and skip_right = 2). Declare these two as 136 and 0 in raw.c and you should get 5800 in raw video menu, then crop 2 columns from the left and 2 from the right in post to get 5796.

[vstrglv]

Thank you for clarifying.

[Tony Weller]

Any way to lock the half-shutter zoom view on without pressing the button?  I find that view very useful.

[Walter Schulz]

Try Prefs tab -> Misc key settings -> Sticky HalfShutter.

[a1ex]

I have a feeling the question was about the preview, where half-shutter toggles between real-time and framing-accurate. In this case, the option is in the raw video submenu (press Q).

FYI, sticky half-shutter does not come without side effects (locks up the GUI while it's sticky).

[Tony Weller]

Sticky-half-shutter was indeed what I was after, thank you.

[Tony Weller]

So I switched preview to real time and x5 jumps straight to that view, focus dots, histo and all without touching the shutter button and sticky-half-shutter off but I have a feeling that's how it worked anyway and I got confused but all good now. Framing not really essential as I have markers on lcd screen.

Just what I needed, thanks.

[Mikv]

Hello Guys,
I would like to share with you my fresh done test with the last build of the crop module for my 5D Mark III V1.2.3 (2018Mar10).
My purpose was to try to use an anamorphic adapter on an already 2,35:1 crop. My curiosity was about to see if after the squeeze of the images at this resolution is still useable without crop it in post.
It's really ultra anamorphic but I love it, what do you think?

- Resolution: 1920 X 818 @50p
- Format: Mlv Lite 14bit
- Sound: On
- Recording Media: Lexar 1066x 64GB

No color correction was made, just a bit of adjustment thru Camera Raw but very little, I love the color of my anamorphic converter together with the Magic Lantern Raw.

As usual the recording time is unpredictable, sometimes the camera let me shoot long shot, sometimes very short.

A super THANK YOU to all the people involved in the making of this awesome crop module!

Enjoy 

[OlRivrRat]

   A few days ago I grabbed the SL1 to get some QuickShots of some Nicely Lit Clouds &

the 1st 2 ended up with Odd Patterns in them. Has anyone else had the happen?

https://photos.app.goo.gl/1TSGDdHFbZEwhM5F2

       SL1 was running on > magiclantern-crop_rec_4k.2018Mar10.100D101

[tigerbengal2009]

Hi everyone, a quick question/clarification about mlv_lite 60p
Canon 5d MIII firmware 113, ML4k firmware March 10 2018, lexar 64gb 1066x.
canon menu : video 1280x720 60p ALL-I
modules loaded: mlv_lite, crop_rec
RAW video ON, 1920x800
crop mode, enable, 1920 50/60 3x3 selected

I cannot get continues recording...only 20, or 25 30 seconds.

If I press the magnify  button one time, 5x, the video is no longer 59.940 (60p) it changes to 29.776 (30p) is that normal? or is anything else I have to change to get the 60p when I am in 5x?