Author Topic: 3K/UHD 5D2 Raw development and Other Digic IV Cams  (Read 18079 times)

Ilia3101

  • Member
  • ***
  • Posts: 203
Re: 3K/UHD 5D2 Raw development and Other Digic IV Cams
« Reply #100 on: September 05, 2017, 05:12:34 PM »
@ Ilia3101 here you go Source Code with modification magic-lantern-adtg-gui-4k-test_source_code.zip
Thanks a lot, I'll see if I can come up with any useful changes.

Can't save a dng yet , tried a image dump I can save the liveview422 see  post #90  here is the original LV dump 422 image  LV-002.422 in Black & White ML perview  I guess I should correct my self it did save a DNG file but it was "0" bytes and there was a HD Liveview dump image HD-002.422 which was normal looking .
I think to clean it up it could be as easy as fps A & B timing  or even the  Cmos  register , once there a clean LV image with ML B/W preview I think it may save a dng dump , there a raw record error when I try to save .raw file (Yes I'm still using raw 1st version not mlv lite , it's very basic just record raw once I have something stable I'll move to MLV Lite)
I have an idea why the preview is all noise: The 3K preset adjusts the preview parameters as well as raw parameters, so image framing is correct on 5D3 at the 3K res(is this true?), so maybe it ruins the preview on 5D2.
I'll try and find where the presets are in the code and comment out the changes in it that are irrelevant, maybe the image will be clear then.

@ Ilia3101 I will also PM you with the test 3.5k build I was using to do my test  that I posted in #90 , I don't what to post it publicly so it get out in the wild.
Thx
5D2

reddeercity

  • Hero Member
  • *****
  • Posts: 1378
Re: 3K/UHD 5D2 Raw development and Other Digic IV Cams
« Reply #101 on: September 06, 2017, 07:53:04 AM »
A small correction I did not use the 3x crop buffer in raw.c
Code: [Select]
#define RAW_LV_BUFFER_ALLOC_SIZE (2040*1267) it's the 1:1 buffer , just look at post#90 in the Edmac screen shot on EDM#5 , address "43e28a4" 3570x1267 (3570/14*8 = 2040) . You could try the 3x crop buffer which is 4046 x 1127 so (4046/14*8 = 2312)
Quote
I have an idea why the preview is all noise: The 3K preset adjusts the preview parameters as well as raw parameters, so image framing is correct on 5D3 at the 3K res(is this true?), so maybe it ruins the preview on 5D2.
I'll try and find where the presets are in the code and comment out the changes in it that are irrelevant, maybe the image will be clear then.
Look at this for help adtg_gui.c-1127 and also this adtg_gui.c-1343

reddeercity

  • Hero Member
  • *****
  • Posts: 1378
Re: 3K/UHD 5D2 Raw development and Other Digic IV Cams
« Reply #102 on: September 07, 2017, 05:13:57 AM »
Found some helpful information for "CONFIG_EDMAC_RAW_SLURP"  treatment on 5D2 , as many times I read over this code I never see this  :o
I think this is a better way then "RAW_LV_BUFFER_ALLOC_SIZE" but not sure if this works on digic 4 cam's  so far it works with digic5 ,
I'll give it try , this is the link to the code starts at line 407 allocate-raw-lv-buffer#Lsrc/raw.cT407
Code: [Select]
408  * How to find buffer dimensions for CONFIG_EDMAC_RAW_SLURP:
409  * - Go to LV and use lv_save_raw
410  * - Check the RAW_LV_EDMAC debug info
411  *  - Suppose it reports W: 0xA3A H: 0x3C7 (taken from 1100D in LV mode)
412  * - EDMAC W is the number of bytes per line
413  *   - The W resolutions is computed as: W * 8 / 14 (raw buffer is 14 bits per pixel)
414  *   - Thus 0xA3A  8 / 14 -> 1496 pixels
415  * - EDMAC H is the number of "jumps"
416  *   - The H resolutions is H + 1 -> 0x3C8 -> 968 pixels

Edit: This will have to be add to "platform / 5D2.212 /  internals.h"
Code: [Select]
/** this method bypasses Canon's lv_save_raw and slurps the raw data directly from connection #0 */
#define CONFIG_EDMAC_RAW_SLURP
not to sure about "connection #0" thou -- this maybe a wild goose chase

Ilia3101

  • Member
  • ***
  • Posts: 203
Re: 3K/UHD 5D2 Raw development and Other Digic IV Cams
« Reply #103 on: September 07, 2017, 09:45:04 AM »
Haven't really managed to get anywhere ::)
I tried changing the presets, separating the 3k one out in to 2 parts, but didn't really help.

I suspect I might have the same exact 'soft brick' you complained about before, as I had tried out your changes a while ago and seen results, now I'm not seeing anything.

Every time I try and do anything with magic lantern I always slow down eventually and give up for a bit, then I try again and the cycle repeats :(

Interesting about the SLURP thing though.
5D2

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10183
  • 5D Mark Free
Re: 3K/UHD 5D2 Raw development and Other Digic IV Cams
« Reply #104 on: September 07, 2017, 09:53:11 AM »
not to sure about "connection #0" thou -- this maybe a wild goose chase

Connections are probably hardcoded (or configured in a way we don't currently understand) to various image processing modules. So far, all the D4 and D5 models get the LiveView RAW data from connection 0. Connection 6 and 7 are pass-through (whatever you transfer there using a Read EDMAC channel will be copied on the other side, to a Write EDMAC channel configured for the same connection).

See this diagram (from http://www.magiclantern.fm/forum/index.php?topic=18315.msg188630#msg188630 )



A read EDMAC channel will read the data from RAM and send it to some image processing module.

A write EDMAC channel will get the data from some image processing module and will write it into RAM.

The data can be read via some input module (such as DSUNPACK, ADUNPACK, UNPACK24, or others - possibly unnamed), where you can configure the input bit depth. In this case, the input stream can be 10-bit, 12-bit, 14-bit or 16-bit, configured using DSUNPACK_MODE / ADUNPACK_MODE / UNPACK24_MODE / 0xC0F371FC / etc. In this case, the image processing module that actually does the work (e.g. JPCORE) probably receives normalized data.

A similar process happens on the output side, where a PACK module is used (PACK16, PACK32). Remember the PACK32_ISEL and PACK32_MODE:
- PACK32_ISEL probably means "wire the input of PACK32 module to whatever other image processing module that outputs Bayer data, in various places in the pipeline";
- PACK32_MODE configures the output bit depth of whatever image data arrives to the PACK32 module (10/12/14/16).

Currently, the uncompressed bit depth selection is done in raw_lv_request_bpp (raw.c, crop_rec_4k branch).

Experiments on the above can be made on existing code that's known to work (raw_twk for digic 4/5, EekoAddRawPath for digic 5), or on FA_MaxSelectTestImage / FA_SubtractTestImage (low-hanging fruit for understanding the image processing modules).

One interesting note from the crop_rec_4k thread, where I've implemented the 10/12-bit lossless compression by darkening the input raw data (so the input and output would still be 14-bit, but there will be fewer levels actually used by the image - as many as a 12-bit or a 10-bit image). For lossless compression, the entropy of a 10/12-bit stream is similar (maybe identical?) to the entropy of a 14-bit stream with each value shifted by 4 or 2 bytes (integer division by 16 or by 4).

How does that work?

raw.c:raw_lv_request_digital_gain:
- lv_raw_gain is written to SHAD_GAIN_REGISTER
- RAW_TYPE_REGISTER is set to 0x12 (DEFCORRE)
- this image happens to be scaled by digital ISO gain and is not affected by bad pixels.

When the digital gain is not set, RAW_TYPE_REGISTER is set to CCD (probably the first stage where the raw data gets in the digital domain).

For a better understanding, set RAW_TYPE_REGISTER to DEFCORRE (0x4 on digic 4) without overriding SHAD_GAIN, and notice what happens at ISO 320 vs 400. Repeat for RAW_TYPE_REGISTER set to CCD. Then start overriding SHAD_GAIN with any values you want, even something like this:
Code: [Select]
if (get_halfshutter_pressed())
{
    EngDrvOut(SHAD_GAIN_REGISTER, rand());
}


Now look at the problems that appeared from this change (the 10/12-bit lossless implementation):

- First of all, the "slurp" EDMAC channel (the one that writes the raw data into memory) had to be configured for exact resolution; the autodetection from raw_lv_get_resolution (0xC0F0680x/0xC0F0608x) is not exact - it's often off by one on the vertical direction, although the exact reason is unknown. Being off by one on 5D3 resulted in the raw data being correct only on every other frame (although I don't really understand why that happens). The issue was only with RAW_TYPE_REGISTER set to DEFCORRE, but it all worked fine when it was set to CCD.

- Next, take a look at this bug: in a video mode with increased vertical resolution, the darkening works only on the top side, on an area equal to default Canon resolution in that video mode. That means, we have to reconfigure some more registers - probably in the image processing pipeline, all the way from CCD (sic) to DEFCORRE. Which ones? I don't know - couldn't find them in adtg_gui. I hope to find them by emulating the LiveView in QEMU, but that's going to be a really long journey.

That's why, for now, the 10/12-bit lossless compression only works in video modes with unmodified resolution (plain 1080p, plain 720p and 5x zoom).

reddeercity

  • Hero Member
  • *****
  • Posts: 1378
Re: 3K/UHD 5D2 Raw development and Other Digic IV Cams
« Reply #105 on: September 08, 2017, 05:51:43 AM »
@Ilia3101 -- baby steps  ;D just pick one thing to focus on and learn as much as you can , look closer at what the code is doing in the 3k 5d3 preset , there a lot of clues there even thou it for the 5d3 the 5d2 share some similarities in this respect
it may not look like there much progress right now but we are laying out the frame work for more then 3.5k video this will also lead to FHD 10/12bit and even in time compressed raw .

@a1ex thanks for the lesson , things are getting clearer .

Wayne H

  • New to the forum
  • *
  • Posts: 23
Re: 3K/UHD 5D2 Raw development and Other Digic IV Cams
« Reply #106 on: September 08, 2017, 07:18:20 AM »
@Alex that is an excellent and highly detailed explanation on how you Magic Lantern magicians are squeezing 3.5K and 4K out of the 5d3,

I was wondering a while back why the 12bit and 11-8bit lossless options were only available on the 3.5K mode, and not in the other UHD and 4K modes, but after doing some magic lantern reading, i quickly understood that the 3.5K mode works differently to all the other high resolution modes,

Makes me appreciate just how much work you guys do in your own free time, LIVEVIEW is incredibly complex. (it took Canon 6 months just to get the 5d3 to spit out clean and mirrored HDMI via a firmware update) AMAZING WORK GUYS.