Author Topic: Canon EOS M (Read 1671396 times)

Danne · « **Reply #1550 on:** July 03, 2018, 12:59:31 PM »

Sometimes it´s gets enabled when turning it on and off. All resolutions are showing when checking into the menu section.

Well, some good news. I shaved it to this in raw.c and footage seems corruption free. Only recorded one clip(uploading as we speak):

Code: [Select]

#ifdef CONFIG_EOSM
    /* EOS M exception */
    /* http://www.magiclantern.fm/forum/index.php?topic=16608.msg176023#msg176023 */
    if (lv_dispsize == 1 && !video_mode_crop && !RECORDING_H264)
    {
        *height = 1080;
    }
#endif

Let´s me set vertical resolution to 1048, will try to find edge for vertical resolution until it starts getting corrupted. This works with bilals registers published above.

EDIT 1:
Seems to only work with 14bit-lossles but hey, better than poop before.
https://bitbucket.org/Dannephoto/magic-lantern/downloads/M03-1229.MLV

EDIT 2: Tried suggested added and erased registers before A1ex but didn´t change anything for the better.

EDIT 3: 1736x1088 working...

EDIT 4: 1736x1120 working...

EDIT 4: In raw.c

Code: [Select]

*height = 1160;Getting us earthquake material

EDIT 4: In raw.c

Code: [Select]

*height = 1150;Working getting us 1736x1120

1736x1120 MLV file(14bit-lossless):
https://bitbucket.org/Dannephoto/magic-lantern/downloads/eosm_mv1080p_mr_cat.MLV

Finally:
1736x1120 seems to be max here. Totally epic that this actually is working now. No way this would work without the helping hand of a lot of people. A1ex, g3gg0, dfort, rbune and more. Finally this guy nails the registers. theBilalFakhouri! Epic work.

First one

:

Here is test version:
mv1080p for eosm
https://bitbucket.org/Dannephoto/magic-lantern/downloads/magiclantern-Nightly.2018Jul03.EOSM202_mv1080p.zip

Select 3x3_mv1080p_EOSM from Crop mode menu.

You will be able to get good footage in 14bit lossless. You can select 24fps and also global draw on for full frame preview. Preview is a bit wonky atm but there´s some serious skill out there(in here) so maybe that will be better with time. Probably continous with sd_uhs hack on(seems continuous without at 24fps).
Other modes might be broken since I modified exception code in raw.c.

theBilalFakhouri · « **Reply #1551 on:** July 03, 2018, 02:02:32 PM »

Great work for all guys helped for getting this and Congratulations for EOS M users

Next thing to fix LiveView

alpicat · « **Reply #1552 on:** July 03, 2018, 02:18:59 PM »

Quote from: Danne on July 03, 2018, 12:59:31 PM

Finally:
1736x1120 seems to be max here. Totally epic that this actually is working now. No way this would work without the helping hand of a lot of people. A1ex, g3gg0, dfort, rbune and more. Finally this guy nail the registers. theBilalFakhouri! Epic work.

Well done @Danne and everyone involved, this is legendary work and that footage looks awesome! Being able to shoot raw with the full aps-c sensor is going to be amazing - especially because Viltrox are close to releasing their ef-m to ef 0.71x speed booster, which will allow people to turn this into a full frame camera if they want!

With this resolution I'm assuming it pretty much uses the full sensor height (i.e. close to 3:2 aspect ratio)? If so that makes anamorphic shooting a nice option here too.

I've tested @Bilal's croprec module with 2.5k mode, but shooting at a lower resolution of 2224x1200 to get longer record times (10-20 seconds). Shot 14 minutes of footage and not a single problem - thanks so much for this!:

Danne · « **Reply #1553 on:** July 03, 2018, 02:32:11 PM »

Here is test version:
mv1080p for eosm
https://bitbucket.org/Dannephoto/magic-lantern/downloads/magiclantern-Nightly.2018Jul03.EOSM202_mv1080p.zip

Select 3x3_mv1080p_EOSM from Crop mode menu.

You will be able to get good footage in 14bit lossless. You can select 24fps and also global draw on for full frame preview. Preview is a bit wonky atm but there´s some serious skill out there(in here) so maybe that will be better with time. Probably continous with sd_uhs hack on(seems continuous without at 24fps).
Other modes might be broken since I modified exception code in raw.c.

alpicat · « **Reply #1554 on:** July 03, 2018, 03:33:42 PM »

Great, this works perfectly for me. Thanks so much - I think I'll be using this camera a lot more often now! Have tried without the sd uhs hack so far. Liveview preview is slightly stretched but totally usable. When global draw is on it says Mv 3x5 along the bottom on the liveview screen, is that normal or should that be 3x3?

Danne · « **Reply #1555 on:** July 03, 2018, 03:36:30 PM »

Hehe, I think *bilal* can answer about stretch modes

IDA_ML · « **Reply #1556 on:** July 03, 2018, 05:13:48 PM »

Nice illustration of the new modes with increased resolution, Alpicat! You may want to try also 3096x1320 at somewhat reduced frame rate (say 15 or 16 fps). You will be amazed at the quality!

theBilalFakhouri · « **Reply #1557 on:** July 03, 2018, 06:34:35 PM »

Quote from: alpicat on July 03, 2018, 03:33:42 PM

When global draw is on it says Mv 3x5 along the bottom on the liveview screen, is that normal or should that be 3x3?

It should be fixed somewhere in the code because this unusual for EOS M,, it's actually 3x3 when enabling the preset and You can't get up to 1120 height in 3x5

.

Danne · « **Reply #1558 on:** July 03, 2018, 06:42:03 PM »

It's very fishy. Earlier code(when mv1080p wasn't working) gave correct liveview with global draw. Now this. Maybe some register in my code?
https://s8.postimg.cc/7ozhy1eud/Screenshot_20180703-183716.png

a1ex · « **Reply #1559 on:** July 03, 2018, 06:43:51 PM »

Trying to add support for different frame rates; currently it's hardcoded to 25p; was the sample clip recorded with FPS override at 24?

One puzzle I'd like you to solve: what is the minimal value of timer A that still gives valid image? (without borders on the right side)

Code from fps-engio.c suggests 520 = 0x208. That means, in this block, use 0x207 instead of 0x27f (the hardware expects timerA - 1):

Code: [Select]

		case 0xC0F0600c: return 0x27f027f;
		case 0xC0F06008: return 0x27f027f;
		case 0xC0F06010: return 0x27f;

If 520 doesn't work, try something higher, until 640. If 520 works, try 510 or so - it should break.

Binning factors ~~and vertical resolution override~~ can be updated from raw_info_update_cbr, ~~so raw.c can stay untouched~~. Will post a patch soon.

Danne · « **Reply #1560 on:** July 03, 2018, 07:10:14 PM »

Yes, fps override 24fps.
Gonna do some fast tests here from suggestions above. Unfortunately I don´t have the time I want for this atm. But hey, who´s in a hurry right

Need to go out for a while...

alpicat · « **Reply #1561 on:** July 03, 2018, 07:19:24 PM »

I've been using 23.98fps override. Works well but I think the video is coming out darker than what I recorded, so I have to increase the exposure in post to compensate. I don't know if I'm doing something wrong, will test further including shooting at 25p. I can confirm that the sd uhs hack functions properly though - recording is fully continuous. Also it's definitely 3x3, if it were 3x5 I'd be getting a lot more moire!

EDIT: my bad, exposure is fine - my monitor brightness was turned right down so everything was looking dark.

@IDA_ML definitely need to try doing timelapses with the higher resolutions, I'll need a tripod for that though!

Danne · « **Reply #1562 on:** July 04, 2018, 12:00:05 AM »

Quote from: a1ex on July 03, 2018, 06:43:51 PM

Trying to add support for different frame rates; currently it's hardcoded to 25p; was the sample clip recorded with FPS override at 24?

One puzzle I'd like you to solve: what is the minimal value of timer A that still gives valid image? (without borders on the right side)

Code from fps-engio.c suggests 520 = 0x208. That means, in this block, use 0x207 instead of 0x27f (the hardware expects timerA - 1):

Code: [Select]
case 0xC0F0600c: return 0x27f027f; case 0xC0F06008: return 0x27f027f; case 0xC0F06010: return 0x27f;
If 520 doesn't work, try something higher, until 640. If 520 works, try 510 or so - it should break.

Binning factors ~~and vertical resolution override~~ can be updated from raw_info_update_cbr, ~~so raw.c can stay untouched~~. Will post a patch soon.

Not sure what to test here but following and adding following doesn´t change anything with performance:

Code: [Select]

        case 0xC0F06014: return 0x7cf;
		case 0xC0F0600c: return 0x207027f;
		case 0xC0F06008: return 0x207027f;
		case 0xC0F06010: return 0x207;
		case 0xC0F37014: return 0xe;

In fps-engio.c changing:

Code: [Select]

#elif defined(CONFIG_EOSM)
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN (ZOOM ? 716 : MV1080CROP ? 532 : 520)

to this doesn+t change anything:

Code: [Select]

#elif defined(CONFIG_EOSM)
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN (ZOOM ? 716 : MV1080CROP ? 532 : 520)

Not even this:

Code: [Select]

#elif defined(CONFIG_EOSM)
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN (ZOOM ? 716 : MV1080CROP ? 532 : 500)

Am I following correctly, couldn´t get it to break anyway.

theBilalFakhouri · « **Reply #1563 on:** July 04, 2018, 12:07:55 AM »

Different frame rates from Canon 700D in mv1080:

30FPS:

Code: [Select]

C0F06014 = 0x7e6
C0F06008 = 0x20f020f
C0F0600c = 0x20f020f
C0F06010 = 0x20f
C0F0713C = 4a7
C0F07150 = 46a

25FPS:

Code: [Select]

C0F06014 = 0x7cf
C0F06008 = 0x27f027f
C0F0600c = 0x27f027f
C0F06010 = 0x27f
C0F0713C = 4a7
C0F07150 = 475

23.976FPS:

Code: [Select]

C0F06014 = 0x9de
C0F06008 = 0x20f020f
C0F0600c = 0x20f020f
C0F06010 = 0x20f
C0F0713C = 4a7
C0F07150 = 46a

Edit: added the head timers also.

a1ex · « **Reply #1564 on:** July 04, 2018, 12:14:26 AM »

Quote from: Danne on July 04, 2018, 12:00:05 AM

Not sure what to test here but following and adding following doesn´t change anything with performance:
Code: [Select]
case 0xC0F06014: return 0x7cf; case 0xC0F0600c: return 0x207027f; case 0xC0F06008: return 0x207027f; case 0xC0F06010: return 0x207; case 0xC0F37014: return 0xe;

It's late, try using find/replace. It won't affect performance in any way; it will affect rolling shutter and available frame rates. I'm only asking about the lowest value that still gives valid image (not asking about performance).

You don't have to change anything in fps-engio.c. Just in that block. To change the values, use a hex calculator or write the constants in decimal, e.g. (x << 16) | x.

Danne · « **Reply #1565 on:** July 04, 2018, 12:38:20 AM »

Ok, thanks for clarifying. Will find time asap.
Another thing. Just played around with 100D values which gives me 42 fps in mv1080p and simply added them to eosm. At least in 3x3_mv1080p mode I can crank fps override to 38 fps. Not bad for this tiny cam.

Added this to eosm:

Code: [Select]

    #define FPS_TIMER_A_MIN (ZOOM ? 676 : MV1080CROP ? 540 : 520)
    #define FPS_TIMER_B_MIN (ZOOM || MV1080 || MV1080CROP ? 1288 : MV720 || (lv && lv_dispsize==1 && !is_movie_mode()) ? 990 : 1970)

38 fps file
https://bitbucket.org/Dannephoto/magic-lantern/downloads/38fps_10frames.MLV

alpicat · « **Reply #1566 on:** July 04, 2018, 01:29:47 AM »

That's so cool it can do 38fps!
Here's my first test with mv1080, really happy with the results

a1ex · « **Reply #1567 on:** July 04, 2018, 09:36:06 AM »

Having trouble finding some magic numbers:

- default timer B and exact frame rate in x5 zoom (timer A is 716); can be found in the FPS override submenu, with FPS override turned off
- default timer B in 1080p crop modes (timer A is either 546 or 640); guess: 2444/2445 in 24p, 2000 in 25p, 1955/1956 in 30p; please confirm
- default value of C0F06084 in adtg_gui right after startup (without starting to record H.264 and without enabling FPS override or crop_rec)

Caveat: timer B might not be fixed, but might alternate between two values (e.g. in 24p it's either 2527 or 2528). If that happens, please write both values.

Will edit as I'll need more values.

Danne · « **Reply #1568 on:** July 04, 2018, 09:56:47 AM »

Quote

- default timer B and exact frame rate in x5 zoom (timer A is 716); can be found in the FPS override submenu, with FPS override turned off

FPS timer B 1491
Actual FPS 29.975

Edit 1: retest shows the same numbers

Quote

- default timer B in 1080p crop modes (timer A is either 546 or 640); guess: 2444/2445 in 24p, 2000 in 25p, 1955/1956 in 30p; please confirm

~~I only got 3x3_mv1080_EOSM crop mode (regarding 1080p crop modes)~~
FPS timer A 640
FPS timer B 2000

Edit 1:
retest: Movie crop mode set and:
2444/2445 in 24p confirmed
2000 in 25p confirmed
1955/1956 in 30p confirmed

Quote

default value of C0F06084 in adtg_gui right after startup (without starting to record H.264 and without enabling FPS override or crop_rec)

without enabling RAW video or anything else enabling latest adtg_gui:
0xa601d4

Edit 1:
C0F06084 when starting cam with nothing enabled:
0x0

Quote

C0F06084: did that show up with previous adtg_gui, before commit 0a2e116? Please write context info for this one as well (the fine print at the bottom of screen). Also, 0xa6 is way too small, please double-check.

Tested june 21 build in adtg_gui and could not get the C0F06084 to show up.

Quote

Caveat: timer B might not be fixed, but might alternate between two values (e.g. in 24p it's either 2527 or 2528). If that happens, please write both values.

Not sure about this one but when checking directly when starting cam:
FPS timer B 2022

Edit 1:
Timer B alterations while recording H.264:
24 fps either 2527 or 2528 confirmed
30 fps either 2022 or 2023
25 fps either 2000

a1ex · « **Reply #1569 on:** July 04, 2018, 10:03:42 AM »

1080p crop modes: from Canon firmware, not crop_rec (movie crop hack). In crop_rec we fill in our own values, I can read them from the source.

C0F06084: did that show up with previous adtg_gui, before commit 0a2e116? Please write context info for this one as well (the fine print at the bottom of screen). Also, 0xa6 is way too small, please double-check.

FPS timer B: when starting the camera it's always 2022? it never goes to 2023?

You need to record H.264 to get most of the FPS modes; remember that EOS M stays in 720p30 during standby.

To be clear, I want you to fill in the missing values from this post (ignore SHUTTER; it's no longer used):

Quote from: coutts on November 27, 2012, 10:58:24 PM

FPS register values (for enabling FPS control in ML). posting it here so it's documented somewhere.

Code: [Select]
NTSC: LV (and all non-recording modes): TIMER_A: 0x20f020f TIMER_B: 0x7e5 / 0x7e6 [changes between the 2 twice a second] SHUTTER (1/60): 0x3B2 (same in all recording modes too) Recording: 1080p 30fps: - same as LV conditions 1080p 24fps: TIMER_A: 0x20f020f TIMER_B: 0x9de / 0x9df 720p 60fps: TIMER_A: 0x20f020f TIMER_B: 0x3f2 / 0x3f3 480p 30fps: - same as LV conditions PAL: LV (and all non-recording modes): TIMER_A: 0x20f020f TIMER_B:0x7e5/0x7e6 SHUTTER (1/100): 0x25e Recording: 1080p 25fps: TIMER_A: 0x27f027f TIMER_B: 0x7cf (doesn't change) SHUTTER: 0x1f4 1080p 24fps: TIMER_A: 0x20f020f TIMER_B: 0x9de / 0x9df SHUTTER: same as lv 720p 50fps: TIMER_A: 0x27f027f TIMER_B: 0x3e7 (doesn't change) SHUTTER: 0x1f4 480p 25fps: TIMER_A: 0x27f027f TIMER_B: 0x7cf SHUTTER: 0x1f4

Danne · « **Reply #1570 on:** July 04, 2018, 10:11:25 AM »

I get on it tonight. Hooked up here atm

Thanks.

theBilalFakhouri · « **Reply #1571 on:** July 05, 2018, 06:50:56 PM »

Quote from: a1ex on July 02, 2018, 05:55:48 PM

BTW...

Confirmed on 60D - latest adtg_gui is able to lock the zoom factor between x5 and x10 (so the image no longer doubles). Procedure: simply locking the registers modified between x5 and x10. As expected, this doesn't work on 5D3.

Screenshot: 60D registers specific to x5 (the "was" values are from x10).

And here the registers for 700D (overridden x10 in x5) and of course the image no longer doubles it stays x10 in x5 so it's working on DIGIC 5 and maybe 5D3 has different case ?

The last two registers are related to each other you can break the image in the first one and fix it in the second (I can change the preview position with these registers in x10 but not in x5):
C0F118E0
C0F118E4

Is there better way (QEMU?) to understand these registers instead of overriding and guessing what it does ? because sometimes it's really hard to find the relationships between these.

I am pretty sure this register for fixing stretched LiveLivew in EOS M when enabling mv1080 and in other cameras when enabling 3x3 in 720p 50/60fps:

C0F11BCC = 0x50009 in mv1080 | 0x400045 in mv720

The proof: I changed [ADTG]800c to 0x4 in mv1080 so I have now stretched LiveView (white bar in the bottom the stretched LiveView to the top other wise the stretched LiveView to the bottom when enabling 3x3) then I copied the register value from mv720 in mv1080,, and the LiveView back to the normal.

Edit before releasing: the LiveView back to the stretched when recording H.264 (not our case now because we will record RAW and this will not affect the LiveView maybe but this means there are more registers to find) .

The Proof 2: I tried all other registers to solve stretched LiveView one by one with no success (from mv1080 registers values to mv720).

The problem: LiveView will stuck when copying the register value from mv1080 into mv720 and I don't know why $:-\$ .

dfort · « **Reply #1572 on:** July 06, 2018, 08:08:59 AM »

Maybe not the most exciting discovery but a while back I was looking at some stubs and found a few that might be off. Anyone care to look into these before I make the pull request?

Code: [Select]

 /** Events **/
 NSTUB(0xFFA8B8BC - RAM_OFFSET,  TryPostEvent)
-NSTUB(0xFFA8B940 - RAM_OFFSET,  TryPostEvent_end)
+NSTUB(0xFFA8B91C - RAM_OFFSET,  TryPostEvent_end)
 NSTUB(0xFFA8B1DC - RAM_OFFSET,  TryPostStageEvent)
-NSTUB(0xFFA8B260 - RAM_OFFSET,  TryPostStageEvent_end)
+NSTUB(0xFFA8B238 - RAM_OFFSET,  TryPostStageEvent_end)

Code: [Select]

 /** Recursive locks **/
 NSTUB(0xFFA88520 - RAM_OFFSET,  AcquireRecursiveLock)       // AJ_KernelDry_KerRLock.c
-NSTUB(0xFFA73E6C - RAM_OFFSET,  CreateRecursiveLock)
+NSTUB(0xFFA88488 - RAM_OFFSET,  CreateRecursiveLock)
 NSTUB(0xFFA88634 - RAM_OFFSET,  ReleaseRecursiveLock)       // AJ_KernelDry_KerRLock.c_p2

a1ex · « **Reply #1573 on:** July 06, 2018, 10:15:50 AM »

TryPostEvent_end / TryPostStageEvent_end are no longer used; functionality replaced by the dm-spy-experiments branch; I should clean it up a bit, make sure it doesn't break anything (currently it does), make sure it works on all models, and merge it.

CreateRecursiveLock: one of these functions is a wrapper to another. Any of them is fine. TODO: figure out what's up with the SubReset / MainReset thingie; it's used on all DIGIC <= 5 models, but this string is not present in newer ROMs.

EstaDive · « **Reply #1574 on:** July 06, 2018, 06:52:33 PM »

I have a 90EX speedlite that powers off automatically when the camera turns off. Is it possible to disable this feature via ML?

I am using it to trigger external strobes through an underwater housing. The problem is, the flash power button is not accessible via the dive housing, so if the camera powers off (powersave, or I accidentally hit the power button) then the flash is off for the rest of the dive and I can't trigger the strobes.

There does not appear to be a canon native way to disable it. It is a documented feature:
https://support.usa.canon.com/kb/index?page=content&id=ART136735

and there is a way to disable the 5-minute idle power, off, but it doesn't stop the flash from turning off with the camera.

News:

Author Topic: Canon EOS M (Read 1671396 times)

dfort