Canon 6D

[dfort]

Well we know this is possible because:

I couldn't get the resolution larger than 634 pixel vertical, not sure how to steer that.

Results for now are 1808 x 632 resolution in 3x3 mode and 50fps 

You can't get more than 632 vertical resolution because this is the 720p raw buffer which is designed to skip 4 lines at a 16x9 aspect ratio. Maximum theoretical vertical resolution skipping 2 lines (3x3) is the sensor max resolution,  3,648, divided by 5 or about 729 but the actual maximum is significantly less.

In any case, looks like we are almost there.

[Levas]

Makes sense, probably the vertical resolution, divided by 5, also needs to be corrected from 3:2 to 16:9 ratio, then you get about 614 pixels
But the 5d3 does 1920 x 960 in 50fps mode ? https://www.magiclantern.fm/forum/index.php?topic=19300.msg182052#msg182052
Or is this 1920 x 960 x 50fps not in 720p mode but in 1080p mode ?
Or has the 5d3 a larger 720p raw buffer ?

[Levas]

Finally I solved the mystery how to 'repair' the 12 to 8 bit lossless MLV's from the 6d.

MLV files with lower bit depth than 14 have wrong white level.
Got a 10 bit lossless file which shows white level of 2932 in the metadata and a 8 bit lossless file which shows a white level of 2269 

Used exiftool to set the white level to 16200 in the resulting extracted 14 bit files, and now everything is fine 

Whoohoo 14 - 8 bit lossless with audio on the 6d 

When using lossless compression I extract the MLV files with MLV_dump on steroids and fix the DNG's with the following command

Code: [Select]

exiftool -IFD0:BlackLevelRepeatDim="2 2" -IFD0:BlackLevel="1920 1792 1536 1024" -IFD0:WhiteLevel="16200" -overwrite_original *.dng


[a1ex]

Used exiftool to set the white level to 16200 in the resulting extracted 14 bit files, and now everything is fine 

... is the reduced bit depth lossless recording actually working on 6D? (as in, do you actually get lower file sizes?)

This works by darkening the input image before compression, while still using a 14-bit container; if you had to raise the white level to 16200, that suggests the bit depth reduction probably did not work.

The uncompressed 10/12-bit recording is a lot different: there, the bit depth reduction happens before the raw image arrives into main memory. For lossless, the bit depth reduction is only at logical level (the container is still 14-bit, just the entropy of the data prior to compression is brought to 8/10/12/whatever-bit levels).

edit: please read the post and the links before replying.

[Levas]

Reduced bit depth lossless works on 6d.
MLV_dump on steroids makes/exports only 14 bit DNG's...
So after exporting the DNG's, it always is in a 14 bit DNG file.

Got about 550 frames with 8 bit lossless in 2400x960x25fps resolution.
with 40Mb/s writing speed and about 250Mb buffer memory , only possible if 8 bit lossless is really 8 bit lossless.

Testing it again, 8 bit lossless, 2400 x 960 x 25 fps at iso 6400, with not much movement/panning I get 693 frames
 
2400 x 960 x 25 fps at iso 6400 in 14 bit lossless, same scene, not much movement/panning gives 200 frames
 

[a1ex]

Alright, so with your second test, the compression ratio (compressed/uncompressed)  was about 50% at 8-bit lossless, and about 72% for 14-bit, which sounds about right.

Then, what was the reason for raising the white level to 16200? May I see the two DNGs? (8-bit vs 14-bit from the above experiment)

BTW, lossless compression is done for each individual frame, so motion doesn't have much effect (other than motion blur, which might reduce the entropy a bit).

[Levas]

I've uploaded two original MLV files, 14 bit lossless and 8 bit lossless.
https://drive.google.com/open?id=1vgOvuL7QuCDtFFgG-peoo7gjLTJeaURr

When I use MLV_dump on steroids, to extract DNG files out of these MLV's, I get 14 bit DNG files out of the 8 bit file, with white level value of 2269 
I've also uploaded two DNG's straight out of MLV_dump on steroids, and two fixed with exiftool.

EDIT: The scene is shot under LED bulbs with 2300Kelvin temperature, so not exactly natural light 

[a1ex]

Alright, you must have developed the DNG with dcraw or some other tool that brightens the image (possibly at default settings), but I still don't know what was the reason for changing white level to 16200; how did the DNG look without that change?

Code: [Select]

exiftool -IFD0:BlackLevelRepeatDim="2 2" -IFD0:BlackLevel="1920 1792 1536 1024" -overwrite_original 8Lossless_frame_000000-UNFIXED.dng

The above gives correct image with dcraw -W

Code: [Select]

-W        Don't automatically brighten the image


[dfort]

Lossless is getting there, let's see if we can also get crop_rec working. Did yet another QEMU session, this time I figured out how to get it to start up in movie mode and the Canon settings in 720p printing out both addresses on the screen.

Code: [Select]

        bmp_printf(FONT_LARGE, 50, 350, "MEM_CMOS_WRITE 0x%x", MEM(CMOS_WRITE));
        bmp_printf(FONT_LARGE, 50, 400, "MEM_ADTG_WRITE 0x%x", MEM(ADTG_WRITE));



Strange but the 5D3 also has the same address for MEM_CMOS_WRITE and MEM_ADTG_WRITE, only slightly different.

Let's give it another try. This time I also uploaded a version named print_CMOS_WRITE_ADTG_WRITE... guess what that does? Just in case the new crop_rec_4k build still doesn't work you can check the addresses on the camera. Just activate the crop_rec module and it should print just like in QEMU. Make sure you're in movie mode, 720p. It seems to make a difference.

As usual--test builds are on my downloads page.

[dfort]

Thought this could use some further discussion:

Makes sense, probably the vertical resolution, divided by 5, also needs to be corrected from 3:2 to 16:9 ratio, then you get about 614 pixels
But the 5d3 does 1920 x 960 in 50fps mode ? https://www.magiclantern.fm/forum/index.php?topic=19300.msg182052#msg182052
Or is this 1920 x 960 x 50fps not in 720p mode but in 1080p mode ?
Or has the 5d3 a larger 720p raw buffer ?

If you look at crop_rec.c you'll see that the code for the 5D3 is further developed than just taking the mv720 buffer and changing the line skipping. I can't find the post but I'm sure that a1ex explained that CROP_PRESET_3x3_1X uses a custom buffer on the 5D3 which has more vertical resolution. Note also that the FPS is somehow related to the image size. At some point we can get the addresses for ENGIO_WRITE and MEM_ENGIO_WRITE and create custom buffers but let's get the basic 3x3 binning in 720p working first.

[Levas]

@Alex, I'm confused, if you fix the black level of the non fixed frame, you see normal results ?
When I look at the text file with meta data from the 8 bit lossless MLV it shows a white level of 2269.
Where the 14 bit lossless meta data text file shows a white level of 16200.

My workflow with the MLV files is, using mlv_dump on steroids to extract the dng's.

Code: [Select]

mlv_dump_on_steroids.osx --no-fixcp --no-stripes --dng
As already known, I'm a big fan of RawTherapee, when I load the non fixed image in RawTherapee and fix the offset of the black levels, I get this:
Exposure settings and stuff is set to zero:


Now when I fix black level and set white level to 16200 with exiftool, I get this in RawTherapee:
Exposure settings, needed to push 6 stops exposure to get this result (and ofcourse compensate black levels for the green channels which are swapped).

[a1ex]

As already known, I'm a big fan of RawTherapee, when I load the non fixed image in RawTherapee and fix the offset of the black levels, I get this:
...

I already know; that's why the first thing I've tried with your DNGs was opening them in RawTherapee. However, I've got a totally bogus image with your FIXED.dng; moreover, your exiftool command contains the black levels in the dcraw/darktable/Adobe order, not in the RawTherapee one. Given the above, I had all the reasons to believe you have used a different program (not RawTherapee) for this particular experiment. Edit: also checked with RT 5.3 stable, no significant changes.

After running my command (white level unchanged, still at 2269) modified to match RawTherapee order, I get normal image in RawTherapee:

Code: [Select]

exiftool -IFD0:BlackLevelRepeatDim="2 2" -IFD0:BlackLevel="1920 1536 1792 1024" -overwrite_original 8Lossless_frame_000000-UNFIXED.dng

MD5 checksums (so you can make sure I've used the right files):

Code: [Select]

8d285dbe3ef4d7a94d04d86994e7520a  8Lossless_frame_000000-FIXED.dng        ; as downloaded
4efb9d69ba83812b09e5447b97a4119b  8Lossless_frame_000000-UNFIXED.dng      ; after exiftool with "1920 1536 1792 1024"
6a7ae89709386b42781beb2d8a2b220a  8Lossless_frame_000000-UNFIXED-orig.dng ; copied after downloading


[Levas]

@Dfort, I don't have much time today to test, so will look further in it tomorrow.

But what I quickly see is that your 'normal' latest crop_rec build does more then the previous builds.
It looks like it has the pixelbinning part right, but the CMOS[7] is not adjusted.
I see a preview similar as if I change only the ADTG800C register to value 2.
The frame is a little messed up on the top half, which can be fixed with CMOS[7] in adtg_gui.

Also checked the 'print' build, it shows addresses at startup, but if live view is on, it's gone...
I get the same addresses in 720p, photo mode ( 0xe92d41f0 ) as you did in QEMU.

[Levas]

@Alex, sorry for the weird workflow 

I can explain.
I keep my files and want them to be future proof, my guess is that DNG's are more future proof then MLV files (not sure of course  )
As I keep DNG's, I fix the black levels, but as we know, Raw Therapee has the green levels in the wrong order, so for future proofing, I choose to fix the black levels according to the DNG format.
When editing in RawTherapee I compensate the green levels (Unlink green channels, compensate -256 for the first green channel and +256 for the second green channel)

Weird, but all logical to me.

Also tried to do what you did, took the unfixed 8 bit lossless dng, fixed the black levels with exiftool (fixed for Rawtherapee use)
And loaded the file in Rawtherapee 5.3.
Looks good at first sight, but when I zoom to 1:1 100%, I see a pattern all over the image.
How does the file, without white level fix, look at 100% on your screen ?

[a1ex]

Yes, it has a fine maze pattern.

Same pattern if I use "1920 1792 1536 1024" and -/+ 256. The pattern disappears with white level set to 16200 and brightening with Auto Levels. Mystery solved.

This points to a possible roundoff error in RawTherapee processing, and I believe the issue should be reported to them (as I'd expect identical results in these two cases).

The same pattern appears in darktable, but is not present with dng_validate 1.4, and neither with dcraw (so the DNG is correct, but RawTherapee and darktable do not interpret it properly). This should be mentioned in the bug reports, should you decide to do them. I can help with checking the reports, BTW.

(interesting that I'm still unable to see the maze pattern in this sample with RT/DT, but maybe it's just my lack of pixel peeping skills)

The above does not mean setting white level to 16200 is the right thing to do (in particular, it will break highlight recovery on overexposed images). It's just a workaround that happens to work for you, nothing more. Reporting the issue to RT and DT is the preferred option, IMO.

[MR MIAN]

I'm come from China and say sorry for my poor English

I have tried dump the 14bit-lossless RAW video with mlv_dump and repair DNGs with exiftool.For every single dng i got a nice image with wrong white balance(alaways on 3200K).


that is ok,good job.However,when I put them into Premiere and DaVinci,the color is borken.it looks like dng without exiftool but have a little higher blacklevel.


I can always get right image with the help of software with ACR like PS,LR and AE,but,you know,it's a trouble.
By the way.I have write a windows form app for dump DNGs.Of course,have the problem I said above.
https://pan.baidu.com/s/1smB7YLf
(I'm not sure if you can open the netdisk link without a VPN  )

[a1ex]

Unfortunately, not all DNG converters interpret per-channel black levels; for best compatibility, it would be to alter the raw data itself (rather than declaring the offsets in the DNG metadata).

Are you able to run the octave script from the linked post, and/or implement the same correction in mlv_dump? (if you were able to write a GUI wrapper for mlv_dump, the answer would be most likely "yes").

[dfort]

But what I quickly see is that your 'normal' latest crop_rec build does more then the previous builds.
It looks like it has the pixelbinning part right, but the CMOS[7] is not adjusted.
I see a preview similar as if I change only the ADTG800C register to value 2.
The frame is a little messed up on the top half, which can be fixed with CMOS[7] in adtg_gui.

Hum, the tool tip for CMOS[7] is, "Looks like the cmos is dieing (g3gg0)." Wonder what that means?

Looking at your lossless MLV's I see that your camera is probably setup for PAL. Maybe that has something to do with it? I also noticed that the CROP_PRESET_3x3_1X might be using ENGIO_WRITE and MEM_ENGIO_WRITE which are not defined other than on the 5D3. Using the same technique that seemed to have worked with MEM_CMOS_WRITE and MEM_ADTG_WRITE I looked up MEM_ENGIO_WRITE and it came up the same as the 5D3. I also found ENGIO_WRITE in the disassembly so this should work:

Code: [Select]

    else if (is_camera("6D", "1.1.6"))
    {
        CMOS_WRITE = 0x2420C;
        MEM_CMOS_WRITE = 0xE92D41F0;       
       
        ADTG_WRITE = 0x24108;
        MEM_ADTG_WRITE = 0xE92D41F0;
       
        ENGIO_WRITE = 0xFF2AE134;
        MEM_ENGIO_WRITE = 0xE51FC15C;

Uploaded a new test build.

• Does the frame look different in NTSC?
• Exactly are you doing with CMOS[7] to fix the frame?
• Have you tried recording anything yet or are you just looking at the LV preview?

[Levas]

does not mean setting white level to 16200 is the right thing to do (in particular, it will break highlight recovery on overexposed images). It's just a workaround that happens to work for you, nothing more. Reporting the issue to RT and DT is the preferred option, IMO.

Thanks for clearing that up, there goes my future proof workflow 

So for reasonable future proofing, it's best to fix black levels and leave white level unaltered.
And as I see in a later post, for best compatibility/future proofing it's best to alter the raw data.

EDIT: Opened the same files(only black level fix, white level unaltered) in Lightroom 5, Lightroom shows them just fine, exposure is good and there's no fine maze pattern.
Preview in MacOS shows the files without the correct exposure, really dark preview, so Preview in MacOS, doesn't read/use the white level.

[Levas]

@Dfort, You're right, my camera is set to PAL.
Always tried recording, but also enable the 'framing' option in MLV_Lite and the 'framing' shows exactly the same thing as recording.

Just tried your latest build and it still looks the same as when I alter the lineskipping value to '2' in adtg_gui.
When I change CMOS[7] in adtg_gui I can get a normal live view image and recording.
In adtg_gui I set CMOS[7] to value '2a5'.

I remember seeing a overview with CMOS and adtg settings and what they do in different camera's, can't find them anymore, do you know what I mean ?

Here is how PAL looks(When I move the camera a little, the upper half of the image becomes green tinted.
As you can see, my dock appears at the upper half of the picture, while it should be in the bottom of the screen.


NTSC looks the same, But alters, 1 frames just as PAL and then 2 frames with purple tinted upper half, repeats this pattern:

[a1ex]

This CMOS[7] appears to have the same effect as CMOS[1] on 5D3; on 700D/100D/M it's also CMOS[7]. This register is used to select where the exposure starts and where it ends. The CMOS registers accept 12-bit values; some of them (including this one) may divided in two halves; others may be bit fields (so it makes sense trying every single bit individually) etc. On 5D3, the lower half (6 bits) adjusts where the exposure starts (adjust it to center the image) and the upper half (also 6 bits) adjusts where the exposure ends (if too high, you get a ghost image like in these screenshots).

These adjustments are available in the crop_rec submenu as well: cmos1_lo and cmos1_hi (you can change that to cmos7, cmos_new[7] etc). The value 2a5 can be written as PACK12(37,10), which doesn't make much sense to me. You could try changing these 2 values individually to see if they have any logic, or you could try dividing this register in some other way if it makes more sense. If you have no idea where to start, you could flip each bit starting from 0x2A5 (12 bits total: 2A5 ^ 1 = 2A4; 2A5 ^ 2 = 2A7; 2A5 ^ 4 = 2A1; ... ; 2A5 ^ 800 = AA5) and write down (or capture a screenshot of) the outcome for each of these 12 values.

Please note adtg_gui and crop_rec are unable to run at the same time; the first one will be able to install the hooks, and the second one will simply not work if you try to enable both. Therefore, the preferred way to experiment is to use the crop_rec submenu (and adapt it for your needs).

The sweet spot for CMOS[7] can be found by decreasing the end limit (after finding out what bits are used to encode it) until you get a white area at the bottom (or maybe black or otherwise without valid image data), then increase it by one notch from there.

[dfort]

The cmos_new[7] is being adjusted for cameras that have only the CROP_PRESET_3x3_1X ("is_basic") crop_rec option here:

Code: [Select]

    if (is_basic)
    {
        switch (crop_preset)
        {
            case CROP_PRESET_3x3_1X:
                /* start/stop scanning line, very large increments */
                cmos_new[7] = PACK12(6,29);
                break;           
        }
    }

While the 5D3 skips this. Maybe this is the problem? Either this needs to be skipped for the 6D or maybe we need to make a special case for the 6D to adjust CMOS[7] to 0x2A5 (or whatever we find works best) like this?

Code: [Select]

            case CROP_PRESET_3x3_1X:
                /* start/stop scanning line, very large increments */
                cmos_new[7] = (is_6D) ? PACK12(37,10) : PACK12(6,29);

I also noticed that the other "is_basic" cameras have the CROP_MODE_HACK feature but the 6D does not so checking for the 600D hack crop mode doesn't apply. That means we should probably make a special case for the 6D here too:

Code: [Select]

        if (is_basic && !is_6D)
        {
            if (reg == 7)
            {
                found = 1;
                /* prevent running in 600D hack crop mode */
                if (value != 0x800)
                {
                    ok = 0;
                }
            }
        }

Uploaded a couple of more test builds. One adjusting CMOS[7] to 0x2A5 and another build that doesn't make any adjustment to CMOS[7].

@alex - off topic - "make clean" wasn't cleaning out adtg_gui so my test builds were including it even though it should have been skipped. In addition, I'm not seeing the uncommitted changes in autoexec.bin which is really helpful. Did something break the new make system or maybe it hasn't been merged into the crop_rec_4k that I branched off of?

[a1ex]

@alex - off topic - "make clean" wasn't cleaning out adtg_gui so my test builds were including it even though it should have been skipped.

Confirmed.

In addition, I'm not seeing the uncommitted changes in autoexec.bin which is really helpful. Did something break the new make system or maybe it hasn't been merged into the crop_rec_4k that I branched off of?

This one seems to have worked - there no uncommitted changes that affected autoexec.bin, but there were some for the crop_rec module.

Code: [Select]

# from crop_rec_4k_no_cmos7_adjust.2018Feb18.6D116.zip
/path/to/magic-lantern/modules/module_hginfo_dump.sh crop_rec.mo
Name        : Crop mode recording
Author      : a1ex
License     : GPL
Summary     : Turn the 1080p and 720p video modes into 1:1 sensor crop modes
Description : This alters the 1080p and 720p video modes, transforming them
              into 3x (1:1) crop modes, by tweaking the sensor registers.
               [...]
Last update : cba0cec on 2018-02-18 07:54:51 UTC by Dan:
              Added ENGIO_WRITE addresses.
Build date  : 2018-02-18 16:45:23 UTC
Build user  : rosiefort@RosieFoComputer

modules/crop_rec/Makefile
modules/crop_rec/README.rst
modules/crop_rec/crop_rec.c
diff -r cba0cec2d4ba modules/crop_rec/crop_rec.c
--- a/modules/crop_rec/crop_rec.c
+++ b/modules/crop_rec/crop_rec.c
@@ -21,6 +21,7 @@
 #endif
 
 static int is_5D3 = 0;
+static int is_6D = 0;
 static int is_basic = 0;
 
 static CONFIG_INT("crop.preset", crop_preset_index, 0);
@@ -346,7 +347,7 @@
             }
         }
         
-        if (is_basic)
+        if (is_basic && !is_6D)
         {
             if (reg == 7)
             {
@@ -523,8 +524,11 @@
         {
             case CROP_PRESET_3x3_1X:
                 /* start/stop scanning line, very large increments */
-                cmos_new[7] = PACK12(6,29);
-                break;           
+                if (!is_6D)
+                {
+                    cmos_new[7] = PACK12(6,29);
+                }
+                break;
         }
     }
 
@@ -1865,6 +1869,7 @@
         ENGIO_WRITE = 0xFF2AE134;
         MEM_ENGIO_WRITE = 0xE51FC15C;
 
+        is_6D = 1;
         is_basic = 1;
         crop_presets                = crop_presets_basic;
         crop_rec_menu[0].choices    = crop_choices_basic;


[dfort]

Got it -- I was so used to looking in autoexec.bin for changes that I forgot that you need to run that script to see the changes in the modules.

Hope these changes look good to you. We'll see how they work on the camera. Don't know what is going on with lossless or if it can be fixed in camera but the crop_rec feels like it is almost there. Sure is challenging to work this out without the camera in hand. Not sure how to test this in QEMU or if it is even possible.

[Levas]

Uploaded a couple of more test builds. One adjusting CMOS[7] to 0x2A5 and another build that doesn't make any adjustment to CMOS[7].

The one without the CMOS[7] adjustment, looks just like your previous builds, ghost image in live view and recording.
Now the one with the CMOS[7] adjustments seems to work 
I've got multiple MLV's with 3x3 binning and 50fps 
BUT weirdly enough, the first time I tried this build, I got an error message on recording, multiple times.
But now I can't recreate this error.

Here are some logs:

Code: [Select]

ML ASSERT:
slots[slot_index].size < max_frame_size
at mlv_lite.c:3388 (raw_video_rec_task), task raw_rec_task
lv:0 mode:3

raw_rec_task stack: 1e0308 [1e03c8-1df3c8]
0x0044C914 @ b935fc:1e0338
0x0044C478 @ 44c970:1e0308

Magic Lantern version : Nightly.2018Feb18.6D116
Mercurial changeset   : cba0cec2d4ba+ (crop_rec_4k_6D.116)
Built on 2018-02-18 16:33:53 UTC by DFORT
Free Memory  : 342K + 2246K


Code: [Select]

ML ASSERT:
0
at mlv_lite.c:2497 (compress_task), task compress_task
lv:1 mode:3

compress_task stack: 1e4340 [1e43d0-1e33d0]
0x0044C914 @ b8e53c:1e4370
0x0044C478 @ 44c970:1e4340

Magic Lantern version : Nightly.2018Feb18.6D116
Mercurial changeset   : cba0cec2d4ba+ (crop_rec_4k_6D.116)
Built on 2018-02-18 16:33:53 UTC by DFORT
Free Memory  : 341K + 2246K


Will do some more testing to and see what it does.