These LiveView Crop Registers (https://www.magiclantern.fm/forum/index.php?topic=24288.0) and Screen/LiveView/HDMI resolutions (https://www.magiclantern.fm/forum/index.php?topic=25222.0) 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 Registers2-
YUV Resolution3-
HDMI Black BarsLet's start investigating:
LiveView Crop Registers
From LiveView Crop Registers (https://www.magiclantern.fm/forum/index.php?topic=24288.0) 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 (https://docs.google.com/spreadsheets/d/1-3PlMmQHfUx7fh_u61p4v2O9rmP0madKaQjlkGWsBdo/edit#gid=0)
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 Registers2-
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:
(https://i.ibb.co/sKDRS2T/Default-x5-View.png) (https://imgbb.com/)
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:
(https://i.ibb.co/mNPLDqM/C0-F11-A8-C-to-0x1-E003-B.png) (https://imgbb.com/)
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:
(https://i.ibb.co/ggmtCsK/C0-F11-A8-C-to-0x1-E001-B.png) (https://imgbb.com/)
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 0x
1E00
2B, 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 = 0x1E00
2B, tweaking it to 0x1E00
3B will show the signal loss, but after tweaking C0F11A88 from 0x0 to 0x1 in x5 Mode, Now tweaking C0F11A8C to 0x1E00
3B 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:
(https://i.ibb.co/j6RNCN8/Default-x5.png) (https://imgbb.com/)
Tweaking C0F11ACC to 0x1E001B in x5 Mode:
(https://i.ibb.co/2F0JRVq/C0-F11-ACC-to-0x1-E001-B-in-x5-Mode.png) (https://imgbb.com/)
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:
https://www.youtube.com/watch?v=cK_A-4tvskY
Link:
youtu.be/cK_A-4tvskYResults:
Default x10 Mode:
(https://i.ibb.co/m6f8rPk/Default-x10-Mode.png) (https://imgbb.com/)
Default x5 Mode:
(https://i.ibb.co/cvsKcCk/Default-x5-Mode.png) (https://imgbb.com/)
Reduced Cropped Area in x10 Mode
(https://i.ibb.co/bgGWqsC/Reduced-Cropped-Area-in-x10-Mode.png) (https://imgbb.com/)
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)
https://youtu.be/gmU6_GknchI
Link:
https://youtu.be/gmU6_GknchI2-
Reducing x5 Cropped Area Experiment: :D
https://youtu.be/BmSU0dOVDtw
3- Some registers with 0x80
XX00
XX 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 . .
Quote from: a1ex on September 23, 2018, 10:54:22 AM
c0f04xnn: EDMAC channel "x", filtered out
He is filtering our registers out of adtg_gui :( , commented out these Lines :P:
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:
(https://i.ibb.co/hMcPjH5/Idle-960x639-YUV.png) (https://imgbb.com/)
When you start H.264 recording it changes to
1728x1151 on
700D, interesting:
(https://i.ibb.co/2cwf5Gz/Mv1080-H-264-YUV.png) (https://imgbb.com/)
When you start H.264 recording in mv720 it changes to
1280x689 (https://i.ibb.co/y6JCtVm/Mv720-H-264-YUV.png) (https://imgbb.com/)
Now using adtg_gui between Idle and H.264 recording we can Identify these registers:
Craw Buffer Changing (https://docs.google.com/spreadsheets/d/1gOngXH_OgtRRnsQ7VfQ7dHjJOSB1AEpNjkeU1ql5c8s/)
Increasing YUV resolution Experiment in mv720https://youtu.be/ESKSDLcywzU
Link:
https://youtu.be/ESKSDLcywzUDownload Dumped YUV files (https://drive.google.com/drive/folders/1oLGSaGJfOYMn-whPSg8Y7W9vRKAK_vuS?usp=sharing) Also included 422ToImage 1.9.2 (https://www.magiclantern.fm/forum/index.php?topic=3310.0), 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:
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
LV_StartTripleRamClearPassLR Width:600, Height:440, VW:3840 and
size (600, skip 3240) x 439, 600, skip -1683120,
(600, skip 3240) x 440These 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 (https://docs.google.com/spreadsheets/d/1uUWkht0LqCpv45-oj8F8C2tFZLGVrhEmhm8XaosCVXk/edit#gid=0)
From above link Notice in full preview in Movie Crop Mode, C0F04210 = 1C70
870 and C0F11590 = 0x1C70
4370x870 = 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 ModeNote: I put White tall papers on TV bezels to show HDMI black bars better.
https://youtu.be/PxDMVM48lDE
Link:
https://youtu.be/PxDMVM48lDEResults:
Movie Crop Mode full size Canon Preview:
(https://i.ibb.co/WBcmckz/Movie-Crop-Mode-full-size-Canon-Preview.png) (https://imgbb.com/)
Movie Crop Mode full size Canon Preview with tweaked registers:
(https://i.ibb.co/6nM81Wq/Movie-Crop-Mode-full-size-Canon-Preview-Tweaked-Registers.png) (https://imgbb.com/)
Movie Crop Mode small size Canon Preview with tweaked registers:
(https://i.ibb.co/qpfFVNq/Movie-Crop-Mode-small-size-Canon-Preview-Tweaked-Registers.png) (https://imgbb.com/)
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 :D 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 :)
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?
Quote from: Danne on August 27, 2020, 12:20:34 PM
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
Quote from: Danne on August 27, 2020, 12:20:34 PM
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
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 :D
Great work theBilalFakhouri!
Great news !
In theory Do You think it would be possible to stay in non copped mode realtime preview and record RAW cropped x5 ?
Quote from: 2blackbar on August 29, 2020, 10:28:14 AM
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 :P. Never say never 8).
Quote from: 2blackbar on August 29, 2020, 10:28:14 AM
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
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.
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:)
@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
Promising results, but
not proof of concept:
https://youtu.be/UUZ2Lu4MYu4
Link:
https://youtu.be/UUZ2Lu4MYu4Preview Before(https://i.ibb.co/hyF1cT7/Normal-x5-Preview.png) (https://imgbb.com/)
Preview After(https://i.ibb.co/6WVjDwh/Mv1080-into-x5.png) (https://imgbb.com/)
- 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 (https://www.magiclantern.fm/forum/index.php?topic=25287.msg230190#msg230190), 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 :D , a1ex did mention that to me:
Quote from: a1ex on September 01, 2020, 10:09:20 AM
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 :D
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
Quote from: a1ex on September 04, 2020, 08:32:03 AM
Yeah, if you also enable raw video.
:P
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.
This is so exciting! Keep experimenting please!!!!
Good work bilal. Getting close.
Very interesting work done here, well done👍
Aaaand Here we go, continuing from my last Experiment, here the first Proof of Concept:
Before: Processing 1736x1162 of RAW data In LiveView:
(https://i.ibb.co/9WckFKF/Before-1736x1162.png) (https://imgbb.com/)
After: Processing 2064x1162 of RAW data In LiveView:
(https://i.ibb.co/BGKJLPH/2064-PoC.png) (https://ibb.co/9h30nvm)
P.S: 2064 Width is pre calculated (I made a calculator, mentioned that in the previous post), no trial and error method was used :D
-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 ;D
Haha. Magician.
Fantastic work !
Is it first april of this year?
Amazing work!
Expanding Preview in x5 Mode is working, patching mv1080 in x5 is no longer needed, and I am not saying anything:
https://youtu.be/kOylUBjPGyg
Link:
https://youtu.be/kOylUBjPGyg
ML Framing in x5 Mode (2520x1080)
(https://i.ibb.co/3W6WpD5/ML-Preview-x5-2520x1080.jpg) (https://ibb.co/ctft6GK)
Expanded Canon Preview in x5 (also 2520x1080) Mode with ML Anamorphic squeezing for more accurate aspect ratio:
(https://i.ibb.co/kgpXhKg/X5-Mode-with-Expaned-Canon-Preview.jpg) (https://ibb.co/QFZM69F)
Limitations
1- Black Bar on the right, increasing Preview region registers aren't helping, new limit has arrived, will investigate into it. (Click (https://www.magiclantern.fm/forum/index.php?topic=25287.msg242356#msg242356)!)
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 :P
I like this!
Wow, respect 8)
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:
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:
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:
#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 :P
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:
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.
Quote from: theBilalFakhouri on September 05, 2020, 06:38:03 PM
Limitations
2- Pinkish image in the bottom-half of Preview (this might be easy to fix)
Fixed.
Quote from: theBilalFakhouri on September 05, 2020, 06:38:03 PM
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.
Legend 👏
Thank you Bilal, you are a wizard! Realtime preview without global draw it's crasy. You gave a big boost with sd overclock and now realtime preview!
Will it be possible to have good ratio for 1×3 mode too? Porting on EOS m should be easy but on 5diii and 5dii more work to do.
How can I test this on the 5DIII ?
I have firmware 1.13 and I can compile ML myself, at least for 5DIII. Is there a repo somewhere where I can download a file, or did you just go with atgd gui ?
Well, all said: is there something implemented already ?
Quote from: theBilalFakhouri on September 05, 2020, 06:38:03 PM
3- The full 1080 height isn't showing, a bit cut in the bottom Edit: Fixed.
Narrowed down this mother f*cker and fixed it.
Quote from: ZEEK on September 06, 2020, 11:41:10 PM
Legend 👏
Glad you are following this development :D
Quote from: Grognard on September 07, 2020, 11:02:54 AM
Thank you Bilal, you are a wizard! Realtime preview without global draw it's crasy. You gave a big boost with sd overclock and now realtime preview!
You're welcome! , Thanks, I thought enhanced sd_uhs and real-time correct preview is the two last thing we could get on DIGIC 5 Canon cameras, a new ML decade has started for newer cameras, I don't think any of main Developers would work on DIGIC 5 cameras again, just a thought . .
Quote from: Grognard on September 07, 2020, 11:02:54 AM
Will it be possible to have good ratio for 1×3 mode too? Porting on EOS m should be easy but on 5diii and 5dii more work to do.
For 1x3 mode In theory it's possible, but more knowledge is required, I am working on it, EOS M shares identical registers and values, I sent same preset to @Danne and Confirmed it's working, 5D3 have different set of registers, it might be easy to port if we the effects of registers were the same, I don't have the camera I can't work on it, Sorry . . 5D2 is another story, and might be simpler.
Quote from: GullRaDriel on September 07, 2020, 06:57:59 PM
How can I test this on the 5DIII ?
I have firmware 1.13 and I can compile ML myself, at least for 5DIII. Is there a repo somewhere where I can download a file, or did you just go with atgd gui ?
Well, all said: is there something implemented already ?
There is nothing for 5D3, Sorry, No one has worked on it yet, I can't work on it too because I don't have the camera.
Quote from: Teamsleepkid on September 02, 2020, 10:38:23 PM
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:)
Already working on EOS M, no available build yet, It's Real-Time Correct Framing, real-time as Canon Preview, correct Framing as ML Framing, both in one, you are welcome.
Quote from: yourboylloyd on September 05, 2020, 06:53:53 AM
This is so exciting! Keep experimenting please!!!!
And it gets more and more exciting :D
RAW data compared to Normal x5 Preview and the new Expanded Preview:
(https://i.ibb.co/3FdsrpY/New-Expanded-Preview.gif)
-These three images are dumped from the Camera.
-The new Expanded Preview is in real-time and responsive as normal 1080p.
-Aspect ratio is correct in LiveView for The new Expanded Preview, no need to enable ML Global Draw.
-Framing is correct if you consider there will be data in the Black Bar on the right.
-No overhead or slowness.
-Works on external HDMI monitor too.
-Only working for 700D and *EOS M (*Confirmed by Danne) for now . . unless someone work on other cameras.
-Last limit of this preview is the Black Bar in the right, still working on it.
Releasing soon for testers.
Jedi skills man 8).
Wowwwww. This is crazy!
Woow! 8) :o
I'm available for testing on 700D
very exciting news, great work
This is amazing
Thanks for your reply bilal can't wait to test. Thanks for this. I'm sure everyone is very excited:)
This is Incredible! What you've already achieved is a huge leap from the preview possible with Canon's 5x crop.
2.5K mode will be the real king and the EOS M will reach its perfection after this.
Thanks @theBilalFakhouri
Test Builds are out for 700D, and *EOS M (*Thanks Danne), You will find it on the new thread:
Experimental Real-Time Correct Framing Preview (https://www.magiclantern.fm/forum/index.php?topic=25323.msg230688;topicseen#msg230688)
-Let's keep this thread for development, and move on to the new thread (https://www.magiclantern.fm/forum/index.php?topic=25323.msg230688;topicseen#msg230688) for sharing thoughts and community discussions.
-Thanks all for your words.
Does this liveview resolution change mean you can record 2.5k in h.264 ? What happens when you disable raw video and hit the record button, how does the canon mov file look.
Just curious :D
(Since raw is way too good to go back to h.264 compression :P )
Canon mov file looks...*drum roll'...................like shit! ;D.
Are you talking about 2.5k liveview or not? Because Canon mov files always looks like shit ;D
Compared to raw that is 8)
Not working to record when in x5zoom.
First we need to patch x5 Mode into mv1080, then apply the new preset, then use YUV Upscaling/Downscaling registers to make YUV resolution as mv1080, after that we should try Hitting the record button and see what H.264 file look like :D
However patching x5 Mode isn't working, we can baypass patching and adjusting YUV res, instead of that we can patch mv1080 to 1:1 by Using ADTG[800C] and CMOS 5, then increasing RAW data, fixing LiveView, Increasing Preview region, Hitting record button, But also fixing LiveView after increasing RAW data in mv1080 isn't working :D
Yes, or modify movie crop mode. The holy shortcut ;).
Movie Crop Mode has 720x404 16:9 AR YUV image with black borders in top and bottom, otherwise x5 Mode and mv1080 has 720x480 YUV 3:2 AR, without the black borders, I didn't study MCM yet, this might help us to center the x5 new preview on screen, there is register controls black borders natively from Canon starting from the right and from the bottom, but has no effect in x5 Mode: C0F08554
It works, thank you Bilal. But it's difficult to keep concentration on the screen with the stuck frame bug or the white noise in the bottom.
I've found a little trick to keep the black bar in the bottom screen by pressing menu button untile the black screen appear then quickly toggle to framing mode by pressing focus button.
We can also toggle in photo mode and quickly go back in video mode.
I also notticed that if we reduce resolution, in 2,5k mode, the preview is still the same and then larger than the correct frame. It's better than the otherwise!
@Grognard
Black bars could be added from mlv_lite, using ML Global Draw, it's very easy task and doable, this is still very new stuff, I might add them in the future, glad you liked it :)
Regards,
-My notes for 5D3 (where to start looking):
-I have started looking in my 700D between x5 and x10 modes, and identify cropping registers by using adtg_gui module. On 5D3 I couldn't see registers between x5 and x10 mode, a1ex has mentioned that cropping is happening using Eeko core (second core for DIGIC 5). adtg_gui won't help here.
So in this case you need to capture DebugMsg log from 5D3, between x5 and x10 mode. And look for the functions which being called, try to identify which one crops the image.
Try for example do x15 cropping instead of x10 using the discovered functions, maybe play with some registers related to cropping if you found any.
Cropping functions/registers between x5 and x10 might not be needed, because it might help with only increasing the cropped area, not decreasing it. If it were required to decrease cropping then understanding it would be important.
-Compare 1080p mode against 720p. adtg_gui would show registers between the two modes. try to understand the registers and identify its effect.
in 1080p mode 1920x1280 RAW data is being processed in LiveView
in 720p mode 1920x648 RAW data is being processed in LiveView
From 720p mode set Binning mode to 3x3, increase RAW data to 1920x1280 (using adtg_gui, take the values from 1080p mode), no you will have stretched LiveView as in 1x3 mode in 5D3, try to recover the cropped part (bottom part of the frame) from your the registers you have found out (I couldn't do it on 700D, LiveView freezes).
-Compare 1080p mode vs x5 mode, a lot of registers would presented here, probably a part of these presented registers are all of what you need. Well, you need to figure out how they work togather.
-Try to identify YUV scaling registers, e.g.
In 720p RAW data would be down scaled from 1920x648 to 1280x720 in LiveView (YUV HD stream).
In 1080p 1920x1280 RAW data is being down scaled to 1904x1151
In LiveView Photo mode 1920x1280 RAW data is being down scaled to 1620x1080, in this case capture DebugMsg log between LiveView photo mode and 1080p mode, this way you might identify YUV scaling registers (on 700D I skipped these registers, doesn't help with increasing processed RAW data in LiveView).
-No idea if there other easier way, probably looking into *SetVram/ClearVram functions (in ROM1.BIN using Ghidra) in different LiveView modes. comparing them might help.
-*on 700D all preview registers are being set after calling SetVramPath (each video mode has its own SetVramPath, see strings in ROM).
-Probably most important thing is to LOG Eeko core activity, as far as I know we don't log its activity currently, would be there new range of registers? no idea.
-I think on 700D Eeko is being used too (not as much as 5D3), e.g. for centering YUV paths on screen, look at this experiment (https://www.magiclantern.fm/forum/index.php?topic=25287.msg230190#msg230190), in that experiment preview was showing in the top of screen, not centered, even though I applied patched all registers from movie crop mode to x5 mode using adtg_gui.
-Problem: lowering RAW video resolution in various movie movie mode will freeze LiveView and the camera will crash after some seconds.
-Preventing the crash: I discovered two ways:
1- by Calling ClearVramPath, this will clear both YUV LV and HD paths (will freeze preview), and no crash would happen after lowering RAW video resolution. (I noticed this a year ago)
2- by suspending aewb task (LiveView hacks (https://www.magiclantern.fm/forum/index.php?topic=26443.0)), I figured this out after some digging some days ago:
LiveView crashes after lowering RAW video because of ClrCalc task, ClrCalc is probably expecting returning some certain values and if that didn't happen it will lead the camera to a crash, there is a function which stops ClrCalc task but I didn't try yet, well, I remembered that suspending aewb task will make a call to stop ClrCalc task too, so I lowered RAW video resolution then called aewbSuspend, and the camera didn't crash.
So the camera crash when lowering RAW video resolution isn't related to preview task/s itself.
-Why this is helpful:
-Making preview experiments without worrying about crashes during the experiments
-Enables high FPS, e.g. I got 88 FPS (not (https://www.magiclantern.fm/forum/index.php?topic=19300.msg204020#msg204020) new (https://www.magiclantern.fm/forum/index.php?topic=19300.msg229590#msg229590) BTW (https://www.magiclantern.fm/forum/index.php?topic=19300.msg229591#msg229591)) in 1736x338 5x3 14-bit lossless and it was continuous without corrupted frames, write speed up to ~50 MB/s thanks to suspending aewb task, also the camera was responsive (aewb is the most CPU hungry task, at high FPS it suck all of the CPU power).
-Only YUV LV path is frozen when lowering RAW resolution, YUV HD path is working (we already have code (e.g. fisheye) which redirect YUV HD path to YUV LV path).
-fully Patching mv720 mode into mv1080 is working with working preview :D:
Set cam to 1080p, adtg_gui "Modified from now on", set cam to 720p, lock registers, skip C0F26810/C0F26808 (related to EDMAC, overriding them will freeze the camera), switch to 1080p --> frozen LiveView, hmm let's suspend aewb task --> LiveView is working again (a little choppy) and RAW data is valid.
Doing the same experiment but by patching mv1080 mode into mv720, will have working YUV HD path and RAW data but both streams will have only 1736x696 from the top of frame working, the bottom part of frame will be frozen, something is restricting the amount of data, figuring this out (by comparing 720p vs 1080p configuration, and this time it's not the displayed registers in adtg_gui) will allow us to process more than 1736x1160 in LiveView in 1080p mode.
Tests were done on 700D.
@Bilal.
I wonder if there way in 3.5k mode (5DIII) when recording to force framing in B&W and not switching between Black and White and color.
Maybe it could improve speed? It's the case in anamorphic, only black and White and higher framerate. In practice it's a very low resolution in black and white but almost in real time.
Thank you.
This can be done easily, in mlv_lite.c iirc it's in:
unsigned int raw_rec_update_preview(unsigned int ctx)
You can force black and white preview all time by changing:
(need_for_speed && !get_halfshutter_pressed())
? RAW_PREVIEW_GRAY_ULTRA_FAST
: RAW_PREVIEW_COLOR_HALFRES
to
(need_for_speed && !get_halfshutter_pressed())
? RAW_PREVIEW_GRAY_ULTRA_FAST
: RAW_PREVIEW_GRAY_ULTRA_FAST
Also forcing B&W preview option can be implemented in a cleaner way under RAW video submenu.
-Will this improve speed?
-Not much really, only in idle (while not recording).
-Is there a way to increase ML Framing preview speed?
-Yes, but the cost is higher chance of corrupted frames while using Framing preview.
This part of code:
/* be gentle with the CPU, save it for recording (especially if the buffer is almost full) */
msleep(
(need_for_speed)
? ((queued_frames > valid_slot_count / 2) ? 1000 : 500)
: 50
);
Controls when it's okay to refresh Framing preview depending on RAW recording state, this part of code add delays while recording for Framing preview to slow down refresh rate.
If you removed this part of code you will have semi real-time preview in B&W during RAW recording, of course this will make CPU usage 100% all time and there is high chance you will have corrupted frames.
But we can probably fine-tune the delay (reduce it), play with 1000 and 500 values (decrease them).
1000 and 500 are in milliseconds.
Thank you for your reply!
In pratical when recording, we can switch between crop realtime preview and framing greyscale. Framing is usefull to check the correct frame before switching back to crop realtime preview which is stable.
If we can finetune the delay and achieve an almost realtime b&w preview for at least 5 seconds (not really need more) it will be enough for following moving subjects without a proper realtime preview.
Last year (24/7/2022) I shared a list for my plans on DIGIC 4/5 models on Discord (https://discord.com/channels/671072748985909258/671072748985909264/1000683224583897120)(did I share it somewhare on the forum too?):
QuoteMy current plans on D4/5 (without guarantees):
-Improve SD overclocking, e.g. making 240 MHz SD overclocking stable on 100D/EOS M/5D3.
-Improve memory management among crop_rec, silent picture and RAW video (on 700D/100D).
-Understanding preview, at least how to control it for our purposes; for real-time correct preview in crop modes, clean HDMI (without black borders).
-Lossless on DIGIC 4 if possible.
My highest priority is 240 MHz SD overclocking on 100D, currently I am putting all of my ML time into SD overclocking.
Good news: I got 240 MHz from "it doesn't work at all" state (on 100D) to "it's working partially", I found a new piece in the puzzle.
And hey, speaking today . . we achieved the first goal, stable 240 MHz overclocking (https://www.magiclantern.fm/forum/index.php?topic=25841.msg234228#msg234228) across all DIGIC 5 models :D
Quote-Improve SD overclocking, e.g. making 240 MHz SD overclocking stable on 100D/EOS M/5D3. Done!
Beside, many W90 SD cards (https://www.magiclantern.fm/forum/index.php?topic=26634.msg240335#msg240335) now work with the *new* sd_uhs at 240 MHz (have we created a list for working SD cards yet? :P), until now nobody reported burned SD card which is good :D
I wouldn't achieve this without the help of community of course, having a 100D (https://www.magiclantern.fm/forum/index.php?topic=26250.msg236842#msg236842) made things easier to me by working on hardware directly, and definitely pushed the excitement and the feel of the challenge.
Also, the work was based on other dev work (https://www.magiclantern.fm/forum/index.php?topic=12862.msg185968#msg185968) who is a1ex (literally, his previous amazing work still pushes/excites me to work more on this project), we are missing you.
Okay, so what would be my next goal after SD overclocking on DIGIC 5 from above list?
We all know, time to work again on it . . .
(https://i.ibb.co/bzbtPPH/PREVIEW.jpg)
Sneak-peek on what's I am working on/doing in background :):
-This month I started to work again on preview, my understanding is improved
-I found a new
missing pieces which affect preivew (the pieces which don't show in adtg_gui)
-Now I can
fully patch mv1080 in mv720 for the
first time with working preview and valid RAW data (no cut):
Quote from: theBilalFakhouri on June 26, 2022, 02:48:28 AM
Doing the same experiment but by patching mv1080 mode into mv720, will have working YUV HD path and RAW data but both streams will have only 1736x696 from the top of frame working, the bottom part of frame will be frozen, something is restricting the amount of data, figuring this out (by comparing 720p vs 1080p configuration, and this time it's not the displayed registers in adtg_gui) will allow us to process more than 1736x1160 in LiveView in 1080p mode.
That means, the new findings can control the limit of processed RAW data in LiveView, unfortunately and untill now my tests to increase processed RAW data in mv1080 *weren't successful
-We can shift preview on screen (LCD/HDMI) which mean we can center it, no need to move ML top bar to bottom
-Also get rid of bottom vram artifacts using Canon configuration, no need to draw black box (current 1x3 presets look like native video modes with these :P)
-I got the first
proof of concept for
clean HDMI on 700D, still not perfect though, I ended up with that "I should work on other part of preview first" then clean HDMI.
-If you followed the previous work on preview, current amount of RAW data which we can process in x5 mode is around ~2.7 MP:
Quote from: theBilalFakhouri on March 30, 2022, 10:44:01 AM
The reason why all of 1x3 real-time presets are limited to ~2.7 MP because of preview, going above ~2.7 MP resolution will make Preview frozen or you will lose part of the horizontal /vertical preview (there is a limit here, more research is required).
Huh, but why it's ~2.7 MP? It's 2.7 MP in
x5 mode . . two days ago I thought about it and figured out that 2520x1080 (default RAW resolution in x5 mode) is ~2.7 MP :)
-*I went back and looked into the new findings which made patching mv1080 into mv720 successful, and found out that they were related to
two EDMAC channels, and more likely it's a buffer size issue, I believe that explain why I couldn't go over 1736x1160 in 1080p and over 2.7 MP in x5, but I got over 1736x696 in mv720, because mainly -I think- I redirected one of EDMAC channel buffer address for mv720 to mv1080 buffer address which should be theoretically larger.
Right now I am still working on EDMAC findings. take everything with grain of salt and be patience please :)
-This is applicable to 700D and should be also applicable to similar models
-5D3 have few similarities, but I am still missing a starting point, didn't look deeper yet
-Things will be shared when it's ready, it's might not be for free, too early to talk about these . . today I just wanted to tell that I have some good news about preview thing
-As always, there is no guarantee of success (it could be there Hardware limits or I might never figure it out completely), there is no time-line regarding when this will be out or ready, I hope it won't take years :)
I am documenting everything I found, hopfully no infos would be lost from my side.
great finding bilal
Very cool. I guess we could get a good mv1080p mode for eos m here? What about increasing fps here? Will it work better than with regular 1080p?
Is this patch also valid for h264? Might get mv1080p 50 or 60 fps?
Thanks andy kh!
Oh yes! it fu*%ing EDMAC thingie :D , I could process more than 1736x1160 for the first time in mv1080, by redirecting EDMAC mv1080 buffer address to x5 buffer address which made me think it would rasies the limit to ~2.7 MP instead of ~2 MP, but . . I could porcess ~3.7 MP now in LiveView in mv1080 mode:
Proof of Concept, exceeding the limits:
[gifv]https://i.imgur.com/0LlKXKy.mp4[/gifv]
Un-touched Vram dumps from camera:
https://drive.google.com/drive/folders/1bbRPhuVe4WJFDAyG-oiP8iqi3xaPCvtp?usp=share_link
-and the funny part is that EDMAC channel (which causes limit issue) is used for clearning focus pixels in preview :P could we just disable it completely?
We might save some memory bandwidth and reduce overhead.
-Unfortunately, I got corrupted frames in 1736x2154 @ 23.976 FPS with real-time preview, this mode isn't usable for RAW recording yet, the cause is the preview, it could be it's from x5 EDMAC buffer which I re-used or a hardware limit,
more tests are needed. Reducing FPS to ~21 FPS helped in this preset (recording was fine).
-I didn't test increasing preview for horizontal resolution, last time we had black bar limit, still no idea where this comes from.
-Also, the preview is now being calculated automagically in crop_rec, there are no hardcoded values for each preset.
I need now to work out how to direct it correctly to our own buffer, that might help . .
Everything you say is too technical for me to understand the real implications, but sounds like magic, you are a wizard! :o
Quote from: Danne on January 31, 2023, 07:11:51 AM
Very cool. I guess we could get a good mv1080p mode for eos m here?
Thanks!
Yes, I think we can patch mv720 to mv1080 with working preview, without using MCM on EOS M (that already worked on 700D).
Quote from: Danne on January 31, 2023, 07:11:51 AM
What about increasing fps here? Will it work better than with regular 1080p?
1080p mode has 1736x1160 RAW resolution, if we could reduce vertical resolution to 1736x976 16:9 or 1736x738 2.35:1 and got preview working (not frozen) we can definitely gain more FPS.
Quote from: Danne on January 31, 2023, 07:11:51 AM
Is this patch also valid for h264? Might get mv1080p 50 or 60 fps?
The sensor isn't fast enough to scan 1736x976 at 60 FPS, on 700D 1736x868 @ 50 FPS is possible for example, but I have no idea if H.264 encoder is fast enough to encode that.
Anyway, I will not touch H.264 things, H.264 is already horrible on our cams, MJPEG make more sense if you ask me :P (too early to even talk about it)
Quote from: theBilalFakhouri on January 31, 2023, 09:16:06 AM
1080p mode has 1736x1160 RAW resolution, if we could reduce vertical resolution to 1736x976 16:9 or 1736x738 2.35:1 and got preview working (not frozen) we can definitely gain more FPS.
When recording I accidentally use 5x zoom in 1736x976 mode 25fps (canon setting) and the fps changed to 29.954 maybe it gives you something to investigate..
I like using this "accidental mode" when use wide lens
🤣 but sometimes I got freeze LV too..
(https://i.ibb.co/ZW8H9Qq/Screenshot-2023-01-21-140847.jpg)
Thanks for the files bilal. I converted it to a MLV with raw2mlv but probably was MLV already :P and opened it in Mlv App. Unstretched and hell yeah. Wizardry in the making. Here´s the MLV file for playing:
https://bitbucket.org/Dannephoto/raw2mlv/downloads/RAW-002.MLV
(https://i.postimg.cc/vmrcxZYb/Screenshot-2023-01-31-at-10-04-05-png-800px.jpg)
(https://i.postimg.cc/Znrf13ZX/Screenshot-2023-01-31-at-10-04-17-png-300px.jpg)
max resolution is 2520 x 1080 from 1736 x 976 from what I have tried..
(https://i.ibb.co/hsSnh8v/Screenshot-2023-01-31-194513.jpg)
Quote from: ML700D on January 31, 2023, 09:58:45 AM
When recording I accidentally use 5x zoom in 1736x976 mode 25fps (canon setting) and the fps changed to 29.954 maybe it gives you something to investigate..
Quote from: ML700D on January 31, 2023, 09:58:45 AM
I like using this "accidental mode" when use wide lens 🤣
off-topic here, please reports any *issues* related to my builds in my dedicated thread Bilal's crop_rec_4k experiments for 650D / 700D (T4i / T5i)
(https://www.magiclantern.fm/forum/index.php?topic=25784.0)
That mode is called
x5 mode which can be entered by pressing magnification button in LiveView, and 30 FPS is normal in x5 mode, x5 mode is always 30 FPS by default (that's how Canon made it) and it discard FPS settings in Canon menu.
Quote from: ML700D on January 31, 2023, 01:58:25 PM
max resolution is 2520 x 1080 from 1736 x 976 from what I have tried..
..
Same thing, in default x5 mode (without crop_rec) the maximum resolution is 2520x1080 @ 29.954 FPS by Canon default, that's normal.
Quote from: ML700D on January 31, 2023, 09:58:45 AM
but sometimes I got freeze LV too..
Steps to reproduce?
Quote from: iaburn on January 31, 2023, 09:10:24 AM
Everything you say is too technical for me to understand the real implications, but sounds like magic, you are a wizard! :o
Thanks! spending a lot of time and doing a lot of experiments helps with making sense of things :)
But for sure, I never understand every little thing, but I understand things enough.
Quote from: theBilalFakhouri on January 31, 2023, 06:15:04 PM
Steps to reproduce?
I'm not aware of that..
but I will report then in your thread Bilal's crop_rec_4k experiments for 650D / 700D (T4i / T5i) if it happens again.
Processing 1736x2214 @ 22 FPS in LiveView works and recording is fine, increasing FPS higher than that will start to introduce problems like choppy preview and corrupted frames, setting FPS to 23.976 freezes both RAW and preview streams.
I think we hit memory bandwidth limit here (could be processing a.k.a Hardware limit?), not a buffer size this time.
I am trying to change EDMAC#24 channel (the one which correct focus pixels, called "Safari") to *other channel, but this requires patching 10 ROM addresses (I am using patch_instruction) which works, but when enabling crop_rec, not all of the addresses will patched (cache collision), I need to find an other way to change the channel.
*Because some EDMAC channels **performs worse than others, I am just geussing that EDMAC#24 channel has limited bandwidth, assuming the problem is coming from it . .
If this doesn't work (if changing the channel doesn't perform better), we need to find a way to skip focus pixel correction step, and pass LiveView streams without it, hoping this will fix the issue,
of course, I am still assuming that the problem is coming from "Safari" process. I don't how to disable Safari and and pass streams . . yet.
**In the past, I tried some EDMAC write channels for RAW recording, some of them introduced corrupted frames, while others were perfect. And of course in our builds we are using the perfect ones.
Perhaps good news for 5D3? 😍
Quote from: ShittyWebsite on February 01, 2023, 09:32:47 PM
Perhaps good news for 5D3? 😍
There is no news for 5D3 . . at least, not yet.
But if 700D was powerful enough to process 1736x2214 @ 22 FPS in LiveView + record RAW video + doing lossless compression in the same time :), 5D3 should be even more powerful, it has faster CPU and RAM.
My tests on 5D3 were by comparing x5 and x10 modes, I was always trying to figure out how cropping is happening, no luck so far.
But in the coming weeks I will start to compare mv720 vs mv1080 configurations on 5D3, might find something there.
Will spend all of my ML time on Preview this year.
Quote from: theBilalFakhouri on January 31, 2023, 09:03:45 AM
-Also, the preview is now being calculated automagically in crop_rec, there are no hardcoded values for each preset.
Woah! That is wonderful!
Quote from: theBilalFakhouri on February 01, 2023, 08:59:09 PM
**In the past, I tried some EDMAC write channels for RAW recording, some of them introduced corrupted frames, while others were perfect. And of course in our builds we are using the perfect ones.
I had this problem in 2014-2015 working on 7D. Tearing in the recorded image (like a split screen) when external monitor was taxing CPU. Changing to different EDMAC channel fixed it. I wish i could tell you why.....
I splitted the post regarding "Framing" preview, it's being off-topic here. Here is it:
Fine-tuning Framing preview to speed it up (https://www.magiclantern.fm/forum/index.php?topic=26783.msg241991#msg241991)
Let's continue there.
Processing 1736x2214 @ 23.976 FPS in LiveView works
yeah yeah ez ez
It seems the hardware is powerful enough, thanks Canon!
Quote from: theBilalFakhouri on February 04, 2023, 02:00:17 PM
Processing 1736x2214 @ 23.976 FPS in LiveView works
yeah yeah ez ez
Does it means that real time preview on the EOS M at 1736x2178 might be possible?? :o :o
Quote from: iaburn on February 04, 2023, 02:40:24 PM
Does it means that real time preview on the EOS M at 1736x2178 might be possible?? :o :o
Yes, that's exactly what does that mean :)
EOS M/EOS M2/700D/650D/100D are benafited from this research and achievements, because their internals are very similar, almost identical.
Previous LiveView work (current 1x3 presets with real-time, a.k.a frtp presets on EOSM) was started on 700D then ported and fine-tuned by Danne to EOS M (it's almost copy-paste stuff here).
Quote from: theBilalFakhouri on February 04, 2023, 02:00:17 PM
Processing 1736x2214 @ 23.976 FPS in LiveView works
yeah yeah ez ez
Crazy. It's almost like you are recording outside liveview area :o.
Incredible... I got on board in Magic Lantern just recently after hearing about it for sooooo many years and I find amazing that you and other clever people are still passionate about this and bringing features that seemed impossible, thank you!!
Clean image (no artifacts) and real time preview are the 2 main factors for me to choose a recording preset. With the latest Framing preview improvements it got much better, 2.8K is awesome now, but live preview on 1x3 using the full 1736 pixels will be my go-to mode <3
Quote from: theBilalFakhouri on February 04, 2023, 02:00:17 PM
Processing 1736x2214 @ 23.976 FPS in LiveView works
yeah yeah ez ez
5D3 user on ML forum like:
(https://raw.githubusercontent.com/vastunghia/vastunghia.github.io/main/F458567E-F11A-4E5C-98D5-08399EDBE6F6.gif)
(Apparently ani gif not supported by forum, here it is (https://raw.githubusercontent.com/vastunghia/vastunghia.github.io/main/F458567E-F11A-4E5C-98D5-08399EDBE6F6.gif))
Quote from: vastunghia on February 04, 2023, 11:04:18 PM
5D3 user on ML forum like:
[gifv]https://i.imgur.com/AsfK0rd.mp4[/gifv]
I will feel the same if I had a 5D3 . . ah I already have a 5D3 😅, yes sorry . . as I said eariler, this year I will focus only on Preview . .
I started on 700D because I worked on it before, I wanted to continue the investigation there until I understand every single piece of preview (understand it enough) and finish the unfinished work
--> 5D3 have some similarities, this may help when I start looking into 5D3 again. Well, same thing has happened to 5D3 regarding SD stuff last year, it started on 100D, then all DIGIC 5 models were benefited, including 5D3 :)
I really hope I can get something on 5D3 regarding preview this year . .
In the meantime:
Proof of Concept: 1736x868 @ 50 FPS
WORKS with correct preview :D (high FPS modes can work with real-time correct preview)
I figured out why it wasn't working before (it was choppy (https://www.magiclantern.fm/forum/index.php?topic=25976.msg235466#msg235466) and casues corrupted frames), a coder error :P
-Current step: figuring out how to increase width preview (we are currently limited to ~2000 pixels), going over that produce black bar in x5 mode. I didn't try yet increasing width in 1080p mode.
Quote from: theBilalFakhouri on February 05, 2023, 12:24:14 AM
In the meantime:
Proof of Concept: 1736x868 @ 50 FPS WORKS with correct preview :D (high FPS modes can work with real-time correct preview)
I figured out why it wasn't working before (it was choppy (https://www.magiclantern.fm/forum/index.php?topic=25976.msg235466#msg235466) and casues corrupted frames), a coder error :P
wow.. nice! can I test it?
Quote from: ML700D on February 05, 2023, 03:09:13 AM
wow.. nice! can I test it?
Thanks!
Things are still being work in progress, not fully finished yet. The fourth month isn't far from now too :P
More likely these new achievements won't be for free, e.g. I spent ~4 hours a day last month working on preview.
Quote from: theBilalFakhouri
I really hope I can get something on 5D3 regarding preview this year . .
Thank you for your amazing work!
I have both EOS M and 5D3, improvement for 700d /Eos M is a good news but improvement for 5d3 will be a little revolution because 5D3 is far better in terme of quality. It will not only be a cheap camera to achieve raw footages but a real cinematique camera for professionnal work.
Quote from: theBilalFakhouri on February 04, 2023, 02:50:52 PM
Yes, that's exactly what does that mean :)
EOS M/EOS M2/700D/650D/100D are benafited from this research and achievements, because their internals are very similar, almost identical.
Previous LiveView work (current 1x3 presets with real-time, a.k.a frtp presets on EOSM) was started on 700D then ported and fine-tuned by Danne to EOS M (it's almost copy-paste stuff here).
This is some serious advancement @theBilalFakhouri, the extra amount of details gained in the 1736x2180 mode on the eos m is quite significant.
Quote from: Grognard on February 06, 2023, 09:18:33 AM
improvement for 5d3 will be a little revolution because 5D3 is far better in terme of quality. It will not only be a cheap camera to achieve raw footages but a real cinematique camera for professionnal work.
+1 and I also think that preview improvements over HDMI, in particular, will be crucial.
Yes! I'd pay for some improvements to my 5D III ...I know here in NYC many working professionals keep 5D Mark 3's around as backups for photos. I think like me, they would put them in service in video production as a B or C cam or backup if they were a bit more usable in terms of monitoring. The CDNG to color space transform in Resolve makes it easy to match 5D III as a B cam.
I personally feel like EOS M is a bit of a toy, hobbyist thing, no offense.
Thank you all guys!
It seems that we all love shooting RAW video :), that's why working on increasing write speed (LiveView hacks, SD Overclocking) and preview are ones of my goals and they excite me too.
Okay, let's recap current state regarding Preview:
700D and similar models:
-Centering Preview on screen (LCD/HDMI) is now possible
-Clearing Preview artifacts using Canon configuration is now possible
-Exceeding Preview height limit is now possible (we can upgrade current 1x3 modes to higher resolutions, 1736x2214 *already works)
-Getting Preview working in High FPS modes is now possible (we can reduce RAW resolution to increase FPS, 1736x868 @ 50 FPS *already works)
*I didn't check yet if there would be new or further limits, e.g. processing 1736x2928 might not be possible (didn't check yet), also didn't check if we can get 1736x738 @ 60 FPS with correct Preview
(without corrupted frames) or even higher FPS than 60 FPS at lower resolutions with working preview.
-Last thing that I need to figure out here regarding Preview is how to increase width preview for 1:1 resolutions, such as 3K/2.8K/2.5K/1440p without black bar.
I didn't make experiments yet, currently going above ~2000 pixels width will result in black area.
5D3:
-Registers which control how much height and width we want to process in LiveView seems similar to 700D, which are in C0F3 range (can be showed using adtg_gui)
-Patching 1080p mode into 720p mode works, gives valid RAW data but Preview is *stretched
-Patching 720p mode into 1080p mode works, gives valid RAW data but Preview is *squeezed
-* That's because YUV configuration is being set somewhere where I don't know yet outside adtg_gui, in 700D it's being set using some C0F1 and C0F0 registers (can be shown in adtg_gui).
And that's might be the only difference compared to 700D. I just need to find where it's being set to be able to start experiments on 5D3.
YUV configuration contains scaling and stretching routines for Preview streams (LV/HD YUV paths). on 700D I use them to show the new processed data in LiveView, also correct
apsect ratio in LiveView.
-How to find it?
More likely by comparing video modes configurations, e.g. 1080p vs 720p and x5 vs x10. Find which function set YUV configuration, and where does it store it in memory?
-For me, I just started yesterday comparing 1080p vs 480p configurations, why?
Because 480p mode have same as 1080p RAW configuration, both have 1920x1290 RAW resolution, beside no registers are being shown in adtg_gui by compring 480p vs 1080p which what I want.
The only difference here is YUV configuration and Canon overlay configuration, I already found out where Canon overlay configuration is being set so I can skip it, because it's not important for us.
Now I am looking for YUV configuration (where it's being set), thing that will help of course is:
1080p has 1904x1274 YUV HD resolution while 480p has 1280x852, which mean scaling and stretching routines are used here . . I just need to find where they are being set now.
Also there are three EDMAC channels seem related to YUV HD path which are channels #10, #21 and #28. Searching around them may lead us to something.
Might spend this month working on 5D3 . .
Truly awesome news! Full 5K real time is already huge. If it's finally possible to overcome this 2000 pixels limit for crop modes, that would take it to another level :o
Quote from: theBilalFakhouri on February 08, 2023, 12:34:57 PM
-Exceeding Preview height limit is now possible (we can upgrade current 1x3 modes to higher resolutions, 1736x2214 *already works)
You have this working with real time liveview?
good work bilal. keep it up👍
Quote from: iaburn on February 08, 2023, 01:53:02 PM
Truly awesome news! Full 5K real time is already huge. If it's finally possible to overcome this 2000 pixels limit for crop modes, that would take it to another level :o
Thanks!
Will try doing my best for getting more 2000 width pixels :)
Quote from: Danne on February 08, 2023, 03:05:24 PM
You have this working with real time liveview?
Yes! already mentinoed that few days ago in this reply (https://www.magiclantern.fm/forum/index.php?topic=25287.msg242039#msg242039). Anyway here is a un-edited quick showcase:
https://www.youtube.com/watch?v=51TFnTAPbHI
What you can see in this video:
-1736x2214 1x3 @ 23.976 FPS with real-time responsive preview
-real-time preview compared to Framing preview
-The real-time preview is centered on LCD screen
-No artifacts in both top and bottom parts of the LiveView,
I pressed Info button to switch to Canon overlay, there are no artifacts there too
-It just look like a native Canon video mode 8)
Perfecto! :P
Thanks guys @vastunghia @andy kh!
Quote from: vastunghia on February 08, 2023, 03:18:28 PM
Am I dreaming? :P
I don't want to be negative, but it would be always there no guarantees of success . . Will try my best though :)
To anyone who is interested: just please don't hold your breath. Don't blame me if I failed :P
Wtf. 5.2k camera with real time preview from digic V sensor. Absolutely crazy.
Wow, would that work on the 5D3?
Crazy, crazy... The only failure is not trying!! The goal is just a bonus ;D
Quote from: iaburn on February 08, 2023, 07:51:43 PM
Crazy, crazy... The only failure is not trying!! The goal is just a bonus ;D
Sometimes I miss the "like" button on this beautiful Web 1.0 forum ;)
That's impressive 😮
Bilal,
You are doing God's work now
Thanks @everyone!
Quote from: Danne on February 08, 2023, 05:33:32 PM
Wtf. 5.2k camera with real time preview from digic V sensor. Absolutely crazy.
Exactly,
mind blowing! (recording RAW video + doing lossless compression + processing RAW data in LiveView .. at the
same time!) that's why I said earlier:
Quote from: theBilalFakhouri on February 04, 2023, 02:02:36 PM
It seems the hardware is powerful enough, thanks Canon!
Quote from: Bruno Italiano on February 08, 2023, 07:19:17 PM
Wow, would that work on the 5D3?
It seems the hardware is powerful enough. 5D3 should be even more powerful than 700D (5D3 has faster CPU, RAM.. better hardware in general).
Current state for 5D3 was explained in this reply (https://www.magiclantern.fm/forum/index.php?topic=25287.msg242143#msg242143) , currently I am looking for the missing pieces on 5D3 . . then I can start doing some real experiments.
Quote from: theBilalFakhouri on February 08, 2023, 12:34:57 PM
-How to find it?
More likely by comparing video modes configurations, e.g. 1080p vs 720p and x5 vs x10. Find which function set YUV configuration, and where does it store it in memory?
are you doing this in QEMU? or in camera? Maybe if you make a video showing how you're comparing configurATIONS i COULD HELP YOU
@dpjpandone
Thanks for offering the help. I am doing it in camera (DebugLog + Ghidra + patching experiments).
I already found some functions which may be involved in YUV configuration on 5D3, I only need some time to make a deep look into it.
Ah, finally I think I have a
starting point on 5D3 :)
Now I found the function which select/toggle among YUV configuration (or at least sets zoom ratio?), I could force x5 preview into x10 preview (vice versa) for the first time.
And that's how things were started on 700D:
Quote from: theBilalFakhouri on August 27, 2020, 12:04:37 PM
"By locking the registers between x5 and x10 you can bring x10 real-time preview into x5 vice versa in Canon 700D.."
It's only the beginning here . . but this time on 5D3.
Quote from: theBilalFakhouri on February 10, 2023, 03:58:51 PM
It's only the beginning here . . but this time on 5D3.
Sounds like a Hollywood movie trailer :D and I'm thrilled as f*. Keep up mate!
Quote from: vastunghia on February 10, 2023, 04:21:07 PM
Sounds like a Hollywood movie trailer :D and I'm thrilled as f*. Keep up mate!
Man i was gonna say the same thing, i'm invested
Looking good @bilal, great job
By looking into ROM files, preview configuration seems like:
-DIGIC 4/4+:
Newer models: 600D, 60D and 1300D more likely it's same as DIGIC 5 (maybe slight differences).
Older models: 5D2, 7D and 550D more likely simpler than DIGIC 5.
-DIGIC 5: 650D/700D/100D/EOS M/EOS M2 are identical, simpler than DIGIC 5+.
-DIGIC 5+: 5D3, 6D and 70D seems similar and more likely it's more complex than DIGIC 5.
Little update on 5D3:
-I know now where EDMAC#
10 and EDMAC#
21 parameters (probably +other related parameters) are being set, and I can modify them, these are related to preview obviously:
Quote from: theBilalFakhouri on February 08, 2023, 12:34:57 PM
Also there are three EDMAC channels seem related to YUV HD path which are channels #10, #21 and #28. Searching around them may lead us to something.
-I am still
missing where EDMAC#
28 parameters + other parameters which might be related to stretching/scaling/cropping are being set.
-I am still looking for them.
After finding them (if I could), I will have some experiments to do, like:
-Patching VGA into 1080p (vice versa)
-Patching 720p into 1080p (vice versa)
-Patching x5 into x10 (vice versa), and get arbitrary crop factors like x15 and x20.
700D:
https://youtu.be/3j0WK3cW-4M
(https://i.ibb.co/sKb6JtR/black-glasses-00000.png) (https://i.ibb.co/sKb6JtR/black-glasses-00000.png) (https://i.ibb.co/sKb6JtR/black-glasses-00000.png)
OMG... This is how you announce progress on ML, with a proper epic video presentation!!! :D :D :D :D
Congrats!!
(https://i.ibb.co/WzmLQnL/applause.png)
Haha, how???
Quote from: iaburn on February 19, 2023, 03:27:51 PM
OMG... This is how you announce progress on ML, with a proper epic video presentation!!! :D :D :D :D
Congrats!!
Epic moments need epic :D
Thanks!
Quote from: Danne on February 19, 2023, 05:50:02 PM
Haha, how???
Magic :P
Some more registers which appear to control/affect black area.
I had a thought yesterday which is black area limit is being controlled somewhere in preview initialization registers which being set once, e.g. doesn't change from video mode to another.
Firstly, I had to search among +2000 registers, until I narrowed down and got it. This year would definitely be the
Year of
Preview (well, at least for entry level models :P)
What you can see in this video (https://www.magiclantern.fm/forum/index.php?topic=25287.msg242356#msg242356):
-I could
exceed 2044 pixels
width limit for the
first time, this limit was introduced in the early days (https://www.magiclantern.fm/forum/index.php?topic=25287.msg230502#msg230502) of this research (https://www.magiclantern.fm/forum/index.php?topic=25287.msg230595#msg230595).
-
Next: figure out how to exceed 2520 width limit (if there is one), this time it won't be a black area, but
*something else :) I didn't make any tests yet.
*Preview stuff is like crashing into a wall to find another wall needs to be crashed in then to find out there is a third wall ... etc :P
Congratulations! This is huge, it can take this cameras to a whole new level! You have really badass skills in reverse-engineering :)
Thanks @Skinny
Quote from: Skinny on February 20, 2023, 05:55:51 PM
This is huge,
It is :)
Not only for DIGIC 5 models, but for newer models, I mean if DIGIC 5 generation (from 12 years) is that powerful, DIGIC 6/7/8 must be capable too.
Quote from: Skinny on February 20, 2023, 05:55:51 PM
..it can take this cameras to a whole new level!
Also it would be nice 10 years anniversary for having RAW video :)
Quote from: Skinny on February 20, 2023, 05:55:51 PM
You have really badass skills in reverse-engineering :)
I am definitely getting better over time, not claiming I am the most expert one here though. Thanks!
Quote from: theBilalFakhouri on February 19, 2023, 09:40:50 PM
I had a thought yesterday which is black area limit is being controlled somewhere in preview initialization registers which being set once, e.g. doesn't change from video mode to another.
Firstly, I had to search among +2000 registers, until I narrowed down and got it. This year would definitely be the Year of Preview (well, at least for entry level models :P)
*Preview stuff is like crashing into a wall to find another wall needs to be crashed in then to find out there is a third wall ... etc :P
That sounds very tedious. Thank you for all your hard work!
When will you post the ransom? :P So we can get this going on eos m? Thanks for the hard work you always move things forward.
Quote from: dpjpandone on February 21, 2023, 02:49:22 AM
That sounds very tedious. Thank you for all your hard work!
Reverse engineering requires a lot of patience in some cases, it's a lot of fun when you discover new thing and make things work.
Thank you too!
Quote from: Teamsleepkid on March 01, 2023, 12:08:00 AM
When will you post the ransom? :P So we can get this going on eos m? Thanks for the hard work you always move things forward.
Sooooon :P
Currently I am re-writing (the old code) and writing new code (for new stuff) and I am trying to make it
as clean as possible, goals:
-Support for 650D / 700D / EOSM / 100D (also
*EOS M2) in one branch
So when it get realeased it will have 650D / 700D / EOS M / 100D support
*I need to check EOS M2 status in crop_rec_4k branch
-Don't break other models support like 5D3
-Code optimizations to avoid crashes, corrupted frames
-Some new things will be announced later
-Also and finally merge all of these new stuff to magiclantern_simplified (https://github.com/reticulatedpines/magiclantern_simplified)
If everything went smoothly, you may expect an announcement next month :)
That would be a very useful merge :) Modern cams and old cams in one repo!
Quote from: theBilalFakhouri on March 01, 2023, 11:07:49 AM
Reverse engineering requires a lot of patience in some cases, it's a lot of fun when you discover new thing and make things work.
Thank you too!
Sooooon :P
Currently I am re-writing (the old code) and writing new code (for new stuff) and I am trying to make it as clean as possible, goals:
-Support for 650D / 700D / EOSM / 100D (also *EOS M2) in one branch
So when it get realeased it will have 650D / 700D / EOS M / 100D support
*I need to check EOS M2 status in crop_rec_4k branch
-Don't break other models support like 5D3
-Code optimizations to avoid crashes, corrupted frames
-Some new things will be announced later
-Also and finally merge all of these new stuff to magiclantern_simplified (https://github.com/reticulatedpines/magiclantern_simplified)
If everything went smoothly, you may expect an annoucment next month :)
Eos m2 is buggy, but very much working. I have the camera in pink, had it sent to me from dfort. Would you be interested in having the M2 sent to you for coding purposes? Maybe send it back when done, or keep it maybe.
Quote from: names_are_hard on March 01, 2023, 11:22:12 AM
That would be a very useful merge :) Modern cams and old cams in one repo!
Yes :D
Quote from: Danne on March 01, 2023, 11:30:45 AM
Eos m2 is buggy, but very much working.
Pretty sure we can make it not buggy :)
Quote from: Danne on March 01, 2023, 11:30:45 AM
I have the camera in pink, had it sent to me from dfort. Would you be interested in having the M2 sent to you for coding purposes? Maybe send it back when done, or keep it maybe.
Thanks for the offer!
Actually a donor offered to me his EOS M2 last year in September, and I accepted the offer, the donor was located in EU, I asked him to ship it to my friend in Germany and my friend got it.
(Thanks Donor!, do you mind mentioning your name?, credit will go to him in future).
Until now, I am still waiting a trusted passenger to bring it with him to my country, there was a chance last month but things didn't go well. Maybe later this year or next year.
Shipping it is very expensive and the main problem shipping can be complex at *unexpected times:
e.g. there was another donor offered to buy me a 70D body 1.5 years ago, the best 70D deal I could find at that time is from **China actually (low shutter count, brand new battery, cheaper),
due to "complexity" and unexpected "things" until now I didn't receive it. But might get a refund next month, and buy it locally.
*I bought a 3D printer a year ago, and PC monitor around ~2.5 years ago from China, shippments went smoothly (I waited ~25 days for 3D printer, around ~2-3 months for the monitor).
Shipping cost for these items were equal if not a little more than items price, so if a 3D printer was 220 USD you pay ~500 USD with shipping (that's sometime still cheaper than buying items locally, it depend)
**You may ask if shipping was very expensive, why to buy a 70D and
ship it from China?
Right, but shipment this was actually *free* that time, a friend bought some stuff from China, I asked him to put the 70D body in one of his many large boxes, so no additinal cost was from my side. What a good friend :P
Sorry it was off-topic here. But I needed to make things clearer. Thanks again!
So basiclly I will have a EOS M2 and 70D to work on sooner or later :D
EOS M2 is more likely very similar to 100D, I will look into it later, also if there was a EOS M2 tester, that would helpful too.
Quote
So basiclly I will have a EOS M2 and 70D to work on sooner or later :D
EOS M2 is more likely very similar to 100D, I will look into it later, also if there was a EOS M2 tester, that would helpful too.
What about us forgotten 5d3 users? Will there be good news also for us? :)
Quote from: Mattia on March 01, 2023, 06:47:03 PM
What about us forgotten 5d3 users? Will there be good news also for us? :)
Come on, 5D3 users are not forgotten . . at least not yet :P
I stopped working for now on 5D3, last update was here (https://www.magiclantern.fm/forum/index.php?topic=25287.msg242336#msg242336), surely I am getting closer, but unfortunately nothing . . yet.
I just need to finish working on 650D / 700D / EOS M/M2 / 100D family (might finish in two months), then after that my ML time would be dedicated to 5D3 to the rest of the year.
I hope I won't give up, even if I did, other devs will have the info which will be documented in future.
The research was started on 700D back in august 2020, and only this year (after ~2.4 years?) I was able to get an interesting results.
I again, really hope to get something this year on 5D3, but hope isn't enough really . . at least I can say my skills are improving overtime which translate to figuring out stuff faster (if it was not very complex) compared to me in the past years, like 2018 :P:
Quote from: theBilalFakhouri on April 20, 2018, 08:30:57 PM
I really don't know much about coding yet.
The blue Developers will know the answer about these coding things :D
I was "New to the forum" member back then, didn't know anything about coding/reverse engineering, ML project was exciting/amazing enough to get me involved.
So: patience please :) , BTW do you still have your EOS M? if yes, you might get some exciting news for it next month ;D
Quote
So: patience please :) , BTW do you still have your EOS M? if yes, you might get some exciting news for it next month ;D
Nope! I've sold it! Right now I'm a happy 5d3 only user! Don't let me regret it! :)
Quote from: Mattia on March 01, 2023, 07:27:44 PM
Nope! I've sold it! Right now I'm a happy 5d3 only user! Don't let me regret it! :)
Ah, I see :) Well, Canon made preview work differently on 5D3, not me ;)
Controlling preview on 5D3 must be possible . . somehow :D
Quote from: theBilalFakhouri on February 19, 2023, 09:40:50 PM
-I could exceed 2044 pixels width limit for the first time, this limit was introduced in the early days (https://www.magiclantern.fm/forum/index.php?topic=25287.msg230502#msg230502) of this research (https://www.magiclantern.fm/forum/index.php?topic=25287.msg230595#msg230595).
-Next: figure out how to exceed 2520 width limit (if there is one), this time it won't be a black area, but *something else :) I didn't make any tests yet.
Preivew width limit now is around ~
2860 pixels (going above this introduce black bar), much better than 2044, it should cover the following 1:1 presets:
-
2.5K, 2520x1080 (already tested)
-
2.8K, 2880x1226 (width tested, height not yet, should work)
-
1440p, 2560x1440 (not tested yet, should work)
Quote from: theBilalFakhouri on March 04, 2023, 07:12:42 PM
Preivew width limit now is around ~2860 pixels (going above this introduce black bar), much better than 2044, it should cover the following 1:1 presets:
-2.5K, 2520x1080 (already tested)
-2.8K, 2880x1226 (width tested, height not yet, should work)
-1440p, 2560x1440 (not tested yet, should work)
Awesome! That's already A LOT :o
I think realtime preview is most useful in modes that allow continuous recording, so at least for the EOS M this is perfect :D
Quote from: theBilalFakhouri on March 04, 2023, 07:12:42 PM
Preivew width limit now is around ~2860 pixels (going above this introduce black bar), much better than 2044, it should cover the following 1:1 presets:
-2.5K, 2520x1080 (already tested)
-2.8K, 2880x1226 (width tested, height not yet, should work)
-1440p, 2560x1440 (not tested yet, should work)
Thats awesome. You are pushing the limits everyday. Almost made it to the 3k limit.
is this available?
"I just need to finish working on 650D / 700D / EOS M/M2 / 100D family"
Bilal if you were to update the M2 build with this I would travel to wherever in the world you are and kiss your feet.
ANY updates or improvements to the M2 build are enormously appreciated.... but frankly it has many problems greater than this... but I would LOVE to have this in my M2.
Please and Thank you regardless.
Quote from: theBilalFakhouri on March 01, 2023, 07:17:52 PM
Come on, 5D3 users are not forgotten . . at least not yet :P
I stopped working for now on 5D3, last update was here (https://www.magiclantern.fm/forum/index.php?topic=25287.msg242336#msg242336), surely I am getting closer, but unfortunately nothing . . yet.
I just need to finish working on 650D / 700D / EOS M/M2 / 100D family (might finish in two months), then after that my ML time would be dedicated to 5D3 to the rest of the year.
I hope I won't give up, even if I did, other devs will have the info which will be documented in future.
The research was started on 700D back in august 2020, and only this year (after ~2.4 years?) I was able to get an interesting results.
I again, really hope to get something this year on 5D3, but hope isn't enough really . . at least I can say my skills are improving overtime which translate to figuring out stuff faster (if it was not very complex) compared to me in the past years, like 2018 :P:
I was "New to the forum" member back then, didn't know anything about coding/reverse engineering, ML project was exciting/amazing enough to get me involved.
So: patience please :) , BTW do you still have your EOS M? if yes, you might get some exciting news for it next month ;D
Is There some new AI technology that can help to develop ML?
No, AI can't really write code and most of ML isn't writing code anyway, it's reversing camera functionality.
Quote from: lightspeed on March 16, 2023, 05:25:42 AM
is this available?
You can help with making it available (https://www.magiclantern.fm/forum/index.php?topic=26851.msg243128#msg243128) :)
Quote from: psieg2 on March 29, 2023, 07:08:47 PM
Bilal if you were to update the M2 build with this..
ANY updates or improvements to the M2 build are enormously appreciated.... but frankly it has many problems greater than this... but I would LOVE to have this in my M2.
Sorry for the delay.
First step would be to check EOS M2 port in general without crop mood, when we make sure it's stable, then porting crop mood should be an easy task.
Probably I will try to port EOS M2 after releasing the new build and source code. Hope it will work out without issues on EOS M2. Don't hold your breath please!
Bilal,
I will try the CropMood on M2 when you release it, but am certain it will not work as no other non-M2 build works (I have tried).
I will update you with the results.
Oh and I donated 50 pounds to your effort last night!
Thanks!
Quote from: psieg2 on April 10, 2023, 08:05:26 PM
I will try the CropMood on M2 when you release it,
Currently EOS M2 isn't supported yet in crop mood build. It won't be there a version for EOS M2 when I release the new build.
Only 650D / 700D / EOS M / 100D will have a build for now. EOS M2 needs to be ported, I will try to do that in future after the release.
Quote from: psieg2 on April 10, 2023, 08:05:26 PM
but am certain it will not work as no other non-M2 build works (I have tried).
You can't install a build for X model on Y model, it doesn't work like this and it will never work.
You will need a dedicated version for EOS M2 to able to use it on EOS M2.
Quote from: psieg2 on April 10, 2023, 08:05:26 PM
Oh and I donated 50 pounds to your effort last night!
Thank you very much for your support!
I think you are on EOS M Facebook group too?
Yes I am on EOS M facebook group as well.
Mr. Bilal
I would like to thank you for your hard work with our community. I would like to ask you a question. Are you able to bring crop mood as well to the 6D? I dont own one, but I am actually wantind to own one because of its color science (some say its better than 5D3 for photography in colours and competes vs 5D2 and 5D classic). It seems to be even better in low ISO than the 5D3 and in some occasions, it even focus better than the 5D3 (Photography wise), hence, should be the better camera for video. Since they share the same processor, arent you capable of porting the crop mood with all the bells and whistles to it?
Again, thanks for your hard work!
Best regards from Portugal!
"hence, should be the better camera for video"
...until you discover the 5D3 got two memory card slots instead of one for the 6D, Magic Lantern allowing combined SD+CF card spanning technique that provides massive RAW writing performances :p
Ok. I wanst aware of that spanning technique. My fault, still, would be better handling higher ISOs. But the other cameras can go to 5k, 6D shouldnt be problematic, right?
@HugoMouteira
Thanks! if you mean getting real-time preview for custom high resolution presets on 6D:
6D is more similar to 5D3 and 70D (all of them have DIGIC 5+ SoC), current preview work (in crop mood) does only work on 650D / 700D / EOS M / EOS M2 / 100D (DIGIC 5, without plus) and this due to some differences among DIGIC 5 and DIGIC 5+ families, hence we will need to reverse engineer LiveView on DIGIC 5+ mostly from scratch, and currently I am still in the beginning phase.
I have both 5D3 and 70D, any progress on one of these model will mostly translate to the other two models, if I could achieve something on 5D3, it willl mostly be just matter of copy paste to 6D (due to similarities).
Unfortunately, no one can predict when we will get something working on 5D3, it may take months / years or may not happen at all, so I can't promise anything, but I can say that I am currently working on it.
Quote from: theBilalFakhouri on August 21, 2023, 08:37:08 PM@HugoMouteira
Thanks! if you mean getting real-time preview for custom high resolution presets on 6D:
6D is more similar to 5D3 and 70D (all of them have DIGIC 5+ SoC), current preview work (in crop mood) does only work on 650D / 700D / EOS M / EOS M2 / 100D (DIGIC 5, without plus) and this due to some differences among DIGIC 5 and DIGIC 5+ families, hence we will need to reverse engineer LiveView on DIGIC 5+ mostly from scratch, and currently I am still in the beginning phase.
I have both 5D3 and 70D, any progress on one of these model will mostly translate to the other two models, if I could achieve something on 5D3, it willl mostly be just matter of copy paste to 6D (due to similarities).
Unfortunately, no one can predict when we will get something working on 5D3, it may take months / years or may not happen at all, so I can't promise anything, but I can say that I am currently working on it.
Hey Bilal, just wanted to check in with you if there was anything you might need help with? I am not a programmer, but I do own a 5D III if you needed me to test anything etc.
Hello @kizza1234, since you asked, here is a
small progress update:
In the past few weeks I was working on 5D3 and was digging into preview stuff and EEKO code, well, I finally found the missing piece (https://www.magiclantern.fm/forum/index.php?topic=25287.msg242336#msg242336) which I mentioned many times :)
Also I found some
new registers in C0F1 range for 5D3 which being set by EEKO (entrly-level models have these also in C0F1, but on 5D3 they have diffrenet addresses and probably diffrenet functionality, both of them are used for the same purpose), they are used to config YUV stuff (preview) e.g for resizing/cropping preview image (like in x5 vs x10 modes on 5D3) . .
This means:I probably have all required pieces to start with preview experiments (by understanding how these registers work and how to control them properly).
I tried some quick experiments to force x5 to x10 on 5D3, also tried to force x6.0 preview to x3.0 on 70D (when using digital zoom mode) from these low level registers (by using EngDrvOut from ICU a.k.a main core), unfortunately it didn't work properly, resulting either in frozen preview or registers values overwrite by EEKO EngDrvOut,
This probably means I need to hook EngDrvOut function from EEKO side if I want to control these registers properly, and this is the hard part for now, because we don't have hooking code for EEKO core yet (cache hacks don't work here), but this doesn't mean it's impossible to hook it.
The
next step for now is to implement a way to hook EEKO code easily, DIGIC 6 cams will benefit from this too (they have Omar core which is similar to EEKO), @names_are_hard told me he might be able help in this.
Quote from: kizza1234 on April 16, 2024, 01:26:25 AMbut I do own a 5D III if you needed me to test anything etc.
Thanks! I have a 5D3 actually, currently there are no tests.
Awesome work, sounds promising!