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

[dfort]

I really want to resolve that black bar at the top issue and even though skipping over calc_skip_offsets/raw_set_geometry does seem to do it, there is an issue with the way ACR is displaying the processed DNG files depending on the app used to process the MLV files.

Let's call the code as it currently stands as "Before" and skipping over calc_skip_offsets/raw_set_geometry as "After":

Before

Code Select Expand

Mode of operation:
   - Input MLV file: 'Before.MLV'
...
Block: RAWI
...
    Res:  1648x724
    raw_info:
      api_version      0x00000001
      height           726
      width            1808
      pitch            3164
      frame_size       0x00230CE8
      bits_per_pixel   14
      black_level      2047
      white_level      16200
...
Block: RAWC
  Offset: 0x000000e8
  Number: 2
    Size: 32
    Time: 0.786000 ms
    raw_capture_info:
      sensor res      5184x3456
      sensor crop     1.62 (APS-C)
      sampling        3x3 (read 1 line, skip 2, bin 3 columns)


After

Code Select Expand

Mode of operation:
   - Input MLV file: 'After.MLV'
...
Block: RAWI
...
    Res:  1736x688
    raw_info:
      api_version      0x00000001
      height           726
      width            1808
      pitch            3164
      frame_size       0x00230CE8
      bits_per_pixel   14
      black_level      2047
      white_level      16200
...
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)


Processed in MLVFS and opening the DNG files in Adobe Camera Raw:

Before


After


The mlv_dump version that is in the crop_rec_4k shows both the Before and After processed DNG files without vertical stretching but maybe that's wrong? My understanding is the mlv_dump code that is in the main repository doesn't read the RAWC metadata. However, Danne's Switch app has two modified versions of mlv_dump (the other is mlv_dump_on_steroids) and they both produce DNG files that display in ACR exactly the same as MLVFS -- when these mlv_dump builds are run from the command line. Switch adjusts the DNGs so crop_rec footage is not stretched provided you choose option 01 from the startup menu:



So I'm confused now. I'd like to resolve the black bar issue in the crop_rec module and skipping over calc_skip_offsets/raw_set_geometry does seem to do it but it is also causing issues with some of the MLV processing apps. I can't see anything in the metadata that would cause this so I'm a bit hesitant to commit that change.

[Danne]

Been discussed several times before. Crop_rec gets treated as mv720 files. Detected the same since rawc isn't integrated. Default scale tag is set into the dng file.
Therefore the manual extra labour in Switch...

[dfort]

Ok, I get it that the default scale tag is different in the dng file but something in the MLV file must have changed when skipping over calc_skip_offsets/raw_set_geometry in crop_rec.c.

No issues when using Switch--you figured this out long ago Danne but it seems that you're doing some black magic on the DNG files after processing through mlv_dump to cover up the underlying issue.

These were processed in MLVFS - both the Before.MLV and After.MLV were placed in the same directory so they were processed with the same settings:

Before

Code Select Expand

ExifTool Version Number         : 10.13
File Name                       : Before_000000.dng
...
Camera Model Name               : Canon EOS REBEL T5i
...
Black Level                     : 2047
White Level                     : 16200
Default Scale                   : 1 1
Default Crop Origin             : 0 0
Default Crop Size               : 1648 724


After

Code Select Expand

ExifTool Version Number         : 10.13
File Name                       : After_000000.dng
...
Camera Model Name               : Canon EOS REBEL T5i
...
Black Level                     : 2047
White Level                     : 16200
Default Scale                   : 1 1.666666667
Default Crop Origin             : 0 0
Default Crop Size               : 1736 688


I want to get rid of the black bar at the top of the processed DNG files but I don't want them stretched in ACR. I also want to resolve this issue in crop_rec.c without using any black magic in post production.

[Danne]

It's all in dng.c. Detection derived from aspect ratio. Gets fooled with crop_rec since you corrected it. Just implement rawc metadata and it can be done straight in code instead like I do, using exiv2.

[dfort]

It seems to me that the MLV processing apps should be able to produce DNGs that scale properly in ACR without having to ask the user if this is crop_rec or mv720 and without having to fix the DNG files with exiv2. MLVFS seemed to be doing a good job before the change I tried in crop_rec.c.

For the record here is some information extracted with mlv_dump -v on three different MLV files from the same camera.

mv720 - plain vanilla, MLVFS adjusts the DNG Default Scale so it displays in ACR properly.

Code Select Expand

Block: RAWI
    Res:  1736x688
    raw_info:
      height           726
      width            1808
Block: RAWC
      sampling        5x3 (read 1 line, skip 4, bin 3 columns)

Before - this is crop_rec in its current state which produces a black bar on the top of EOSM/100D/650D/700D crop_rec files but MLVFS does handle Default Scale properly in the DNG files.

Code Select Expand

Block: RAWI
    Res:  1648x724
    raw_info:
      height           726
      width            1808
Block: RAWC
      sampling        3x3 (read 1 line, skip 2, bin 3 columns)

After - Skipping over calc_skip_offsets/raw_set_geometry in crop_rec.c, no black bar but MLVFS doesn't handle this properly and is stretched vertically in ACR.

Code Select Expand

Block: RAWI
    Res:  1736x688
    raw_info:
      height           726
      width            1808
Block: RAWC
      sampling        3x3 (read 1 line, skip 2, bin 3 columns)


I'm coming to the conclusion that the problem is in the MLV processing apps. The developers should be looking at the RAWC sampling information. That includes you @g3gg0 - it looks like mlv_dump does nothing with the DNG Default Scale metadata. Though other developers seemed to have added feature in mlv_dump to adjust Default Scale but apparently they are not using the information in RAWC sampling.

So--I'll go ahead and make that change in crop_rec.c on the pull request and let the MLV processing app developers figure this out.

[Danne]

Nothing wrong with crop_rec.c. Check this in dng.c(dmilligan):

Code Select Expand

   int32_t par[4] = {1,1,1,1};
    double rawW = dng_info->raw_info->active_area.x2 - dng_info->raw_info->active_area.x1;
    double rawH = dng_info->raw_info->active_area.y2 - dng_info->raw_info->active_area.y1;
    double aspect_ratio = rawW / rawH;
    //check the aspect ratio of the original raw buffer, if it's > 2 and we're not in crop mode, then this is probably squeezed footage
        //TODO: can we be more precise about detecting this?
        if(aspect_ratio > 2.0 && rawH <= 720)
        {
            // 5x3 line skpping
            par[2] = 5; par[3] = 3;
            focal_resolution_x[1] = focal_resolution_x[1] * 3;
            focal_resolution_y[1] = focal_resolution_y[1] * 5;
        }
        //if the width is larger than 2000, we're probably not in crop mode
        //TODO: this may not be the safest assumption, esp. if adtg control of sensor resolution/crop is implemented, currently it is true for all ML cameras
        else if(rawW < 2000)
        {
            focal_resolution_x[1] = focal_resolution_x[1] * 3;
            focal_resolution_y[1] = focal_resolution_y[1] * 3;
        }

[dfort]

Thought I broke the 5D3 with these changes but it turned out that it wasn't me!

Steps to reproduce, if you dare. Just make sure you're close to your computer and card reader.

• Download latest 5D3.113 experimental (didn't test this on 123)
• Turn on only the crop_rec and mlv_lite modules
• Set crop_rec to 1920 50/60 3x3 which I take it is the 3x3_1X mode, right?
• Turn off camera.
• Turn on camera
• Panic because the LV screen is blank!
• Recite Walter's mantra -- remove card, remove battery, reinsert battery, start camera without card.
• Delete the ML/SETTINGS off the card and you're back in business.

[a1ex]

This particular sequence works fine here. However...

sometimes the screen remains black when switching modes around (not sure how to reproduce); in this case, you don't need to go to photo mode; just press MENU twice (see first post).

On 5D3, the 50/60 3x3 preset is indeed 1x, but also with higher vertical resolution (unlike the smaller cameras).

[dfort]

Yep, hitting menu twice resurrects LiveView. Haven't used crop_rec on the 5D3 much but glad to know I didn't break it!

[Danne]

I see a lot of "is_basic"(dfort) workarounds in crop_rec.c to make crop_rec working for 100D/700D/eosm/650D. i tried like this and works. Seems easier to just categorize the cameras. Thoughts?
https://bitbucket.org/Dannephoto/magic-lantern/commits/a01a8f4420cfe37a7b52ca071ae3525906c02296

[a1ex]

The correct skip offsets are already in raw.c - your approach requires duplicating them, does not reduce the number of branches and... you have a typo in one of the offsets

The current solution does not override the offsets for these models (these offsets happen to be the same as without crop_rec). Compare these two screenshots side by side.

[Danne]

Yes, probably. I updated dforts pull request with two screenshots of raw_diag images and a question.

[Rcorrell1]

Can someone please help me with removing the april 4th null pointer bug???  I'm not getting any help from anyone, just being made fun of and being told to contact people I already have several times. I've gone on IRC several times, made posts in this forum, and DM'ed with no responses. Please, if anyone can point me in the right direction to remove this bug in any way that would be great!

Thank you!!

[Walter Schulz]

If you don't want to use an outdated and buggy build you may want to consider using a newer one.

Ceterum censeo experimental build page esse delendam.

[kichetof]

FRSP in photo mode with Full-res LV mode and Lossless DNG is now really fast! Preview for 2s, just a little stripped pink flash (before it was a long flash). I don't know if it's this commit (842e25f) but really appreciate!! (last build 17oct16 used)

[axelcine]

"Ceterum censeo experimental build page esse delendam." Walther you had me howling from laughter. When I get my breath back, I'm going toagree with you. I install every new official build, and it certainly pays off - and when I try out an experimental, I reinstall the official build immediately after testing. I find it exciting like Christmas every time I install a new build - and many times I have been totally awed by the improvements.

[a1ex]

FRSP in photo mode with Full-res LV mode and Lossless DNG is now really fast! Preview for 2s, just a little stripped pink flash (before it was a long flash). I don't know if it's this commit (842e25f) but really appreciate!! (last build 17oct16 used)

I've tested the first build with this feature (Aug 20), but didn't notice any speed difference...

Found a bug: to use crop_rec in photo mode (any preset), movie mode *must* be set to 1080p30. Nobody else noticed?!

[kichetof]

I've tested the first build with this feature (Aug 20), but didn't notice any speed difference...

Some tests and you're right! I'll try to test some builds from September, I noticed a difference, that's why I've been so enthusiastic

[OlRivrRat]

   Issue? Whenever I attempt "MLV_Lite" on My SL1 I get a "Busy...Please Wait" Flag

across the top of the View Screen. Recording can be started & does seem to occur.

I have tried numerous diff' settings but It's always there.

   Have tried in Latest Nightly & "crop_rec_4k.17~10~10.100D101"

           Also > Unable to take Screen Shots while "MLV_Lite" is active.

                     ORR ~ DeanB

[a1ex]

Workaround: disable SRM memory. However, that means less memory available for raw recording. For 5D3 I've found a way to avoid the BUSY screen, but other cameras may show different behavior.

The screenshot doesn't work because mlv_lite preallocates all the shooting memory during standby (because this is a slow operation that would delay recording). That's not an issue with 5D3, since it has enough memory in the general-purpose pools (such as AllocateMemory), but smaller cameras are not that lucky.

Can you do a quick test?
- enable the console from the Debug menu
- enable raw video (mlv_lite)
- take a picture of the screen with a second camera

[Danne]

From console:


Is the srm memory fix for 5D mark III active for other cameras too or only 5D mark III? Trying to follow exmem.c from september 3rd  to see if anything could be unchecked to test busy screen fix also for the 100D.


*update(mv1080)

[a1ex]

It's active on all models, but probably the 100D handles the BUSY screen differently.

You could try to allocate manually 1, 2, 3 SRM buffers (and so on), e.g. with srm_malloc_suite, and document what happens with the BUSY screen. If that one comes up as soon as one SRM buffer is allocated... I'm not sure what we can do. If it comes up after allocating all SRM buffers, but does not disappear when freeing one of them (in 5D3 it disappears), we can probably find a different workaround (such as reallocating everything from scratch after finding out how many SRM buffers are available).

[Danne]

Ok, now I can´t even reproduce the "busy" screen at the top or at the bottom. Tested latest crop_rec_4k. I had it several times in the past but now stressing shooting crop_rec, mv1080 etc both mlv_lite and mlv_rec for about ten files each and all worked fine. Could alter iso, shutter etc while recording, nothing stuck. So probably the fix is active and working but I know i had the issue described with busy screen at the top several times before. I will try my best to reproduce.

Question. How to allocate manually? snippet in exmem.c:

Code Select Expand

    printf("[SRM] free all buffers\n");

    /* free all SRM buffers */
    /* note: first buffer is use-after-free */
    for (int i = 0; i < COUNT(srm_buffers); i++)
    {
        if (srm_buffers[i].buffer)
        {
            ASSERT(!srm_buffers[i].used);

            if (!srm_buffers[i].use_after_free)
            {
                SRM_FreeMemoryResourceFor1stJob(srm_buffers[i].buffer, 0, 0);
            }

            srm_buffers[i].buffer = 0;
            srm_buffers[i].use_after_free = 0;
        }
    }

    srm_shutter_unlock();

    srm_allocated = 0;
}

REQUIRES(mem_sem)
struct memSuite * _srm_malloc_suite(int num_requested_buffers)
{
    printf("srm_malloc_suite(%d)...\n", num_requested_buffers);

    /* alloc from operating system, if needed */
    srm_alloc_internal();

    if (num_requested_buffers == 0)
    {
        /* if you request 0, this means allocate as much as you can */
        num_requested_buffers = COUNT(srm_buffers);
    }

adding number here?

Code Select Expand

if (num_requested_buffers == 0)
or here?:

Code Select Expand

srm_allocated = 0;

[a1ex]

Don't edit the library, just call its functions.

with srm_malloc_suite

e.g. srm_malloc_suite(1) in don't click me, then 2, then 3...

[jacekp]

I have tried 16oct crop_rec build on 100D. No problem with RAW recording (12bit lossless most the time) at ISO100.
At ISO>100 most time "Raw detect error" (usually first ISO>100 clip correct and then further tries with this error) - was the same situation with previous builds.