Canon 70D

[dfort]

Interesting observation -- with ML loaded the screen doesn't switch to mirror display when in "selfie mode." So it looks like the face tracking is trying to track where the face "should" be on the screen which is on the opposite side. I just took a look on my 700D and in "selfie mode" the LiveView image also does not switch to mirror mode with ML loaded. Never noticed this before. (I'm not a blogger and don't take many pictures of myself.)

[yokashin]

Thanks a lot!
I appreciate your hard work!
And I was about to change my 70D to M1

Good luck in further work!

Hell yeah, first 14-bit lossless MLV from 70D!



It's amazing what you know about and can do with closed internals of these cams!

The one to be commented out is

Code: [Select]

//0x5002d,
If too much was commented out (all but first four lines: EDMAC channels and read/write connections) it was still stucking at the same point and additionally locking the camera. LV couldn't be exited. After changing mode between photo/video it thrown Err80.

With only this one line removed I haven't noticed any side effects yet but wasn't focusing on it. I'll test it in the next days/weeks, report back and submit a pull request if all seems to be fine.

[David_Hugh]

Excellent! Let's give this a try:

Code: [Select]

    else if (is_camera("70D", "1.1.2"))
    {
        CMOS_WRITE = 0x26B54;
        MEM_CMOS_WRITE = 0xE92D41F0;
       
        ADTG_WRITE = 0x2684C;
        MEM_ADTG_WRITE = 0xE92D47F0;

Put up a test build on my downloads page. The way to test this is to first turn on only the crop_rec module. Put your camera in 1280x720/50 or 60 (depending if you're set up for PAL or NTSC) and try recording some H.264 video. The LiveView will probably look stretched vertically.

We know that mlv_lite isn't working yet because we need to figure out the lossless recording but maybe mlv_rec will work? You should be able to record video using 3x3 sampling at 60fps. Well, the card will limit how large of an image you can continuously record at that speed but it does give you another option to play with.

@Danne Yes - I believe this build, along with the register changes I described in post 3194 results in a proper crop_rec file. It ONLY works however when it's on the PAL setting, as I also described, 60fps is just too much. I am going through my notes, sorry I can only point to past achievments but it's been almost a year since I played with that stuff.

VERY important note: I could also lower the fps from 50 to around 21fps with this build, but I needed to change TWO, not one register:

c0f0 6014
c0f0 6024

Unfortuntaley I never got behind a way to increase the resolution past the 1824x626 I started with, because I could not manage to find the right registers to change resolution. I remember the cam was very sensitive to the order/way in which the registers were changed - fps changes were stable but every time I tried something else it kept locking up.

Here is what @nikfreak had to say about all this

Hey Dave,

fps override was always problematic for me. TimerA always worked to modify but Timer b was causing problems and disco-like effects on the LCD. Now that you found out that 70D needs two registers for Timer B namely

• c0f06014
• c0f06024

you need to update fps-engio.c to get it working. Just out of my head:

#define FPS_REGISTER_A 0xC0F06008
#define FPS_REGISTER_B 0xC0F06014
#define FPS_REGISTER_B_DUALPIXEL 0xC0F06024

Afterwards "grep" fps-engio.c for all register_b related code and modify it to work for 70D by defining code for it. I would suggest you make a request at bitbucket if you can't handle it yourself but you need that additional register 0xC0F06024 for 70D from what I understand

As always, hope this is helpful.

[Danne]

Two regs? Opening up a can of worms  .
Let's see if we can get a branch going and then I can provide basic guidance building presets.

[nikfreak]

DPAF is stubborn. I guess it has something to do with https://twitter.com/autoexec_bin/status/1038866055278538753

[andy kh]

i got face tracking working in selfie mode

with ML loaded the screen doesn't switch to mirror display when in "selfie mode."

thanks dfort



auto mirroring is set to dont allow by default. it needs to b changed to allow and wala

[dfort]

auto mirroring is set to dont allow by default. it needs to b changed to allow and wala

Great. Tried it on the 700D and it behaves the same.



This is what the ML menus look like with Auto Mirroring turned on and the screen flipped out to "selfie" mode. Canon menus don't flip with or without ML loaded.



I searched the user manual to see if there is a Canon setting to turn this on or off but the only reference to this feature that I could find says:

• During Live View shooting or movie shooting, facing the LCD monitor toward the subject will display a mirror image on the screen.

[andy kh]

This is what the ML menus look like with Auto Mirroring turned on and the screen flipped out to "selfie" mode. Canon menus don't flip with or without ML loaded.

it is the same with mine but face tracking in selfie mode is working flawless now after turning on the auto mirroring and urning off the small hack

[theBilalFakhouri]

Same thing here with my 700D in selfie mode, @dfort So is disabling Auto Mirroring in ML helps?

[dfort]

So is disabling Auto Mirroring in ML helps?

If you want to use face tracking it looks like Auto Mirroring needs to be enabled. Does disabling Auto Mirroring in ML help? Depends. Do you like taking a selfie where left is right and right is left or are you are like Leonardo da Vinci and have a preference for mirror writing?

Seriously though, it is good that ML gives you a choice because apparently Canon doesn't.

[ArcziPL]

Hi, with the actual adtg_gui.mo from https://builds.magiclantern.fm/modules.html "Latest Build (2018-11-11 14:24)" the cam can't enter LV nor video mode if adtg_gui is enabled with "ENGIO registers" = ON. The screen remains black, only battery pull helps.


As a result, I can't do this:

6008 is set only once when entering LiveView, so you should do that with adtg_gui enabled in order to see it. Going to PLAY mode and back, or pressing MENU twice, will do the trick. This register is interesting only if you want to increase horizontal resolution (and you can only do that in 1:1 crop modes).

Any idea? Are older builds available? Unfortunately, I don't see them on builds.magiclantern.fm nor at dforts Bitbucket download page anymore.

[Walter Schulz]

These modules can be loaded on top of the experimental crop_rec_4k build.

Try experimental lua_fix build for 70D instead.

Older semi-nightlies are here: https://builds.magiclantern.fm/jenkins/job/70D.112/ but I don't think you will have any luck with this module using them.

[dfort]

That reminds me, I should cleanup my downloads page and take out the test builds that didn't work. Looks like I already did that for the 70D.

There was a recent update to get lossless compression working on the 70D. However, it was done on the crop_rec_4k branch and as reported by @David_Hugh on Reply #320 that branch won't compile on some cameras including the 70D.

Until that's resolved your best best is lua_fix like Walter suggested.

[ArcziPL]

There was a recent update to get lossless compression working on the 70D. However, it was done on the crop_rec_4k branch and as reported by @David_Hugh on Reply #320 that branch won't compile on some cameras including the 70D.

Yep, I chose crop_rec_4k, as I believed the change would (could?) be propagated to *_mlv_snd and *_mlv_lite_snd but apparently I was wrong. It rather works only the other way round. (?)

[dfort]

Yeah, I'm not sure exactly how to bring in just your change without fiddling around with the merge and possibly messing things up. I made a new branch from crop_rec_4k_mlv_snd and did this on my fork:

Code: [Select]

hg revert -r 20452 lossless.c
But that put my name on your changes which I don't want to do. I think you need to make a branch from before crop_rec_4k_mlv_snd and crop_rec_4k_mlv_lite_snd were branched off of crop_rec_4k and make your changes there.

In any case, back the issue at hand. Simply copy lossless.c from crop_rec_4k into the other branches, compile, add the adtg_gui module from the modules download page and that should give you what you're looking for.

I just tried it and posted it on my downloads page but I don't have a 70D to try it out.

Are you looking into getting crop_rec working? That would be great.

[a1ex]

Yep, I chose crop_rec_4k, as I believed the change would (could?) be propagated to *_mlv_snd and *_mlv_lite_snd

That's correct. Only audio changes should go directly into *_mlv_snd and *_mlv_lite_snd, if you ask me. Other crop_rec changes should go in crop_rec_4k and synced with *_mlv_snd and *_mlv_lite_snd by merging. That would allow me to review the audio changes separate for the other stuff.

but apparently I was wrong. It rather works only the other way round. (?)

Sorry, changes not following this (i.e. after 3e4294d) are not mine...

Yes, I need to figure out how to fix 700D and EOS M (or back out these changes - 046e388, 58d6735, 1d493af, d556a10 - and rework all my local updates without them).

However, it was done on the crop_rec_4k branch and as reported by @David_Hugh on Reply #320 that branch won't compile on some cameras including the 70D.

Yes, 32ac2f1 should have been done in crop_rec_4k. Then, 70D also needs FRAME_SHUTTER_BLANKING_READ (i.e. the memory address of the shutter blanking register, as printed in adtg_gui). On some models, this address is a moving target, though, so we need to find another way to retrieve it.

Or, we could abandon the recent shutter speed refactoring (i.e. revert 046e388, 58d6735, 1d493af, d556a10 and keep shutter speeds broken on most cameras). I need these changes set to make sure the dialed shutter speed also matches what you get after using various crop_rec presets (otherwise you end up with all sorts of weird values, just not what you dialed). That's because shutter speeds are affected by FPS timers, which we override in crop_rec. My further local changes on crop_rec_4k depend on this refactoring, and I don't want to commit them in a non-working state.

[ArcziPL]

I could not see/find a C0F0 [6008], but a C0F0 [6014] and [6024] which had the same value. I needed to change BOTH of them in order for the image not to freeze. In this manner, I was able to lower the fps in the crop_rec module AND in regular 1080p, but I could only lower fps, not increase.

Bingo, good work David_Hugh! This opens the doors to FPS override on 70D. I already adapted fps-engio.c to always set both registers for Timer B adjustments according to your find. Result: FPS override finally works (ok, kind of, still one issue to be solved) and lossless compressor for MLV broke again.

fps-engio.c

Code: [Select]

@@ -45,6 +45,7 @@
 
 #define FPS_REGISTER_A 0xC0F06008
 #define FPS_REGISTER_B 0xC0F06014
+#define FPS_REGISTER_B_DUAL_PIXEL 0xC0F06024
 #define FPS_REGISTER_CONFIRM_CHANGES 0xC0F06000
 
 #define PACK(lo, hi) ((lo) & 0x0000FFFF) | (((hi) & 0x0000FFFF) << 16)
@@ -52,6 +53,7 @@
 #define FPS_REGISTER_A_VALUE ((int) shamem_read(FPS_REGISTER_A))
 #define FPS_REGISTER_A_DEFAULT_VALUE ((int) shamem_read(FPS_REGISTER_A+4))
 #define FPS_REGISTER_B_VALUE ((int) shamem_read(FPS_REGISTER_B))
+#define FPS_REGISTER_B_DUAL_PIXEL_VALUE ((int) shamem_read(FPS_REGISTER_B_DUAL_PIXEL))
 
 #ifdef CONFIG_7D
 uint32_t *buf = NULL;
@@ -485,10 +487,7 @@
     float shutter = frame_duration * (max - blanking) / max;
     return (int)(1.0 / shutter * 1000);
 
-// ToDo: Cleanup 70D once fps override feature is fixed
-// till then use the fallback. Do it this way to have fast ettr
-// and keep frame_shutter timer enabled in consts.h
-#elif defined(FRAME_SHUTTER_TIMER) && !defined(CONFIG_70D)
+#elif defined(FRAME_SHUTTER_TIMER)
     int timer = FRAME_SHUTTER_TIMER;
 
     #ifdef FEATURE_SHUTTER_FINE_TUNING
@@ -750,6 +749,7 @@
         timerB -= 1;
         written_value_b = PACK(timerB, fps_reg_b_orig);
         EngDrvOutFPS(FPS_REGISTER_B, written_value_b);
+        EngDrvOutFPS(FPS_REGISTER_B_DUAL_PIXEL, written_value_b);
         fps_needs_updating = 0;
     #if defined(NEW_FPS_METHOD)
     }
@@ -1050,6 +1050,7 @@
         written_value_b = 0;
         EngDrvOutFPS(FPS_REGISTER_A, fps_reg_a_orig);
         EngDrvOutFPS(FPS_REGISTER_B, fps_reg_b_orig);
+        EngDrvOutFPS(FPS_REGISTER_B_DUAL_PIXEL, fps_reg_b_orig);
         EngDrvOutFPS(FPS_REGISTER_CONFIRM_CHANGES, 1);
     }
 }
@@ -1651,6 +1652,7 @@
     {
         EngDrvOutLV(FPS_REGISTER_A, fps_timerA_override);
         EngDrvOutLV(FPS_REGISTER_B, fps_timerB_override);
+        EngDrvOutLV(FPS_REGISTER_B_DUAL_PIXEL, fps_timerB_override);
         EngDrvOutLV(FPS_REGISTER_CONFIRM_CHANGES, 1);
     }
     fps_timers_updated = 1;

features.h

Code: [Select]

@@ -11,7 +11,7 @@
 // Tried it for a felt hundred hours
 // TIMER_B has untraceable problems
 // Using TIMER_A_ONLY causes banding / patterns
-#undef FEATURE_FPS_OVERRIDE
+// #undef FEATURE_FPS_OVERRIDE
 
 /* see comments in lens.c */
 #undef FEATURE_FOLLOW_FOCUS

internals.h

Code: [Select]

@@ -125,8 +125,11 @@
 /** FIO_RenameFile works **/
 #define CONFIG_FIO_RENAMEFILE_WORKS
 
-// FPS updates from evf state do not work atm on 70D
-// #define CONFIG_FPS_UPDATE_FROM_EVF_STATE
+// FPS override: change timers from EVF state */
+#define CONFIG_FPS_UPDATE_FROM_EVF_STATE
 
 #define CONFIG_REC709
 


The cam doesn't lock-up anymore and doesn't show any funny effect on LCD when trying FPS override in LV. But the overriden FPS value shortly jumps to the default one every 2s. I think ML task does something with this interval. It also jumps shortly to default FPS for every navigation key pressed when in video tab. This is with no modules loaded. Here see how it looks:
https://youtu.be/ZnNLZ6sgp7Y


But you can nicely increase LCD visibility at night and MLV recording also works with the overriden FPS. However bitrate shown during recording is wrong, it shows just bitrate which would be true with default FPS. And also recording time is counting slower. Seems that the mlv_lite module doesn't get the right overriden FPS value for calculations.

Which function is called approx. every 2s when staying in menu? I must analyze it in details to see what causes the short glitch. Actually the first question shall be: does this value really change only for a short moment when ML is doing something or does ML realize it only after 2s from the moment when other piece of code changes it? As LV is showing permanent FPS override I hope for the first one.

During initial testing, the FPS was also getting back to default value after few first frames during recording. This seems to not happen anymore, I believe after changing the FPS update mode by  #define CONFIG_FPS_UPDATE_FROM_EVF_STATE in internals.h. But I haven't tested enough.

Here a build, so you can test as well. Feedback very welcome!

https://bitbucket.org/ArcziPL/magic-lantern/downloads/magiclantern-Nightly.2019Mar15.70D112_crop_rec_4k_mlv_lite_lossless_fps_override_experimental.zip

And for everyone, who gets "ISOless err xx" when trying to use DualISO, here a modified module with alternative adresses (just move it to ML/modules):
https://bitbucket.org/ArcziPL/magic-lantern/downloads/70d_dual_iso_alternative_adress.zip

As already mentioned above, enabling FPS override caused lossless compressor to break again. I had to remove one more resource to make it work again.

Code: [Select]

+    else if (is_camera("70D", "*"))
+    {
+        uint32_t resources[] = {
+            0x00000 | edmac_channel_to_index(edmac_write_chan),
+            0x10000 | edmac_channel_to_index(edmac_read_chan),
+            0x30001,    /* Read connection 1 (uncompressed input) */
+            0x2002d,    /* Write connection 45 (compressed output) */
+          //0x20016,    /* Write connection 22 (for WR2 - not used) */
+            0x50034,
+          //0x5002d,    /* workaround, TTL_Prepare stucks otherwise if called in LV */
+          //0x50010,    /* workaround, TTL_Prepare stucks otherwise if compiled with FEATURE_FPS_OVERRIDE defined */
+            0x90001,
+            0x230000,
+            0x160000,
+            0x260000,
+            0x260001,
+            0x260002,
+            0x260003,
+        };

Then, 70D also needs FRAME_SHUTTER_BLANKING_READ (i.e. the memory address of the shutter blanking register, as printed in adtg_gui). On some models, this address is a moving target, though, so we need to find another way to retrieve it.

On my cam it is different than the already present entry in crop_rec_4k_mlc_* which is commented out because of some reason.

Code: [Select]

// see "Malloc Information"
// #define FRAME_SHUTTER_BLANKING_ZOOM   (*(uint16_t*)0x40452180) // ADTG register 805f
// #define FRAME_SHUTTER_BLANKING_NOZOOM (*(uint16_t*)0x40452184) // ADTG register 8061

#define FRAME_SHUTTER_BLANKING_READ   (lv_dispsize > 1 ? FRAME_SHUTTER_BLANKING_NOZOOM : FRAME_SHUTTER_BLANKING_ZOOM)
#define FRAME_SHUTTER_BLANKING_WRITE  (lv_dispsize > 1 ? &FRAME_SHUTTER_BLANKING_ZOOM : &FRAME_SHUTTER_BLANKING_NOZOOM)
BTW: why does FRAME_SHUTTER_BLANKING_WRITE use swapped order of ZOOM and NOZOOM registers?! For other cams it looks same...

On my cam I see the following adresses:

Code: [Select]

805f: 0x404e6180
8061: 0x404e6184
How to see if the shutter_blanking is working or not at all? I've tried uncommenting and replacing with my two addresses but couldn't tell any difference...

[andy kh]

goo job ArcziPL. this is fantastic

[DeafEyeJedi]

Great work @ArcziPL & @dfort! Also thanks @a1ex for pointers to get this 70D revived yet once again!

[ArcziPL]

[Here was some pointless whining but I removed it, as it was pointless. I'm on track, analyzing what happens and there will be no whining anymore, promise. ]

I see that fps_get_current_x1000() is called several times per second in video LV and only in 1 out of 4 cases returns the expected (=override) value. Three others are the default FPS. Need to find out if it's Canon or ML, who keeps overriding the FPS back to default (or maybe just the readback is wrong?).

Next step was to keep FPS override turned off and call  fps_setup_timerA() + fps_setup_timerB() once from run_test(), followed by fps_get_current_x1000().

Result without CONFIG_FPS_UPDATE_FROM_EVF_STATE:
- 700D: after one frame the FPS is back to default
- 70D: same

Result with #define CONFIG_FPS_UPDATE_FROM_EVF_STATE:
- 700D: keeps FPS after one call
- 70D: LV and h264 recording stay overriden but fps_get_current_x1000() returns default FPS

Next step: tried to strip vsync_func() from everything but calling fps_update_timers_from_evfstate() but it didn't change anything.

Next step: try to reduce fps_task() to the absolute required minimum. This is still ongoing.

[ptec]

Just want to let you know what issues I have if not known already:

Autofocus (Face Recognition) does not work. If I move my head to the left, the autofocus field moves to the right and vis versa. Strange phenomen (35mm 1.4).
NO ML -> Works fine.

I cant use Eos Utility to monitor liveview or push the shutter. Says "busy" all the time.
When I skipp ML on Startup it works fine.

[andy kh]

@ptec
See my reply #3280
Also turn off small hacks
Enjoyyy