LiveView Investigation

[theBilalFakhouri]

These LiveView Crop Registers and Screen/LiveView/HDMI resolutions threads don't fit the info I will discuss, I want to draw the full image of the complex LiveView (with your help), How things related to each other, It's difficult to do it myself alone So any help from you is needed.

for Users: the main goal for me is to achieve real-time correct framing preview.

Today I am Discussing :

1- LiveView Crop Registers
2- YUV Resolution
3- HDMI Black Bars

Let's start investigating:

LiveView Crop Registers

From LiveView Crop Registers thread:

"By locking the registers between x5 and x10 you can bring x10 real-time preview into x5 vice versa in Canon 700D, here is the registers between the two:"
Google spreadsheet Link

A couple of days ago I succeed to reduce the cropped preview area but only in x10 mode for both width and height, actually I got the full width of x5 mode in x10 mode, but the things get different for these registers in x5 mode, it will not work in the same way, I noticed 3 types of registers:

1- Stretching Registers
2- Limit Registers Registers control the Limits of other Registers (Has no visual effect)
3- Preview Region Registers control the region of cropped area, its values are a resolution values

1- Stretching Registers

There are specialized registers for Vertical stretching and other registers specialized for Horizontal stretching, let's take a look for Horizontal registers first:

1-C0F11B8C
2-C0F11A8C

3-C0F11A88 (Has two values 0x0 or 0x1, Reverts C0F11B8C effect)

These first two registers have a ratio between the left part and right part values, it changes at different modes depending on other factors Like YUV resolution and the preview area, Examples in x5 Mode:

C0F11B8C = 0x0*
C0F11A8C = 0x1E002B

With default value, a normal view in x5:


Tweaked C0F11A8C to 0x1E003B, It seems it's trying to show a new part of LiveView but there is no Data to show it, it seems like signal loss in this area:


Tweaked C0F11A8C to 0x1E001B, You lose part of LiveView by stretching it, Simply this the trick which Canon uses to make a Digital lossy Zoom like in x10 Mode:


C0F11B8C has the same effect, its value in *Idle mv1080 (Without H.264 Recording) = 0x50009, Tweaking it to 0x5000a gives the lost signal, Tweaking it to 0x50008 gives a Horizontal Zoom.

These registers have limitations, You can't decrease/ increase too much, the limitations are coming from the ratio between the two parts in the same register e.g in C0F11A8C between 0x1E002B, or other registers depending on the mode, not sure what are they exactly.

Note: C0F11A88 gives same result as above two registers, the differences are it has two values 0x0 or 0x1, in x5 mode it's 0x0 , tweaking it to 0x1 gives massive Horizontal stretching (Zoom) in one step, and it reverts C0F11A8C  effect, normally in x5 mode C0F11A8C = 0x1E002B, tweaking it to 0x1E003B will show the signal loss, but after tweaking C0F11A88 from 0x0 to 0x1 in x5 Mode, Now tweaking C0F11A8C to 0x1E003B will increase the Horizontal stretching (Zoom) instead of giving the signal loss or compressing LiveView Horizontally, its effect has been reverted by C0F11A88.

in x10 Mode C0F11A88 = 0x1, tweaking it to 0x0 gives massive signal loss area in one step.

Second, the Vertical registers in x5 Mode:

1-C0F11BCC = 0x0*
2-C0F11ACC = 0x1E002B (Yes same value as Horizontal one)

3-C0F11AC8 (Has two values 0x0 or 0x1, Reverts C0F11ACC effect)

Vertical registers are more aggressive, for C0F11ACC in x5 mode if you attempted to increase it value from 0x1E002B to 0x1E003B to get signal loss as the Horizontal register, it will stuck the LiveView maybe because there no data to show, figure out how to Control it without frozen LiveView, tweaking it to 0x1E001B gives a vertical Zoom stretching.

Default C0F11ACC value in x5 Mode:


Tweaking C0F11ACC to 0x1E001B in x5 Mode:


Also C0F11BCC has same value as C0F11B8C, its value in *Idle mv1080 (Without H.264 Recording) = 0x50009, Tweaking it to 0x5000a gives the a frozen LiveView, Tweaking it to 0x50008 gives a Vertical Zoom stretching.

2- Limit Registers and & 3- Preview Region Registers

Let's start with the Experiment:
Reducing the Cropped area in x10 Mode:

Link:

Code: [Select]

youtu.be/cK_A-4tvskY
Results:
Default x10 Mode:


Default x5 Mode:


Reduced Cropped Area in x10 Mode




Random Notes and Details:

1- There are some registers controls some factors between the stretching registers and region of cropped area registers, and affect how it work together, and by tweaking these registers with other adjustments for the registers showed in the video above we can get the full height of x5 Mode in x10 Mode, I don't understand these scaling routines and how it affect the limits and the cropped area yet, so I don't have accurate answer what is it really doing, Here are Three Example in x5 Mode: (Also Managed to get full width of x5 Mode into x10 by tweaking only three registers)

Link:

Code: [Select]

https://youtu.be/gmU6_GknchI
2- Reducing x5 Cropped Area Experiment:

3- Some registers with 0x80XX00XX appear to control the preview, some of them can break LiveView also.

-The best way to start is by increasing or trying to fix 1x3 Preview, the required registers are between mv720 and mv1080, I hope there is no other registers should change to fix 1x3 preview, and there is no Horizontal registers to deal with.

YUV Resolution

Without HDMI black bars Experiment and DebugMsg LOG I wouldn't be able to get this, a1ex is a bit evil on this . .

c0f04xnn: EDMAC channel "x", filtered out

He is filtering our registers out of adtg_gui , commented out these Lines :

Code: [Select]

    if ((dst == 0xC0F0 && (reg & 0xF000) == 0x4000) ||  /* EDMAC block 1: 0xC0F04xnn */
        (dst == 0xC0F2 && (reg & 0xF000) == 0x6000) ||  /* EDMAC block 2: 0xC0F26xnn */
        (dst == 0xC0F3 && (reg & 0xF000) == 0x0000) ||  /* EDMAC block 3: 0xC0F30xnn */
        0)
    {
        /* ignore EDMAC activity */
        return;
    }
Especially this range of registers "0xC0F04xnn" , Now we can get interesting ones . .

-How did I find out what controls YUV resolution properly?

In Idle mv1080 and Idle mv720 Mode YUV resolution is 960x639 A.K.A in ML Menu the Craw buffer size:


When you start H.264 recording it changes to 1728x1151 on 700D, interesting:


When you start H.264 recording in mv720 it changes to 1280x689


Now using adtg_gui between Idle and H.264 recording we can Identify these registers:
Craw Buffer Changing

Increasing YUV resolution Experiment in mv720

Link:

Code: [Select]

https://youtu.be/ESKSDLcywzU
Download Dumped YUV files Also included 422ToImage 1.9.2, the Repository is down.

-Does YUV resolution control or related to cropped area in x5 Mode? YUV resolution in 700D in x5 Mode is 1032x687, matches 1032x687 of RAW data without up-scaling (you can align YUV dump and RAW DNG dump without re-sizing unlike idle mv1080 on 700D), also Movie Crop Mode has 1728x971 YUV resolution out of the box, I will do an Experiment to decrease YUV resolution from 1728x971 to 960x539 to see if LiveView will be cropped more.

-Didn't play with Vertical resolution registers, I can override mv1080 H.264 registers in Idle mv1080 and LiveView still working with increased YUV resolution, increasing Vertical resolution is possible, might be simpler.

-This might lower the overhead when using HDMI, maybe if we decrease YUV resolution? using HDMI on 700D in mv1080 YUV resolution is 1620x639.

-I have tried to record H.264 @ 1728x689 instead of 1280x689 in mv720 to force H.264 Encoder to down scale 1728 to 1280 instead of YUV path, however I got stuck video in H.264 file.

HDMI Black Bars

By pressing Info button you can toggle between two Canon default previews which are Canon global DRAW with a small Canon Preview with black bars in the Left and Right, also in the bottom, and the second Preview by Canon without Canon global draw and with bigger size LiveView, I captured a LOG using DebugMsg in x5 Mode (Because YUV resolution are not changing in x5 mode), I narrowed down to this part of the LOG:

Code: [Select]

4.441.384  **INT-6Dh*:ff37cf1c:ad:03: RamClear_StartPath
 4.441.394  **INT-6Dh*:ff37d084:ad:03: RamClear_LV_RAMCLEAR_COLOR_BLACK
 4.441.467  **INT-6Dh*:ff37c334:ad:03: LV_StartTripleRamClearPassLR Width:600, Height:440, VW:3840
 4.441.482  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11004] <- 0x00000000
 4.441.484  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11440] <- 0x00000001
 4.441.485  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11444] <- 0x00000000
 4.441.487  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F1108C] <- 0x00000002
 4.441.488  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11144] <- 0x00000001
 4.441.490  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11448] <- 0x00001000
 4.441.491  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F1144C] <- 0x00000001
 4.441.493  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11450] <- 0x01B70257
 4.441.494  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11454] <- 0x00000257
 4.441.553  **INT-6Dh*:ff37c3f0:00:00: *** RegisterEDmacCompleteCBR(0x5, 0xff37bfdc "WriteEDmac1CompleteCBR[%x]", 0x777c4)
 4.441.574  **INT-6Dh*:ff0c7ba4:MMIO : [0xC0201010] <- 0x0000006D
 4.441.575  **INT-6Dh*:ff0c7ba8:MMIO : [0xC0201200] -> 0x00000001
 4.441.636  **INT-6Dh*:ff37c404:00:00: *** SetEDmac(0x5, 0x4b9ee000, 0x24bf14, 0x60000000)
 4.441.714  **INT-6Dh*:000c76ec:00:00:     size (600, skip 3240) x 439, 600, skip -1683120,
  (600, skip 3240) x 440
 4.441.733  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F0450C] <- 0x00000001
 4.441.737  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04510] <- 0x01B70258
 4.441.741  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04514] <- 0x00000258
 4.441.743  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04518] <- 0x00000CA8
 4.441.745  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F0451C] <- 0xFFE65150
 4.441.747  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04520] <- 0x00000CA8
 4.441.748  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04524] <- 0x00000000
 4.441.750  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04528] <- 0x00000000
 4.441.756  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F04504] <- 0x60000000
 4.441.757  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F04508] <- 0x0B9EE000
 4.441.781  **INT-6Dh*:ff37c410:00:00: *** ConnectWriteEDmac(0x5, 0x6)
 4.441.787  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F05014] <- 0x00000006
 4.441.808  **INT-6Dh*:ff37c424:ad:03: SetEDmac1 addr:0x4b9ee000
 4.441.866  **INT-6Dh*:ff37c4a0:00:00: *** RegisterEDmacCompleteCBR(0x1, 0xff37c05c "WriteEDmac3CompleteCBR[%x]", 0x777c4)
 4.441.880  **INT-6Dh*:ff0c7ba4:MMIO : [0xC0201010] <- 0x00000059
 4.441.882  **INT-6Dh*:ff0c7ba8:MMIO : [0xC0201200] -> 0x00000001
 4.441.935  **INT-6Dh*:ff37c4b4:00:00: *** SetEDmac(0x1, 0x4c20e000, 0x24bf14, 0x20000000)
 4.442.011  **INT-6Dh*:000c76ec:00:00:     size (600, skip 3240) x 439, 600, skip -1683120,
  (600, skip 3240) x 440
 4.442.028  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F0410C] <- 0x00000001
 4.442.031  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04110] <- 0x01B70258
 4.442.032  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04114] <- 0x00000258
 4.442.034  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04118] <- 0x00000CA8
 4.442.036  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F0411C] <- 0xFFE65150
 4.442.038  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04120] <- 0x00000CA8
 4.442.039  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04124] <- 0x00000000
 4.442.041  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04128] <- 0x00000000
 4.442.045  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F04104] <- 0x20000000
 4.442.047  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F04108] <- 0x0C20E000
 4.442.070  **INT-6Dh*:ff37c4c0:00:00: *** ConnectWriteEDmac(0x1, 0x4)
 4.442.076  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F05004] <- 0x00000004
 4.442.093  **INT-6Dh*:ff37c4d4:ad:03: SetEDmac3 addr:0x4c20e000
 4.442.148  **INT-6Dh*:ff37c4f8:00:00: *** RegisterEDmacCompleteCBR(0x9, 0xff37c09c "ReadEDmac1CompleteCBR[%x]", 0x777c4)
 4.442.163  **INT-6Dh*:ff0c7ba4:MMIO : [0xC0201010] <- 0x0000005E
 4.442.164  **INT-6Dh*:ff0c7ba8:MMIO : [0xC0201200] -> 0x00000001
 4.442.220  **INT-6Dh*:ff37c50c:00:00: *** SetEDmac(0x9, 0x4074e100, 0x24bf40, 0x40000001)
 4.442.255  **INT-6Dh*:000c76ec:00:00:     size ((600, skip -600) x 440) x 2
 4.442.271  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F0490C] <- 0x00000001
 4.442.273  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04910] <- 0x01B70258
 4.442.274  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04914] <- 0x00000258
 4.442.276  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04918] <- 0x0007FDA8
 4.442.278  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F0491C] <- 0xFFFFFDA8
 4.442.279  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04920] <- 0x0007FDA8
 4.442.281  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04924] <- 0x00000000
 4.442.283  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04928] <- 0x00000000
 4.442.287  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F04904] <- 0x40000001
 4.442.288  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F04908] <- 0x0074E100
 4.442.311  **INT-6Dh*:ff37c518:00:00: *** ConnectReadEDmac(0x9, 0x6)
 4.442.317  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F05038] <- 0x00000001
 4.442.339  **INT-6Dh*:ff37c524:00:00: *** ConnectReadEDmac(0x9, 0x7)
 4.442.344  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F0503C] <- 0x00000001
 4.442.401  **INT-6Dh*:ff37c548:00:00: *** RegisterEDmacCompleteCBR(0x8, 0xff37c0dc "ReadEDmac2CompleteCBR[%x]", 0x777c4)
 4.442.415  **INT-6Dh*:ff0c7ba4:MMIO : [0xC0201010] <- 0x0000005D
 4.442.417  **INT-6Dh*:ff0c7ba8:MMIO : [0xC0201200] -> 0x00000001
 4.442.462  **INT-6Dh*:ff37c560:00:00: *** SetEDmac(0x8, 0x4074e100, 0x24bf40, 0x1)
 4.442.496  **INT-6Dh*:000c76ec:00:00:     size ((600, skip -600) x 440) x 2
 4.442.511  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F0480C] <- 0x00000001
 4.442.514  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04810] <- 0x01B70258
 4.442.517  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04814] <- 0x00000258
 4.442.519  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04818] <- 0x0007FDA8
 4.442.521  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F0481C] <- 0xFFFFFDA8
 4.442.523  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04820] <- 0x0007FDA8
 4.442.525  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04824] <- 0x00000000
 4.442.526  **INT-6Dh*:ff2c2b88:MMIO : [0xC0F04828] <- 0x00000000
 4.442.530  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F04804] <- 0x00000001
 4.442.532  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F04808] <- 0x0074E100
 4.442.551  **INT-6Dh*:ff37c56c:00:00: *** ConnectReadEDmac(0x8, 0x3)
 4.442.556  **INT-6Dh*:ff2c29e8:MMIO : [0xC0F0502C] <- 0x00000000
 4.442.570  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11004] <- 0x00000001
 4.442.571  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11440] <- 0x00000000
 4.442.572  **INT-6Dh*:ff2c2d14:MMIO : [0xC0F11444] <- 0x00000001
 4.442.593  **INT-6Dh*:ff37c590:00:00: *** StartEDmac(0x5, 0x0)
 4.442.699  **INT-6Dh*:ff37c590:00:00:     addr b9ee000, ptr b9ee000, size (600, skip 3240) x 439, 600, skip -1683120,
  (600, skip 3240) x 440
.....
Look at

Code: [Select]

LV_StartTripleRamClearPassLR Width:600, Height:440, VW:3840 and

Code: [Select]

size (600, skip 3240) x 439, 600, skip -1683120,
  (600, skip 3240) x 440
These numbers are changing when toggling the Preview by using Info button, also some of 0xC0F04xnn registers have same values, then immediately I remembered a post in the past from a1ex, these kind of registers are filtered in adtg_gui, before capturing DebugMsg LOG I was trying to reduce black bars with no success, and no success mean something is missing, now the missing guys are shown in adtg_gui:

C0F04210
C0F04218

These two registers are related to each other, to shift box preview around and get different sizes of preview, when increase C0F04210 value you should decrease C0F04218 to get the correct preview size, e.g: on 700D in mv1080:

C0F04210 = 0x1b70a50
C0F04218 = 0x4b0

If you want to decrease preview size you should decrease C0F04210 e.g from 0x1b70a50 to 0x1b70950, now to fix the box preview you should increase C0F04218 from 0x4b0 to 0x5b0, Now LiveView are broken, you need to do other adjustments for the other registers (showed in the next experiment)

Registers between Canon Previews when pressing Info button in Movie Crop Mode:
Canon Previews HDMI in Movie Crop Mode

From above link Notice in full preview in Movie Crop Mode, C0F04210 = 1C70870 and C0F11590 = 0x1C70437

0x870  = 2160
0x437 = 1079

I noticed many times Canon are using doubled resolution size values in some of their resolution registers, if you want to tweak above registers you know now how to calculate it right, didn't play much with Vertical resolution values.

in mv1080 on Canon 700D toggling between the two preview using Info button also changes YUV resolution, to narrow the registers down I used Movie Crop Mode, this only changes Black Bars and the size of LiveView on HDMI without changing YUV resolution, I couldn't get a HDMI to USB capture card unfortunately there no capture card like that in my country, will get one from Ali Express but it will take months to arrive, so I used my smartphone for that, sorry and here is the Experiment:

HDMI Black Bars Experiment in Movie Crop Mode
Note: I put White tall papers on TV bezels to show HDMI black bars better.

Link:

Code: [Select]

https://youtu.be/PxDMVM48lDE
Results:

Movie Crop Mode full size Canon Preview:


Movie Crop Mode full size Canon Preview with tweaked registers:


Movie Crop Mode small size Canon Preview with tweaked registers:


Notice the offset between the last two images.
General note: You can also do some calculations for these values instead of trial and error method.

@reddeercity
Your turn on 5D2 Wondering how it would be on DIGIC 4 cameras.

Unfortunately I couldn't do it in mv1080 mode, the preview will still broken after tweaking same registers, there are a missing ones, didn't try too hard to find them.

Furthermore, please push it further and further

[Danne]

Thanks for interesting results. Speaking results. From what I understand you are still not able to achieve back the full live view real time preview window? Not even from x10 by tweaking regs? What you have is manipulating x5 cropped preview to x10 preview or from x10 zoom back to x5 crop still being in x10 crop?

[theBilalFakhouri]

From what I understand you are still not able to achieve back the full live view real time preview window? Not even from x10 by tweaking regs?

Yes, Unfortunately, I am missing some registers and the correct way to tweak it, x10 preview rely on x5 registers, we can't get more width than x5 in x10 Mode, We should look between mv1080 and x5 registers, and their is what we are looking for, I am trying narrow the registers down, also I noticed 4 registers not showing in adtg_gui but in DebugMsg LOGS, so a further investigating definitely needed, I hope if there some interested Developers would help too

What you have is manipulating x5 cropped preview to x10 preview or from x10 zoom back to x5 crop still being in x10 crop?

Didn't fully get you, I can get x5 to x10 while being in x5 or x10, or x10 to x5 while being in x5 or x10, LiveView doesn't freeze at all with default registers between x5 mode and x10 mode, at least on 700D

[theBilalFakhouri]

After commented out filtered registers, and with io_trace defined in adtg_gui, I can now fully patch Movie Crop Mode into x5 Mode with working LiveView and valid RAW data, previously wasn't possible, Actually this is the first successful attempt to patch Canon preview from Mode to another Mode

[ArcziPL]

Great work theBilalFakhouri!

[2blackbar]

Great news !
In theory Do You think it would be possible to stay in non copped mode realtime preview and record RAW cropped x5 ?

[Danne]

Great news !
In theory Do You think it would be possible to stay in non copped mode realtime preview and record RAW cropped x5 ?

In a theoretical dream maybe  . Never say never  .

[yourboylloyd]

Do You think it would be possible to stay in non copped mode realtime preview and record RAW cropped x5 ?

Wow that would be awesome. Then all we would have to do is add black crop bars or something

[theBilalFakhouri]

Thanks @ArcziPL

@2blackbar
I think it's greatly possible, some knowledge is required, Simple reason: on 700D LiveView can process already 1736x1160 Pixels x 40FPS in LiveView = ~80 MegaPixles per second, in x5 Mode 2520x1080 x 24FPS = only ~65 MegaPixels less than what LiveView can already process.

@yourboylloyd
Black bars could be achieved also from Canon registers after we know how to control them, even without enabling ML global draw.

In general I am aware of an overhead could happen and affects write speeds, too early to talk about these . .

for Now I might be narrowed down what's exactly control the region of cropped area in x5, but still can't control all of them properly, there is a limit, and a lot of complicated things togather, and I am preparing Clean LOGs for what Canon is doing when switching from video mode to another one, I want to know what prevents the fully patch of mv720 into mv1080 vice versa, this might lead us to something.

[Teamsleepkid]

Anything working on eos m? I think this is what I’ve been dreaming about for like 2 years... it’s real live view in real time right? The choppy preview live view that shows the framing is all we have now. Or real live view with the wrong framing. If this is real live view with correct framing you’ll be the hero of all time:)

[reddeercity]

@theBilalFakhouri , tried those reg's on the 5d2 and there no joy they do different things
But did find Reg "C0F11308" stretches or shrinks the HDMI Liveview Vertcially ,
Would be good for 3x1 or 1x3 modes

[theBilalFakhouri]

Promising results, but not proof of concept:

Link:

Code: [Select]

https://youtu.be/UUZ2Lu4MYu4
Preview Before


Preview After

- Both RAW data and Preview are centered, the Camera was fixed on the Tripode.

I got the idea after the successful attempt for patching MCM into x5 Mode, the experiment tells us we can process more than 1032x639 in x5 Mode but if we took the Preview registers from MCM or mv1080, Before, I tried pretty hard for increasing the processed RAW area in YUV and made accurate calculator for the registers between x5 and mv1080, no luck when using it for increasing or decreasing processed RAW area in YUV properly in x5, Still experimenting more things.

So, I patched all mv1080 registers into x5 mode, LiveView is frozen but you can see what's happening even if it was frozen, in Preview there are two YUV Paths:

1- HD YUV path This is what process RAW data directly to YUV in different resolutions
2- LV YUV path This takes the already processed YUV from HD path and down scale it to fit on the LCD screen properly to 720x480 or 1080 if you using external monitor

When LiveView is stuck, the LV YUV path is the frozen one, fortunately HD YUV path is still working, Cool! , So is it possible to add a real-time Preview for HD YUV path to see the changes?

Well, Yes, actually there is one already implemented in your ML build: Defishing Preview , a1ex did mention that to me:

Maybe the live defishing preview code could be useful - iirc, it takes an image from the YUV buffer (aka HD), distorts it and displays it on the main image preview buffer (aka LV).

Huge thanks to him

Unfortunately defishing preview requires global draw to be ON, in x5 there is no Global Draw, unless you turn on RAW video, yes I missed that one

Yeah, if you also enable raw video.

General notes:
1- False colors also using data from HD YUV path
2- If we succeed to expand cropped preview area in YUV HD path, we can use it, ignore the frozen LiveView, first step is YUV HD path
3- YUV HD resolution and other preview registers are working together for Preview region
4- Defishing preview is nearly real-time, a bit choppy

Back to the Experiment:
So I patched mv1080 into x5 Mode, YUV HD path is working, LiveView is frozen, I increased RAW Width resolution above 1736, at some point the LiveView was back to work again and not frozen anymore, fixed scrambled LiveView with C0F38024, Maximum RAW width resolution with wokring LiveView is 2336x1162 (Edit: also C0F08188, C0F08194, C0F08198, C0F0434 I kept its values same as x5 Mode)

-Both RAW data and Preview are centered and you can see that from the video above, centering RAW data done by CMOS registers, centering Preview by C0F383DC, C0F383D4.

-Full height of RAW data is being processed which is 1162, only 1736 of Width is being processed

-You can increase Width res more than 2336 and fix it by C0F38024, but you have to use YUV HD preview, LiveView will be frozen, and I didn't test it if it would crash after some time.

-I will try if I would have luck for increasing region preview area registers in x5 mode with patched mv1080 in x5.

See you in the next experiments.

[yourboylloyd]

This is so exciting! Keep experimenting please!!!!

[Danne]

Good work bilal. Getting close.

[ZEEK]

Very interesting work done here, well done👍

[theBilalFakhouri]

Aaaand Here we go, continuing from my last Experiment, here the first Proof of Concept:

Before: Processing 1736x1162 of RAW data In LiveView:


After: Processing 2064x1162 of RAW data In LiveView:


P.S: 2064 Width is pre calculated (I made a calculator, mentioned that in the previous post), no trial and error method was used

-LiveView is working
-The 2064 looks compressed Horizontally in LiveView, I de-squeezed it for showing the above example correctly.

Details are coming, please be patient

[Danne]

Haha. Magician.

[2blackbar]

Fantastic work !

[Grognard]

Is it first april of this year?

Amazing work!

[theBilalFakhouri]

Expanding Preview in x5 Mode is working, patching mv1080 in x5 is no longer needed, and I am not saying anything:

Link:

Code: [Select]

https://youtu.be/kOylUBjPGyg
ML Framing in x5 Mode (2520x1080)


Expanded Canon Preview in x5 (also 2520x1080) Mode with ML Anamorphic squeezing for more accurate aspect ratio:


Limitations
1- Black Bar on the right, increasing Preview region registers aren't helping, new limit has arrived, will investigate into it. (Click!)
2- Pinkish image in the bottom-half of Preview (this might be easy to fix) Edit: Fixed.
3- The full 1080 height isn't showing, a bit cut in the bottom Edit: Fixed.

-Could this be used for Framing?
-Yes.. kind of, you can set your imagination in the right instead of the black bar, or if it possible, we might get the missing part (black bar) from ML Framing, and have two previews working togather.

-Details are coming . . just want to double check values and other things.

@Grognard
I am feeling happy with throwing things before 1st April

[Danne]

I like this!

[Levas]

Wow, respect 

[theBilalFakhouri]

Reducing x5 Cropped Area Experiment Part II

I thought before the cropped area is controlled by few registers, maybe only maximum of five registers, however here is the full list of registers that controls the Preview region:

Code: [Select]

C0F11B9C
C0F1A00C
C0F118DC
C0F118E4

C0F3B0DC
C0F3B074
C0F3B070
C0F3B054
C0F3A0B0
C0F3A0A0
C0F3A04C
C0F389EC
C0F389E4
C0F389D4
C0F389B4
C0F389A4
C0F38960
C0F38934
C0F380A4
C0F380A0
C0F38094
C0F38084
C0F38080
C0F3807C
C0F38078
C0F38070

C0F383DC
C0F383D4
C0F38024

C0F42194
C0F4204C
C0F42014
In addition to Stretching registers, for Horizontal: C0F11B8C , for Vertical: C0F11ACC.

Skipped Registers:

Code: [Select]

C0F04110

C0F11B98
C0F11BDC
C0F11A9C

C0F2C01C
C0F2C054
C0F2C0C0
C0F2C0B8
Reason: I didn't like them.

Real Reason: These the registers which are changing between Idle mv1080 and H.264 recording from 960x639 to 1728x1151, Apparently which control the Up-Scaling or Down-Scaling of YUV HD path, but not the Preview region, In all of my first experiments (behind the scenes) I was starting by tweaking these ones, Increasing YUV HD buffer, I thought this is required step to fit the increased processed RAW data,

However I calculated all the values of all previous registers, and pretty sure it was right, but ended up with Un-fixable LiveView, even when decreasing the preview region (in this case I won't face limitations), then I got the thought maybe we don't need to play with YUV HD buffer size, I skipped these registers, I used same calculated values, and I could fix the LiveView after tweaking the rest of above registers,

After that I tweaked Horizontal stretching register, There was a data to show, I said WOW, it's Working! in Arabic.

Understanding the Values:

Simply, Preview region registers is resolution values, what's the resolution of RAW data you want to process in YUV HD path, That's it, e.g:

Let's take C0F11B9C as example:

in mv1080 processed RAW data in Preview is 1728x1151: C0F11B9C = 0x47F06BF:
0x47F = 1151
0x6BF = 1727  (Horizontal Resolution - 1 )

in x5 processed RAW data in Preview is 1032x687: C0F11B9C = 0x2AF0407:
0x2AF = 687
0x407 = 1031  (Horizontal Resolution - 1 )

In this example you can see the Horizontal values is mines one, an the accurate way for knowing what is the processed RAW data in Preview is from YUV HD buffer size which is C0F04110, in x5 Mode C0F04110 = 0x2AF0810:
0x2AF = 687
0x810 = 2064 Because Canon is using doubled value in this register, divide it by 2 = 1032

From H.264 mv1080 C0F04110 = 0x47F0D80
0x47F = 1151
0xD80 = 3456, divide by 2 = 1728

Other Preview registers have also minor difference in values, some of them the Horizontal resolution is divided by 4, so I calculated all the differences for all Preview region registers and made this calculator:

The Code of the Calculator I used:

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

 //   **Don't use it: These registers are used for upscaling/downscaling YUV HD path,
 // You can see them changing between Idle mv1080 and while recording H.264 from 960x639 to 1728x1151,
 // It's not required for Expanding processed region area in YUV HD path, if you used it you will end up with un-fiyble Preview

 // That's what was puzzling me, so if you want to to increase Preview region you should calculate it from RAW resolution,
 // in mv1080 on 700D, processed RAW data in LiveView is 1728x1151,type these values in x,y and you will get same set of registers values
 // in camera,

 // Except for registers mentioned with ** , in x5 Mode there is no upscaling/downscaling YUV HD path, it's constant 1032x687, but even
 // if you used ** registers you will end up with un-fixable Preview, not sure why, so we are keeping YUV container (Buffer) as it is, but
 // Changing the Processed region area from the rest of registers, after increasing it you may use stretching Horizontal YUV register
 // which is C0F11B8C, for Height stretching you should use C0F11ACC,I used x=2520, y=687, Yes I didn't touch the height, and I could
 // Expand it, but with pinkish color, If set y=1080 I will able to restore image color, but with not correct order in the bottom part
 // of the Expanded height.

int main()
{
    int x, y;

    x = 2520*2;  /* YUV Horizontal , Multiplied by 2 because of C0F04110 which is using doubled value */
    y = 687;    /* YUV Vertical */

    /* C0F0 */
    printf("case 0x4110: return 0x%X%X;\n\n", y , x);             //YUV Buffer Size **Don't use it

    /* C0F1 */
    printf("case 0x1B98: return 0x%X;\n", x / 2 -1);                //**Don't use it
    printf("case 0x1BDC: return 0x%X0%X;\n", y , x / 2 -1);        //**Don't use it
    printf("case 0x1A9C: return 0x%X0%X;\n\n", y , x / 2 -1);      //**Don't use it

    printf("case 0x1B9C: return 0x%X0%X;\n", y , x / 2 -1);
    printf("case 0xA00C: return 0x%X0%X;\n", y , x / 2 -1);
    printf("case 0x18DC: return 0x%X0%X;\n", y , x / 2 -1);
    printf("case 0x18E4: return 0x%X0%X;\n\n", y , x / 2 -1);

    printf("case 0x1984: return 0x%X0%X;\n", y , x / 2 - 1);      //Not used in x5 Mode
    printf("case 0x197C: return 0x%X0%X;\n\n", y , x / 2 - 1);    //Not used in x5 Mode

    /* C0F2 */
    printf("case 0xC01C: return 0x%X0%X;\n", y + 1 , x / 2 -1);   //**Don't use it
    printf("case 0xC054: return 0x%X0%X;\n", y + 2 , x / 2 +16);  //**Don't use it
    printf("case 0xC0C0: return 0x%X0000;\n", x / 2 + 2);          //**Don't use it
    printf("case 0xC0B8: return 0x%X0000;\n\n", y + 1);            //**Don't use it

    /* C0F3 */
    printf("case 0xB0DC: return 0x%X0%X;\n", y , x / 2 + 0x4F);
    printf("case 0xB074: return 0x%X0%X;\n", y , x / 2 + 0x57);
    printf("case 0xB070: return 0x%X0%X;\n", y + 6 , x / 2 + 0x57);
    printf("case 0xB054: return 0x%X0%X;\n", y + 6 , x / 2 + 7);
    printf("case 0xA0B0: return 0x%X0%X;\n", y +10 , x / 2 + 8);
    printf("case 0xA0A0: return 0x%X0%X;\n", y +10 , x / 2 + 11);
    printf("case 0xA04C: return 0x%X0%X;\n", y +6 , x / 2 / 4 + 5);
    printf("case 0x89EC: return 0x%X0001;\n",  x / 2 / 4 + 6);
    printf("case 0x89E4: return 0x%X0%X;\n", y +7 , x / 2 / 4 + 7);
    printf("case 0x89D4: return 0x%X0%X;\n", y +6 , x / 2 / 4 + 5);
    printf("case 0x89B4: return 0x%X0%X;\n", y +7 , x / 2 / 4 + 6);
    printf("case 0x89A4: return 0x%X0%X;\n", y +6 , x / 2 / 4 + 5);
    printf("case 0x8960: return 0x%X0000;\n",  y + 6);
    printf("case 0x8934: return 0x%X0%X;\n", y +6 , x / 2 / 4 + 5);
    printf("case 0x80A4: return 0x%X0000;\n",  x /2 / 4 + 7);
    printf("case 0x80A0: return 0x%X0000;\n",  x /2 / 4 + 7);
    printf("case 0x8094: return 0x%X0000;\n",  y + 10);
    printf("case 0x8084: return 0x%X0000;\n",  x /2 / 4 + 7);
    printf("case 0x8080: return 0x%X0002;\n",  y  + 7);
    printf("case 0x807C: return 0x%X0000;\n",  x /2 / 4 + 5);
    printf("case 0x8078: return 0x%X0001;\n",  x /2 / 4 + 6);
    printf("case 0x8070: return 0x%X0%X;\n\n", y +9 , x / 2 / 4 + 5);

    printf("case 0x83DC: return 0x%X0%X;\n", y + 0x27 , x / 2 / 4 + 0x12);      /* Only Horizontal value is accurate, don't take the Vertical */

    /* C0F4 */
    printf("\n");
    printf("case 0x2194: return 0x%X;\n",  x / 2 / 4 + 5);
    printf("case 0x204C: return 0x%X0%X;\n", y +9 , x / 2 / 4 + 5);
    printf("case 0x2014: return 0x%X0%X;\n\n\n", y +9 , x / 2 / 4 + 5);

    return 0;
}
All values are calculated from YUV HD buffer size (C0F04110), change x (keep *2) and y and run the program, I am using codeblocks, you may try 1728x1151 and 1032x687 and compare the results from your camera

For the values I used in Expanding x5 Experiment is (x = 2520*2;) and (y = 687;), Yes I kept y resolution 687. and I could expand the height, however with pinkish color, if I set y to 1080, I can get correct image colors, and also a bit more height area maybe the full height of 1080, but order of the bottom half of expanded height will be in the wrong order, there is an offset.

-The calculator output is designed to use it in adtg_gui as preset.

Here is all the values on 700D I used from adtg_gui:

Code: [Select]

static int YUV_reg(int reg)
{

if (regs[reg].dst == 0xC0F0)
    {
        switch (regs[reg].reg)
        {

//case 0x4110: return 0x47F1230;

        }
    }

if (regs[reg].dst == 0xC0F1)
    {
        switch (regs[reg].reg)
        {

        //case 0x1B8C: return 0x5005;

        //case 0x1B98: return 0x917;
       //case 0x1BDC: return 0x47F0917;
      //case 0x1A9C: return 0x47F0917;
        case 0x1B9C: return 0x2AF09D7;
        case 0xA00C: return 0x2AF09D7;
        case 0x18DC: return 0x2AF09D7;
        case 0x18E4: return 0x2AF09D7;

        case 0x1B8C: return 0x5000C;
        case 0x1ACC: return 0x1E003C;

        }
    }

    if (regs[reg].dst == 0xC0F2)
    {
        switch (regs[reg].reg)
        {
           
        //case 0xC01C: return 0x4800917;
        //case 0xC054: return 0x4810928;
        //case 0xC0C0: return 0x91A0000;
        //case 0xC0B8: return 0x4800000;
        }
    }

    if (regs[reg].dst == 0xC0F3)
    {
        switch (regs[reg].reg)
        {

        case 0xB0DC: return 0x2AF0A27;
        case 0xB074: return 0x2AF0A2F;
        case 0xB070: return 0x2B50A2F;
        case 0xB054: return 0x2B509DF;
        case 0xA0B0: return 0x2B909E0;
        case 0xA0A0: return 0x2B909E3;
        case 0xA04C: return 0x2B5027B;
        case 0x89EC: return 0x27C0001;
        case 0x89E4: return 0x2B6027D;
        case 0x89D4: return 0x2B5027B;
        case 0x89B4: return 0x2B6027C;
        case 0x89A4: return 0x2B5027B;
        case 0x8960: return 0x2B50000;
        case 0x8934: return 0x2B5027B;
        case 0x80A4: return 0x27D0000;
        case 0x80A0: return 0x27D0000;
        case 0x8094: return 0x2B90000;
        case 0x8084: return 0x27D0000;
        case 0x8080: return 0x2B60002;
        case 0x807C: return 0x27B0000;
        case 0x8078: return 0x27C0001;
        case 0x8070: return 0x2B8027B;

case 0x83D4: return 0x2B000C;
case 0x83DC: return 0x40C0288;

        }
    }

    if (regs[reg].dst == 0xC0F4)
    {
        switch (regs[reg].reg)
        {

        case 0x2194: return 0x27B;
        case 0x204C: return 0x2B8027B;
        case 0x2014: return 0x2B8027B;

        }
    }

    return 0;
}
Last thing, after you use above registers and apply them, you will end up with frozen LiveView, tweak these two registers manually:

C0F383DC (Increase Width resolution in this register to fix frozen LiveView, or take Horizontal resolution value from the Calculator above, don't take Vertical value it's not accurate in the calculator)

C0F383D4 (Fix broken LiveView with this)

Then use Stretching registers to show the new data:
for Horizontal: C0F11B8C , for Vertical: C0F11ACC

These method works in x5 Mode, didn't test it in other modes, you may end up with camera crash in mv1080).

-Use Defishing preview when LiveView is frozen.
-It might be some differences in other cameras, 5D3 doesn't share the same set of registers.

I will shoot a video showing the Experiment.

[theBilalFakhouri]

Limitations
2- Pinkish image in the bottom-half of Preview (this might be easy to fix)

Fixed.

[theBilalFakhouri]

Expanded Canon Preview in x5 (also 2520x1080) Mode with ML Anamorphic squeezing for more accurate aspect ratio:

ML Anamorphic is no longer needed to fix the aspect ratio, you can use the new Preview option with ML Global Draw off and with correct aspect ratio.
Correcting aspect ratio was done by Canon registers, That means there wouldn't be any overhead, and the Preview will be just responsive as 1080p mode, before it was a bit choppy in Idle, and a lot choppy when recording, details are coming.