Canon 6D

[dfort]

Right, mlv_lite has lossless compression but no sound capabilities and mlv_rec can use mlv_snd but doesn't have lossless compression. There is an option to do H.264 proxies with mlv_lite which works great on the 5D3 but I haven't been able to getting it running properly on other cameras.

Thanks to Levas and NunoCaldeira for the testing and a huge thank you to Danne for finding a critical piece of code that I overlooked.

Let's start testing out crop_rec_4k on the 6D. Things to try out: crop_rec module - is it working? How about compressed silent pictures? If someone could run this test it would be really helpful.

[dfort]

Pull request is open. Test build on my Bitbucket downloads page. I'll keep it updated with any changes to the crop_rec_4k branch.

[Levas]

Wait wait, could be that it needs a little finetuning.
The frames I get with lossless recording are a little weird, first I thought it was me who was doing things wrong with converting the mlv's to dng's with some older mlv_dump versions.
But it turns out that the silent picture module, which can create lossless dng's, also gives weird frames.

Here's an example of a normal silent picture and a lossless silent picture
http://drive.google.com/drive/folders/0B1BxGc3dfMDaNGZtLWwtYVd5WXc?usp=sharing

[a1ex]

There might be some unhandled case in our lossless decoder and maybe also in dcraw, or there may be some encoder misconfiguration.

Test #1 - you can use any build with lossless compression enabled:

To find out whether the fault is in our decoders, or on the encoder side, try loading a lossless silent DNG in pic_view from file_man. Only run this if mlv_dump or dcraw output is obviously wrong (maybe as in the above example, maybe with other defects).

Results:
- Looks fine? The problem is in our PC-based decoders (dcraw, mlv_dump).
- Image from pic_view has the same defects as with dcraw/mlv_dump? The problem is in the encoder configuration (lossless.c).
- Image from pic_view broken, or playback doesn't work? Look at Canon's lossless decoding stubs, or at the way we call it from pic_view/mlv_play.

Test #2 - you need to compile a custom silent.mo:

To check whether this bug affects your camera (applies to any model that supports lossless compression), or to investigate and hopefully fix it, follow these steps:

Step 1: save some image as both 14-bit lossless *and* 14-bit uncompressed (it *must* be the same image, not just the same static scene):

Code: [Select]

diff -r 8ee7858f0d7e modules/silent/silent.c
--- a/modules/silent/silent.c
+++ b/modules/silent/silent.c
@@ -560,3 +560,5 @@
             if (!ok) bmp_printf( FONT_MED, 0, 83, "DNG save error (card full?)");
-            return ok;
+            extern void reverse_bytes_order(char*, int);
+            reverse_bytes_order(raw_info->buffer, raw_info->frame_size);
+            /* fall through */
         }

Step 2: compare the raw data and check whether there are any differences (on 6D and 650D, there will be; on other models, hopefully not):

Code: [Select]

dcraw -4 -E 12340000.DNG 12340001.DNG
md5sum 12340000.pgm 12340001.pgm

Step 3: if the two checksums are different, investigate the differences (tutorial):

Code: [Select]

octave:1> a = imread('12340000.pgm');
octave:2> b = imread('12340001.pgm');
octave:3> manual inspection, imshow(a - b, []) etc

Step 4: adjust the lossless decoder (either the one from dcraw, or lj92.c from mlv_dump) or the encoder configuration (lossless.c) until these differences disappear (how? I don't know, you need to experiment)

Step 5: repeat for 650D and all other models (I've ran this test on 5D3, got identical checksums at step 2)

Good luck!

[Levas]

Test 1
Result
- Image from pic_view has the same defects as with dcraw/mlv_dump? The problem is in the encoder configuration (lossless.c).

Test 2
Made 2 pairs of silent pics with a custom silent.mo (with some help from Dfort  )
https://drive.google.com/drive/folders/0B1BxGc3dfMDaaDhrcTVCNkJ4a2s?usp=sharing

There's also a 5th picture in this directory, it's a silent dng, but it shows nothing, but it has the full file size? This happened before with the silent module which can handle lossless.

Step 1 is done
Can other people help with step 2, 3, 4 and 5 (see post from Alex above)

[Levas]

Ok, I believe I have done step 2.

Got two pgm files from the number 2 images I posted, did md5sum check and got two different checksums, as expected...
18c6f801394a14aa87bc5159f9c73c74
VS
dc8cc8bb8eda68bd63551228b435de1f

So next step 3...

[dfort]

Here are the md5sum values for all of the files @Levas uploaded:

Code: [Select]

3864c9ff665c0377f79590c6121838bd  1-lossless.pgm
7a504ba8fdb627b3706abc8c3f69a672  1-normal.pgm
dc8cc8bb8eda68bd63551228b435de1f  2-lossless.pgm
18c6f801394a14aa87bc5159f9c73c74  2-normal.pgm
69373f9824213b4cd65933bc1e37091c  No-image-normal-mode.pgm

Uh oh -- got some studying to do. Not well versed in octave.

Code: [Select]

octave:1> a = imread('1-normal.pgm');
octave:2> b = imread('1-lossless.pgm');
octave:3> manual inspection, imshow(a - b, []) etc
parse error:

  syntax error

>>> manual inspection, imshow(a - b, []) etc
                                           ^

[EDIT]

Code: [Select]

octave:4> imshow(a - b, [])

[a1ex]

Alright, so the defect appears to be a per-channel offset. Let's check the two images that are supposed to be identical - will look at the 4 Bayer channel differences (R, G1, G2, B):

Code: [Select]

octave:1> a = imread('2-normal.pgm');
octave:2> b = imread('2-lossless.pgm');
octave:3> for i = 1:2, for j = 1:2,
>           chd = (a-b)(i:2:end,j:2:end);
>           disp([min(chd(:)), max(chd(:))])
>         end, end
  128  128
  256  256
  512  512
  1024  1024

Result: each channel differs from the ground truth by a constant value (that happens to be power of 2!)

There are no other differences (that was the role of min and max).

Let's check the other pair of images (slightly different scene, so you can't draw many conclusions from their raw difference). Will check only their optical black area; in this case, min and max will no longer be relevant, as we will be looking at two different samples; let's take a look at median differences (median is statistically robust):

Code: [Select]

octave:4> a = imread('Silent-14bit.pgm');
octave:5> b = imread('Silent-lossless.pgm');
octave:6> for i = 1:2, for j = 1:2,
>           chd = (a-b)(i:2:end,j:2:50);
>           disp([min(chd(:)), median(chd(:)), max(chd(:))])
>         end, end
    0  128  214
  151  256  329
  397  512  599
  961  1024  1092

Result: median differences are the same as before!

This defect is likely predictable and can be easily worked around in post. Let's check the actual black levels (if you didn't do the math already):

Code: [Select]

octave:7> for i = 1:2, for j = 1:2,
>           obch = b(i:2:end,j:2:50);
>           disp(median(obch(:)))
>         end, end
1919
1791
1536
1024

Dial these values in darktable (the 4 black level sliders) and the image is back to normal

Homework for you: hardcode the above black levels in the DNG with exiftool / exiv2 / whatever you prefer.

[dfort]

Amazing. Here's the 1-lossless.DNG file Levas uploaded:

Homework for you: hardcode the above black levels in the DNG with exiftool / exiv2 / whatever you prefer.

@Danne -- you're the exiftool / exiv2 expert, want to give it a shot?

So this can only be worked out in post or is there something more we need to do to get lossless working on the 6D? Does this also apply to the issues on the 650D?

[a1ex]

It can be worked around in post, or - preferably - it can be fixed in lossless.c. The only issue - I have no idea where to start. Maybe this can help. Or running Canon's compression routine in QEMU and comparing register configurations with our own. BTW, is the defect present on a full-res silent picture? What about different resolutions?

The issue from 650D is not that obvious, but you can look into it if you like math

[dfort]

BTW, is the defect present on a full-res silent picture?

We found out that the defect on the 650D doesn't appear in a FRSP. The 6D probably needs my hack in order to save a lossless FRSP. I'd give you a proper fix but I have no idea where to start. 

Could a 6D user please check and see if you can save a lossless Full Resolution Silent Picture using the crop_rec_4k test build I posted?

[Levas]

Tried the build, but I can't take full res silent pics with it, at least not lossless.
Normal dng full res works, but if lossless is activated, no image is saved on the card 

[dfort]

I posted a new build with the FRSP hack that works with the EOSM/100D/650D/700D. Hopefully it will also work with the 6D.

https://bitbucket.org/daniel_fort/magic-lantern/downloads/crop_rec_4k_with_lossless_FRSP.2017Oct18.6D116.zip

[Levas]

Tried Dfort latest build, but can't get any lossless full res silent pics with it.
Normal full res silent pics works.

Can other people with 6d confirm ?

[Audionut]

Confirmed.




dfort, I prefer for conversation to be in this thread, it's pretty much what this thread is here for.  The problem I find with pm is that the conversation gets segregated to those in the pm.
I like to follow along, even if I don't have the time to jump in and swim with the rest of you.   

Nice to see devs bugging a1ex with stuff.  Keeps the brain ticking.  Good work.

[Levas]

Digging through lossless.c because Alex said the problem is there.
Can't find anything about the black levels.
http://bitbucket.org/daniel_fort/magic-lantern/src/0c3ef797ce995b51e86184049350022d0ee97324/modules/silent/lossless.c?at=crop_rec_4k_6D.116&fileviewer=file-view-default

However, lossless.c also uses raw.h, where black levels are written into the file, only thing is, the black levels seems to be autodetected 
http://bitbucket.org/daniel_fort/magic-lantern/src/0c3ef797ce995b51e86184049350022d0ee97324/src/raw.h?at=crop_rec_4k_6D.116&fileviewer=file-view-default

[a1ex]

You won't find it in ML source - it's in Canon code (and maybe not in the ARM side of the code, which you can inspect and emulate, but in their image processor, which is a black box to us).

Since Canon code configures the lossless encoder properly (they don't have this issue in CR2 files), but we have it, all we can do is to compare the encoder configuration (hardware registers) done by their code (by logging their still photo capture process) vs our own code (by logging a lossless encoding session in the same way). You can do that with dm-spy-experiments (limitation: you can only see the registers set from high-level functions; some are set by writing directly to MMIO - you won't see these with this method), or by running both codes in QEMU ("-d io" shows all registers, including those set directly), but the latter method requires understanding the photo capture and the lossless encoding processes well enough to be able to emulate them.

So far, the 6D is the only single-digic model that runs ML, but cannot be emulated in QEMU. What are you waiting for?!

Also, this PR (new DryOS task hooks) is open since 2015, and I'd really like to have it in the nightly builds (100D, 70D and EOSM2 are all waiting for it), but other than 2 screenshots from Audionut, there was zero feedback from 6D users. What are you waiting for?!

Yeah, I know, neither option will give you 4K at 300 FPS...

[dfort]

...The problem I find with pm is that the conversation gets segregated to those in the pm....

Right, I was us PM's instead of IRC to get a rapid exchange going with a small group until we got something worth sharing. I believe the firewall where I work might be blocking IRC. I was also anticipating some camera lock ups and possibly needing a new firmware dump to see if maybe the one I was using. In any case, we're back on the forum and it would be great if more 6D users would get involved in this crop_rec_4k experiment and comment both here and on the pull request which, by the way Audionut I put you down as a reviewer because you know a lot more about this camera than I ever will.

Back to the testing--I'm still not sure if the crop_rec module is working. Loading only the crop_rec module, does it look stretched vertically like this when the Canon menu is set to 1280x720?



or does it look normal like this:



I see other people are getting those diagonal lines on their ML Screenshots, any idea what is causing that and if there's a way to fix it?

[Audionut]

which, by the way Audionut I put you down as a reviewer because you know a lot more about this camera than I ever will.

You're to kind.

Back to the testing--I'm still not sure if the crop_rec module is working. Loading only the crop_rec module, does it look stretched vertically like this when the Canon menu is set to 1280x720?

Looks fine to me.

I see other people are getting those diagonal lines on their ML Screenshots, any idea what is causing that and if there's a way to fix it?

Turns out those lines are underexposure zebras, jpg based of course.  Well, the only way I can make them appear is to underexpose.
edit:  Hang on, it appears that overexposure zebras are being displayed in some funky situations.  This needs further testing.
edit2:  In a severely underexposed scene.


This is silent.mo normal DNG.  Initial full white screen, then the black areas become overlayed.  You can see the background white around the spot meter.


Lossless DNG.  Replace black overlay with stripes.

Also, the help dialog says that raw zebras need raw shooting enabled, when I was performing the test above (crop_rec only enabled).  Enabling mlv_something does the trick (obviously), but I have no idea how that plays with crop_rec. The crop_rec stuff happened after I lost time for this project, so I've only been very loosely following, but I assumed crop_rec was raw based.

Also, this PR (new DryOS task hooks) is open since 2015, and I'd really like to have it in the nightly builds (100D, 70D and EOSM2 are all waiting for it), but other than 2 screenshots from Audionut, there was zero feedback from 6D users. What are you waiting for?!

What are you waiting for?   

Confirmation from more 6D users.
Something else in Stack trace (aka backtrace) in crash logs.
Serial flash contents.

The last one seems obvious that you are still waiting for.  If you're willing to do that easy coding task, and the dev team are willing to help with any issues that crop up while performing the required tasks, I'm willing to put the (remaining) effort in.  I need my hand held.  Bonus points if you compile the module also.

I just need life to settle down a little more before I go and commit to time (for this project) that I don't have.

[a1ex]

Soon after enabling the new DryOS hooks on 100D, we ran into trouble (check the next few pages - some cameras unable to start). That particular issue was fixed meanwhile, but...

This wouldn't have happened if a few knowledgeable 6D users would have tried the PR and reported the issue (they had about 2 years to try it and notice the error). I prefer these changes to be tested by somebody familiar with the codebase before they get into the build recommended to regular users for first-time use. And backend changes like this one, which can possibly affect each and every ML function (hopefully none of them) should deserve a little more attention from those who can read the source code (and understand at least some of it).

(I've bumped this PR once, but it's not fun...)

[dfort]

Serial flash contents.

The last one seems obvious that you are still waiting for.  If you're willing to do that easy coding task, and the dev team are willing to help with any issues that crop up while performing the required tasks, I'm willing to put the (remaining) effort in.  I need my hand held.  Bonus points if you compile the module also.

Bonus point - did the easy coding task and posted a sf_dump module that should work with the 6D on my Bitbucket downloads page. Also submitted a pull request with @Audionut and @Levas as reviewers.

Totally understand about not having time--life happens.

[a1ex]

I was hoping there might be other 6D users able to follow a tutorial, but...

[dfort]

I don't have access to a 6D and my wife will leave me if I get another camera. Last one I bought was a used C300. Don't worry, I don't plan to put ML on it, I'm not that crazy -- though it does have a 4k sensor...

Back on topic, will the SFDATA.BIN help get the 6D working in QEMU?

[a1ex]

I hope so. If that won't work, I'll also need a startup log (dm-spy-experiments branch) with mpu_send and mpu_recv stubs (but for now, the errors I'm getting appear to be from incorrect serial flash contents).

[Walter Schulz]

I was hoping there might be other 6D users able to follow a tutorial, but...

... drawback with blindly supported cams ...
Download statistic shows 1000+ 6D nightly build downloads frequently. I suppose most 6D users (the kind actually doing stills/movies) won't show up in this forum because things run pretty well for them and they are unaware their help is needed to make it even better. I'm doing quite the same with other open source stuff: Just looking for updates.

Maybe some message box/hint in 6D download page would help finding some computer-savvy photog willing and able to give back.