crop_rec_4k for the 6D.116.

#875 Declined
Repository
daniel_fort
Branch
crop_rec_4k_6D.116
Repository
hudson
Branch
crop_rec_4k
Author
  1. Daniel Fort
Reviewers
Description

Got the 6D.116 working on the crop_rec_4k branch. Being a full frame camera it is similar to the 5D3 and can use much of the same code.

Still needs more testing.

Thanks Danne for the help.

Forum discussion starts here:

http://www.magiclantern.fm/forum/index.php?topic=15088.msg191691#msg191691

Comments (5)

  1. Alex

    Unlikely to find a fix in the camera in the near future - better just document the workarounds in post, or implement something in mlv_dump.

    The only issue with the second way: not all raw processing programs use the same Bayer order for per-channel black levels - http://www.magiclantern.fm/forum/index.php?topic=15088.msg192898#msg192898

    Is it a bug in RawTherapee? (todo: document it properly and report it)

    Nitpick: corrupted image at certain resolutions (workaround available).

    Going to merge in this state; just summarized the next steps.

      1. Alex

        650D looks a lot different, but doing a register comparison in QEMU with a model from the same generation, but different resolution (wait a minute, can't find any) should help. I'll compare them and post the results in the thread. Test code will be: call the lossless compression on some dummy "image" (can be zeroed out, but needs to have the correct size - can be faked). If silent.mo works on the tested model, even better.

        Greg did one such comparison for 500D vs 7D, but this one is a lot more difficult to interpret: http://www.magiclantern.fm/forum/index.php?topic=18443.msg184283#msg184283

  2. Levas - MagicLantern - 6D

    With current test build (4Feb2018Build from Dfort) (which uses the same modulo restrictions as other builds and cams) you have 3 outcomes with lossless in MLV_lite on the 6d: Option 1: It works (after blacklevel fix) Option 2: You get frames with bottom half corrupted, all frames in the MLV have this, not just a few, all frames. Option 3: You get normal sized MLV's, but you can't extract any dng's out of it. Also while recording, emptying the buffer is painfully slow when selected a resolution which gives option 3 outcome.

    Haven't tested all possible resolutions, but did a quick test with the current build from Dfort. 1824 x 768 = good frames 1808 x 1016 = good frames 2544 x 960(5xzoom) = good frames 2528 x 960(5xzoom) = good frames 2512 x 960(5xzoom) = good frames 1824 x 1026 = Bottom half corrupted frames 2592 x 960 (5xzoom) = good 2560 x 960 (5xzoom) = MLV where no dng's come out with mlv_dump.

    If I remember correct, restricting the 6d to only modulo 8, didn't help, outcome was more resolutions had the bad MLV's, where no dng's came out.