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

[Lars Steenhoff]

Thanks for the workaround for mlv_play +mlv_rec !

[Danne]

@A1ex
I had issues before as well but, as I was testing before I think the issues dissapeared. Not entirely sure, was very tired when checking the first time. I think the issues was there from the start on the 100D. Is it acting weird with other cameras?

[Lars Steenhoff]

I have one issue, When I use the config preset startup key (MENU) and I save the config will the crop module selected for load at startup, it does not load the module.

[vstrglv]

Alex, thanks for the workaround for mlv_rec+silent picture module+ mlv_play. But preview works only for 14bpp. There is black screen for 12,10bpp. Canon 5D3.

[Danne]

Was fooling around recording 2520x1080p 8 seconds takes with my 100D in 24fps. The following issue appears in every single file:
http://www.magiclantern.fm/forum/index.php?topic=19300.msg189633#msg189633
Doubled frames causing a slip here and there in the files. What´s also fishy is that the first frame in the following recorded clip will contain one frame from the preceeding file. Not all files but most when filming 2520x1080p. It´s like it´s still in memory in the camera and wants out. Said and done. What to try next. Disabling srm memory maybe helps but no, the problem persists. I then tried lowering aspect ratio to 3xzoom 1920x1080p and the problem is still present. I also tried non compresses 12/10bit but still the double frame issue. Tried regular 14bit and files comes out very short but without doubled frame but still too short to be reliable for this test.
Here is an example file with a doubled frame:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/3xzoom_100D_Frame_57-59.MLV

The issue can happen anywhere but often after a couple of seconds. Tried changing timers in FPS but didn´t work. Seemed to worsen things at one point but can´t really be sure of that. One theory I have is that maybe the issue appears due to 3xzoom code now is centred? Just guessing here. Can´t really see what´s up here.

[Lars Steenhoff]

I have seen that If I use mlv_lite with h264 the resulting DNG files have a 1 pixel line on the left side.   1080p 25fps Pal ( canon 5d3 1.2.3 )
Is this a known issue?

[vstrglv]

There is no 1 pixel line on any side,  mlv_lite with h264, Canon 5D3 1.1.3. Tested 14-bit lossless and 12-bit lossless, 1920x1080, 24fps

[Lars Steenhoff]

https://www.dropbox.com/s/ineacrodd1x0lb7/M10-1506_000000.dng?dl=0

you can see it in this DNG file, black Line of pixels on the left side

[vstrglv]

This is two pixels line.

[Lars Steenhoff]

 . true, by the way 14 bit lossles was used. did you not get the same?

[Sganzerla]

I have black lines at left with my 5D MKIII 1.2.3 images too.
Is this related to mlv_dump settings?

[vstrglv]

. true, by the way 14 bit lossles was used. did you not get the same?

There are no black pixel lines,  mlv_lite with h264, Canon 5D3 1.1.3. Tested 14-bit lossless too.

[a1ex]

Not sure what this has to do with H.264 or bit depth, but it's a valid bug - fix pushed. There were two black pixels on the left edge, not just one.

mlv_rec and/or the unified branch may also need this fix (not checked).

Bugs like this are subtle enough to go unnoticed and/or unreported for a long time; as I'm not a regular video user, and not very good at pixel peeping, I wasn't aware of it. After searching for similar stuff, noticed this report from 2013...

[Lars Steenhoff]

Thanks for the fix!

Im sure it has nothing to do with h264, I was just trying to report as accurate as possible my settings when I noticed the pixels.

I just double checked and mlv_rec does NOT have this issue.

[MichaelVito]

Hi all- Long-time forum reader, first time commenter.

Wanted to chime in that I also get the two dark pixel column bug. It's been present for me since I started experimenting with crop_rec on steroids back in 2017 June. I was about to summarize my observations and post when I saw it come up again in the thread. Thus far, I've only tested on 5D3 1.2.3.

I went through the thread and found a few other mentions, with some variations:
http://www.magiclantern.fm/forum/index.php?topic=19300.msg184143#msg184143
http://www.magiclantern.fm/forum/index.php?topic=19300.msg184217#msg184217
http://www.magiclantern.fm/forum/index.php?topic=19300.msg185903#msg185903
http://www.magiclantern.fm/forum/index.php?topic=19300.msg186013#msg186013

In my case, I've isolated it to a combination of using one of the lossless recording modes and having a horizontal resolution of exactly 1920 in some, but not all shooting modes. Shooting 14-bit lossless with 1920 pixels wide in 3x3 binned, regular old 1to1 cropped, and 50/60p gets me the two dark (but not black) pixel columns at the left edge. There is also a one pixel column of lighter pixels immediately adjacent. They change a little moving to 12 and 8-11 lossless; an additional slightly darkened area a few pixels wide also appears to the right of the dark bars. If I make the horizontal resolution slightly smaller, or in a crop mode slightly larger, the bug goes away. It does not appear to come up in 3.5K centered shooting mode. Changing vertical resolution or using speed hacks like Global Draw off do not have any effect.

Hope this helps. Let me know if I can provide more information.

[mr.smith]

someone please...

 4096×2160 24p 10bit raw, Continuous please!!!!

always great thanks to ML team.

[dfort]

4096×2160 24p 10bit raw, Continuous please!!!!

I want more -- 5184x3456 14bit raw on the EOSM. Come on guys, you can do it! Oh yeah, FRSP already does. Now I want 120p continuous!!!!

Ok--back to reality. I'd like to resurrect the discussion on the OB zones issue with the EOSM, 100D, 700D and probably 650D. This happens when using crop_rec 3x3_1X at maximum possible image size.

EOSM example (black bar on top of frame)

[dfort]

I'm at work without my development computer or cameras right now but this looks like something interesting:

Code: [Select]

/* max resolution for each video mode (trial and error) */
/* it's usually possible to push the numbers a few pixels further,
 * at the risk of corrupted frames */
static int max_resolutions[NUM_CROP_PRESETS][5] = {
                                /*   24p   25p   30p   50p   60p */
    [CROP_PRESET_3X_TALL]       = { 1920, 1728, 1536,  960,  800 },
    [CROP_PRESET_3x3_1X]        = { 1290, 1290, 1290,  960,  800 },
    [CROP_PRESET_3x3_1X_48p]    = { 1290, 1290, 1290, 1080, 1040 }, /* 1080p45/48 */
    [CROP_PRESET_3K]            = { 1920, 1728, 1504,  760,  680 },
    [CROP_PRESET_UHD]           = { 1536, 1472, 1120,  640,  540 },
    [CROP_PRESET_4K_HFPS]       = { 3072, 3072, 2500, 1440, 1200 },
    [CROP_PRESET_FULLRES_LV]    = { 3870, 3870, 3870, 3870, 3870 },
};

Secifically, the CROP_PRESET_3x3_1X on the EOSM, 100D, 700D, 650D is not 800 vertically in mv720 mode. The full raw buffer isn't even that big. As far as I can tell there's no other place in the code that sets max_resolutions.

On the EOSM there are 28 black pixels at the top of the frame and the image is 724 pixels high. I couldn't find an EOSM mv720 full raw buffer in my flickr library but I have one for the 100D that Danne shared with me.



It is 727 pixels high and the out of bounds area takes up 28 pixels off the top (sound familiar?) so the maximum possible vertical resolution would be 699 pixels, maybe slightly less, so that 800 pixel max resolution may be fine for the 5D3 but it doesn't apply to these other cameras.

[Danne]

To change height and width for the 100D this is the place in crop_rec.c:

Code: [Select]

/* optical black area sizes */
/* not sure how to adjust them from registers, so... hardcode them here */
static inline void FAST calc_skip_offsets(int * p_skip_left, int * p_skip_right, int * p_skip_top, int * p_skip_bottom)
{
    /* start from LiveView values */
    int skip_left       = 146;
    int skip_right      = 2;
    int skip_top        = 28;
    int skip_bottom     = 0;

    switch (crop_preset)
    {
        case CROP_PRESET_FULLRES_LV:
            /* photo mode values */
            skip_left       = 138;
            skip_right      = 2;
            skip_top        = 60;   /* fixme: this is different, why? */
            break;

        case CROP_PRESET_3K:
        case CROP_PRESET_UHD:
        case CROP_PRESET_4K_HFPS:
            skip_right      = 0;    /* required for 3840 - tight fit */
            /* fall-through */
       
        case CROP_PRESET_3X_TALL:
            skip_top        = 30;
            break;

        case CROP_PRESET_3X:
        case CROP_PRESET_1x3:
            skip_top        = 60;
            break;

        case CROP_PRESET_3x3_1X:
        case CROP_PRESET_3x3_1X_48p:
            if (is_720p()) skip_top = 0;
            break;
    }

    if (p_skip_left)   *p_skip_left    = skip_left;
    if (p_skip_right)  *p_skip_right   = skip_right;
    if (p_skip_top)    *p_skip_top     = skip_top;
    if (p_skip_bottom) *p_skip_bottom  = skip_bottom;
}
This:

Code: [Select]

    /* start from LiveView values */
    int skip_left       = 146;to:

Code: [Select]

    /* start from LiveView values */
    int skip_left       = 66;
and this:

Code: [Select]

            if (is_720p()) skip_top = 0;to:

Code: [Select]

            if (is_720p()) skip_top = 28;
Will result in 1728x698 crop_rec recordings.

[dfort]

Strange.

Code: [Select]

        case CROP_PRESET_3x3_1X:
        case CROP_PRESET_3x3_1X_48p:
            if (is_720p()) skip_top = 0;

EOSM/100D/700D/650D are using only 3x3_1X so changing that line to if (is_720p()) skip_top = 28; should have no effect.

So did that get rid of the black bar?

[Danne]

Yes.
Well if it's x724 and you put in -28 when otherwise 0 when set to mv720 something should happen...
Could you try your 700D?

The line should apply for both?
CROP_PRESET_3x3_1X
And
CROP_PRESET_3x3_1X_48p
?

[dfort]

Tried your suggestion on the 700D and also a simpler suggestion a1ex made on the 650D pull request and got the same results. Basically, don't run this:

Code: [Select]

        /* update skip offsets */
        int skip_left, skip_right, skip_top, skip_bottom;
        calc_skip_offsets(&skip_left, &skip_right, &skip_top, &skip_bottom);
        raw_set_geometry(raw_info.width, raw_info.height, skip_left, skip_right, skip_top, skip_bottom);

I put the EOSM/100D/650D/700D into a group called "is_basic" because they only do the basic 3x3_1X thing. This will make it easy to test for this group and skip that section.

So here is the before:

700D crop_rec 1648x724


And after -- not running that section of code:

700D crop_rec 1736x688


Something interesting happened to the LiveView with this change. Before Auto Preview defaulted to Framing but not calling calc_skip_offsets/raw_set_geometry changed Auto Preview to Real-time which for crop_rec is stretched vertically. Either way works fine.

By the way, I've been using Danne's Switch app to process the MLVs and at one point I tried mlv_dump on the command line and Adobe Camera Raw stretched out the image--guess it was adjusting it as if it were a regular mv720 clip. However, this is also how it looks like on the LiveView.

[a1ex]

By the way, I've been using Danne's Switch app to process the MLVs and at one point I tried mlv_dump on the command line and Adobe Camera Raw stretched out the image--guess it was adjusting it as if it were a regular mv720 clip. However, this is also how it looks like on the LiveView.

Pretty sure it does that. Suggestion: if the MLV has RAWC metadata, this can tell whether the image requires any stretching (and if so, how much). The aspect ratio would be (binning_x + skipping_x) / (binning_y + skipping_y).

[Danne]

Yes, should follow metadata. It's not atm. Mlv_dump version in Switch adds default scale tag corrections first automatically then corrects it if told it's processing crop_rec.
Regular(unified) mlv_dump doesn't touch the default scale tag.

[dfort]

Another ML mystery solved. Here is the RAWC block from the shot that I posted.

Code: [Select]

Block: RAWC
  Offset: 0x000000e8
  Number: 2
    Size: 32
    Time: 0.815000 ms
    raw_capture_info:
      sensor res      5184x3456
      sensor crop     1.62 (APS-C)
      sampling        3x3 (read 1 line, skip 2, bin 3 columns)