Canon 650D / T4i

[anisdimeji]

Hi Guys,

I installed Magic Lantern on my Canon T4i but faced with few challenges

1. The magic zoom feature flickers, please what should i do to stop this distraction?

2. When I connect the OEM cable from Canon (Usb-->RCA) into the USB Port, the LCD Screen went blank, what can I do to make the screen come up and monitor the sound?

3. Why is the lua function not loading on my camera (canon t4i)

[saulbass]

There's been lots of changes on the crop_rec_4k and crop_rec_4k_mlv_lite_snd branches.

The 650D is in these branches but there are no builds available on the Experiments downloads page because there are some issues with lossless compression that still need to be worked out. If you want a preview of coming attractions I put up a test build on my downloads page. Who knows, maybe we got lucky?

Maybe not so lucky with the lossless compression on the 650D. Otherwise looking good.

Using dforts experimental - 'crop_rec_4k_mlv_lite_snd.2018Feb04.650D104' from 3 weeks ago.

Results based on the fastest SD card that I can find a 32GB SanDisk Extreme Pro 95Mb/s formatted using ExFAT.
Testing with the dforts Feb 4th build: mlv_lite crop_rec modules only and setting the canon menu to 1080p.

With this build I can get a firm 165 frames at 1920x1080 10bit uncompressed. The picture via MLV App v0.14 looks great. Fantastic!

If I switch to 1920x1080 11-8bit lossless I can still only get a few seconds but the picture has become flawed - presumably there are still problems with the lossless codec on the 650D.

I've tried every combination of 10,12,14 lossless vs 10,12,14 uncompressed and all the compressed lossless clips have the same alternate scanline problem as above.

In other settings I can get 1736x976 10bit - I can get perfect pictures again for slightly longer: 331 frames but at a lower resolution.

At this resolution if I switch to 10bit lossless I can record continuously but with similar critical compression issues as above.

If dfort thinks it helpful please PM me and I can send some mlv samples.

Very happy with what's there, the MLV App v.0.14 seems to have defeated the focus pixel problem at all these resolutions.

Thanks guys.

Attached is sample of lossless problems.

[dfort]

@saulbass - Thanks for testing. The 650D seems to be in the same state that is was when it was merged into the crop_rec_4k branch. Let's check and see if any of the commits made since Feb. 4 made any difference--probably not but still worth checking. In addition, the 650D hasn't been run through this test that might help. I put up the test builds on my downloads page.

I'd like to see your test MLV's but I'm no expert on how to figure out what went wrong or how to fix them. Best if you could upload them to a site and share with everyone instead of doing via PM with just me. Besides, I got called in to work this week so I won't have much time to look at it.

[saulbass]

@saulbass - Thanks for testing. The 650D seems to be in the same state that is was when it was merged into the crop_rec_4k branch. Let's check and see if any of the commits made since Feb. 4 made any difference--probably not but still worth checking. In addition, the 650D hasn't been run through this test that might help. I put up the test builds on my downloads page.

I'd like to see your test MLV's but I'm no expert on how to figure out what went wrong or how to fix them. Best if you could upload them to a site and share with everyone instead of doing via PM with just me. Besides, I got called in to work this week so I won't have much time to look at it.

dfort - thanks for the reply.
I have tried the two builds that you posted:
crop_rec_4k.2018Feb25.650D104.zip
crop_rec_4k_mlv_lite_snd.2018Feb25.650D104.zip
but the errors still appear in the lossless compressed versions.

I also had a go with the console tests you described using allocate-raw-lv-buffer.2018Feb25.650D104.zip
and posted these on the https://www.magiclantern.fm/forum/index.php?topic=5601.1600
but not entirely certain I know what I'm doing here.

[saulbass]

These images are using dfort's - crop_rec_4k.2018Feb25.650D104.zip filming a gradient offscreen - using 14bit lossless & 14bit uncompressed - locked off camera - frames exported from MLVAPP0.14 as tiff - then averaged to a single frame each - overlaid with difference - I've uploaded these here at jpgs. There is a 73 pixel descending pattern in the lossless version with a horizontal repeat at about 144 pixels which might be double 73(ish). There is a 6 pixel micro pattern there too - not sure if any of this of help - there seems to be some kind of regularity in the pattern - I seem to recall that jpeg works off 7 pixel quadrants but I might be hopelessly out of my depth. Anyway if it helps...

[a1ex]

Pixel counting:
- video frame: 1736x976
- CR2 full size: 5280x3528
- best guess: some image processing modules are configured for width=5280, but receive width=1736 as input
- let's render a gradient image like that:

Code Select Expand


octave:1> x = 1:5280; y = 1:3528;
octave:2> [x,y] = meshgrid(x,y);
octave:3> g = x+y;
octave:4> imwrite(g / max(g(:)), 'gradient.png');
octave:5> h = reshape(g'(1:1736*976), [1736 976])';
octave:6> imwrite(h / max(h(:)), 'wrong-width.png');
# the reverse transformation would be:
# r = reshape(h'(1:5280*320), [5280 320])';




A better match can be obtained with x = 1:5280/2 (reason: Canon code reads the image in two half-width slices, while ML reconfigures them as full width). So, a better hypothesis would be: Canon's image processing hardware is configured for width=2640, but receives input with width=1736.



=> start reading here for a possible solution (possibly fixable just by tinkering with the code until it works).

In particular, either look at the differences between 650D and 700D (though none of them refer to registers related to image width, but might enable some additional processing that depends on image size), or try adjusting the width registers, as done on 5D3 and 6D (search for A4F in the logs, as 0xA4F+1 = 2640).

What I'm wondering: what kind of processing is done by the lossless encoder, that depends on image width?! (besides the encoding itself, which is not supposed to change the image content in any way)

Also wondering: what lossless compression rates are you getting on 700D, EOSM and 100D? Do they depend on horizontal resolution? (a bit off-topic, but pretty sure dfort is reading). I'd expect bad compression rates if the declared width does not match the actual image width (but that won't affect decoding).

[saulbass]

A1ex - amazing! - the cadence of your block gradient calculated image is an EXACT match to the compression artefacts in my 14lossless 1736x976 image (650D) that I posted yesterday.

It's interesting that the correlations are so exact.





free image hosting no sign up

[saulbass]

A1ex - I've done 4 tests - the first a repeat of the 1736x976 but with different compression settings. It's worth noting that the live view appears to darken as I step through from 14LL 12LL 11-8LL - not sure if this is normal behaviour but it seems that the settings in the mlv-lite and what the live_view shows may be connected.

All tests on a 650D with dfort's:crop_rec_4k.2018Feb25.650D104

I've also overlaid some screen measurements of the compression artefacts which significantly remain geometrically the same with differing compression levels but do change with changing overall image geometry as the next posts demonstrate - which is what you suggested above. Again I've no idea if any of this is helpful. The original image is a grey defocused swatch which makes it much easier to see what the compression is doing to the 650D image.

Thanks again. I've no idea how you get to think about this in the way that you do - I suppose you somehow see the numerical relations.





1736x976 1080p mlvlite





1736x584 720p mlvlite





1920x1080 720p croprec 3x3 z5




online print screen


2520x1080 720p croprec 3x3 z5

Hopefully these tests with different 650D mlv capture geometry will reveal some more of the numerical relations that you managed to identify in the first 1736x976 test.

I have the 16bit tiffs if required.

[dfort]

Got a new test build that might be working on the 650D. Lossless silent stills might still be a problem but mlv_lite should be working.

https://www.magiclantern.fm/forum/index.php?topic=18443.msg198021#msg198021

[saulbass]

Latest on Canon 650D
Using a fast ExFat SD card and dfort and a1ex's (plus everyone else involved) recent crop_rec_4k.2018Mar04.650D104

Recording Durations - timings show when the camera stopped recording except on two occasions when I stopped after one minute. No sound.

1080p (1736x976) 24fps - 14bit uncompressed 116 frames
1080p (1736x976) 24fps - 12bit uncompressed 159 frames
1080p (1736x976) 24fps - 10bit uncompressed 320 frames
1080p (1736x976) 24fps - 14bit lossless 1062 frames - 44 seconds.
1080p (1736x976) 24fps - 12bit lossless - At least 1 minute - I manually stopped the recording.
1080p (1736x976) 24fps - 10bit lossless - At least 1 minute - I manually stopped the recording.
1080p CrpRec (1920x1080) 24fps - 14bit uncompressed - 65 frames
1080p CrpRec (1920x1080) 24fps - 12bit uncompressed - 104 frames
1080p CrpRec (1920x1080) 24fps - 10bit uncompressed - 163 frames
1080p CrpRec (1920x1080) 24fps - 14bit lossless - 182 frames
1080p CrpRec (1920x1080) 24fps - 12bit lossless - 433 frames - 18 seconds.
1080p CrpRec (1920x1080) 24fps - 10bit lossless - 1333 frames - that's 55 seconds! (2.35Gb)
1080p CrpRec (2520x1080) 24fps - 10bit lossless - 193 frames

Same exposure levels - no pink frames on extreme highlights.

Silent DNG and Silent L-DNG both working - no colour shifts.

This in conjunction the excellent MLVApp0.14 (so no visible focus pixels) represents something of a landmark for my lowly 650D which can now record nearly a minute of continuous 1080p 24fps 10bit Raw. Happy days.

truly the ML guys rwk

[saulbass]

Using a fast ExFat SD card and dfort crop_rec_4k.2018Mar05.650D104.

All working as far as my limited testing goes.

Recording durations - timings show when the camera stopped recording except on three occasions when I manually stopped after one minute. No sound.

This new build shows:
1080p (1736x976) mode with slightly longer recording times,
while the 1920x1080 crop mode is a mixed bag, small improvements and one substantial worsening (1920x1080 crop mode 10bit lossless.)

1080p (1736x976) 24fps - 14bit uncompressed 115 frames - marginal change
1080p (1736x976) 24fps - 12bit uncompressed 167 frames - marginal change
1080p (1736x976) 24fps - 10bit uncompressed 330 frames - marginal change
1080p (1736x976) 24fps - 14bit lossless At least 1 minute - I manually stopped the recording. - BETTER!
1080p (1736x976) 24fps - 12bit lossless At least 1 minute - I manually stopped the recording. similar
1080p (1736x976) 24fps - 10bit lossless At least 1 minute - I manually stopped the recording. similar
1080p CrpRec (1920x1080) 24fps - 14bit uncompressed -    72 frames slight improvement
1080p CrpRec (1920x1080) 24fps - 12bit uncompressed -    104 frames - same
1080p CrpRec (1920x1080) 24fps - 10bit uncompressed -    163 frames - improvement
1080p CrpRec (1920x1080) 24fps - 14bit lossless -    180 frames - slightly worse
1080p CrpRec (1920x1080) 24fps - 12bit lossless -    380 frames - slightly worse
1080p CrpRec (1920x1080) 24fps - 10bit lossless -    915 frames - worse (from 1333 frames).

I'll do the sample images tomorrow.

@a1ex - what test did you want me to do? dfort messaged me but I cant follow what test you are looking for. Thanks.

[dfort]

The difference from the previous build was the addition of the DEFAULT_RAW_BUFFER_SIZE that I took from this test.

Code Select Expand

#ifdef CONFIG_650D
#define DEFAULT_RAW_BUFFER MEM(0x25B00 + 0x3C)
#define DEFAULT_RAW_BUFFER_SIZE (0x47F00000 - 0x46798080)
#endif


I didn't think it would make much of a difference but worth checking to make sure things didn't get worse.

while the 1920x1080 crop mode is a mixed bag, small improvements and one substantial worsening (1920x1080 crop mode 10bit lossless.)
...
1080p CrpRec (1920x1080) 24fps - 10bit lossless -    915 frames - worse (from 1333 frames).

That actually isn't much of a difference. Note that lossless compression is variable so it depends on your subject, exposure, sensor noise, etc. If you try recording several clips using the same settings you're likely to get different lengths even when shooting in the same conditions. That's what happens when you try flying too close to the sun.

[saulbass]

@dfort - thanks of course you are correct!


Some recent 650D sample files as requested using - dforts: crop_rec_4k.2018Mar05.650D104

1. Silent Simple

650D 1080p simple DNG NoMlvLite Or CropRec loaded.dng
650D 1080p simple LDNG NoMlvLite Or CropRec loaded.dng
These will be on the following link for about 5 days. If anyone needs them after that i.e. after 14/3/2018 PM me.
https://wetransfer.com/downloads/f0fb7507f2ce14e1941d5d5ef1b7d0af20180308235844/c092bfd652910657811675c5ac7703b920180308235844/edf0cd

The resolution has gone from 1736x976 > 1736x1158 - not sure why. I rechecked and it went back to 976 - some knob-related confusion no doubt.
Anyway they look fine. Tried to capture a strong highlight.

2. FRSP

Also here are two FRSP dngs one lossless the other compressed. They look fine. Res 5208x3476
These will be on the following link for about 5 days. If anyone needs them after that i.e. after 14/3/2018 PM me.
https://wetransfer.com/downloads/190daac0b1f6b3aa02bf40daa4a7db0620180309043604/cda99f2fcc65521ebc0d19f3a189025820180309043604/484ae7

FRSP5208x3476_650D_UNC.dng
FRSP5208x3476_650D_LLESS.dng

As before build is crop_rec_4k.2018Mar05.650D104

3. MLVS lossless and uncompressed.

Finally 4 short mlvs. 500MB approx.

650D1080pCropRec1920x1080un14bit.mlv
650D1080pCropRec1920x1080LLess14bit.mlv
650D1080p1736x976un14bit.mlv
650D1080p1736x976LLess14bit.mlv

They look fine - titles explain it all. tried to make these as small as possible.

These will be on the following link for about 5 days. If anyone needs them after that i.e. after 14/3/2018 PM me.
https://wetransfer.com/downloads/bcd8179dd72c3edece83509355491ed820180308235937/fa2f890c986b266b9b1df9862c51d89e20180308235937/764962

Thanks again for everyones amazing work.

@a1ex - if there's any additional testing you'd like me do, let me know. I'm afraid I can't do any coding or scripting though.

[saulbass]

So,
Here are two more DNG test files.
This time silent & crop-rec on 650D - using - dforts: crop_rec_4k.2018Mar05.650D104

650D 720pCropRec SimpleDNG 2520x1082 Uncompressed

650D 720pCropRec SimpleDNG 2520x1082 LossLess

They look fine.

Will be available for a week from this site - PM me if you need them after that:

https://wetransfer.com/downloads/89d0be71f9cc9c17a5b9498bc4c817e620180309163835/12ad94a9cb23c2f738f6e6525bcbf39220180309163835/256e0b

Let me know if there's anything else needed.

[saulbass]

just wondering if it is possible to remove the flickering live view overlay (bottom right) that persistently appears on the 650D whenever live view is activated as it obscures the menus. Appreciate this is something of a first world problem and maybe a limiting factor of these smaller canons but I was looking at some of the 700D screen dumps and noticed it wasn't there.

This has appeared in a large number of ML builds for the 650D and is there on the latest builds

Apologies if this has been brought up before..

[a1ex]

Would this help? https://bitbucket.org/hudson/magic-lantern/pull-requests/734/cleaner-method-for-hiding-canons-bottom

edit: reproduced in QEMU. Doesn't seem to happen on 700D, under the same test conditions (also QEMU).

[saulbass]

@a1ex: I'm afraid coding is going to be beyond me but happy to do any testing.

The 650D functionally works really well with the recent builds so this is more of a gilding the lily kind of thing...

[a1ex]

It's still testing (no coding), just no precompiled build; see the sticky tweet for a quick howto.

[dfort]

With the help of @COMMANDES I was able to get a firmware dump of the 1.0.5 firmware. Turned out to be the easiest firmware update I've done. Tested in QEMU but not in camera. Anyone who wants to give it a try make sure you set your camera and card bootflags in 1.0.4 before doing the firmware update. Posted a test build on my downloads page. Also there you'll find Canon firmware updaters for 1.0.4 and 1.0.5 so you can upgrade/downgrade your firmware. If you find any issues when using 1.0.5 please check them in 1.0.4 so we know if it is a new or existing issue.

Pull request submitted. Please feel free to comment.

https://bitbucket.org/hudson/magic-lantern/pull-requests/914/update-to-650d105/diff

[saulbass]

Okay - used dforts 650D105 firmware updater - seemed to work okay.

Then Tried using - magiclantern-Nightly.2018Apr04.650D105 & a1ex's sd_uhs.mo

No go as these screen shots attest....

tried mlv_lite.mo & mlv_rec.mo both which did seem to work(ish) but obviously missing all the recent goodness of the crop_rec

Here is the crash log - I have the COREDUMP.DAT if needed...

Code Select Expand

[100] raw_rec_task: NULL PTR (80c3e100,e1a00000)
pc=    ce28 lr=    ce28 stack=1ac1d8+0x1000
entry=a56438(0)
e1a00000 e59ff014 e59ff014 e59f001d
e59ff014 e1a00000 e59ff010 e59ff010

Magic Lantern version : Nightly.2018Apr04.650D105
Mercurial changeset   : e4abf5dddb65 (update-to-650D.105) tip
Built on 2018-04-04 23:24:00 UTC by rosiefort@RosieFoComputer.
Free Memory  : 127K + 3591K

[dfort]

You do know that the sd_uhs module is supposed to be used with the crop_rec_4k branch and the 1.0.5 test build is on the unified branch, right? Like I said, if you find an issue try reproducing it with the nightly 1.0.4 build. I think you'll find the same issue.

I've been thinking of doing firmware updates on the various experimental branches simultaneously but let's take a step at a time for now. If the firmware update is working as expected in the unified branch (a.k.a. nightly builds) then we can take it to the next level.

[Felipe]

Great, New blood for my trusty 650D

[clustercuss]

When I install the firmware the camera says that magic lantern was installed successfully but after restarting, the only thing that has changed with the interface is some text on the main camera screen listing the lens i'm using, the build number, and today's date. The setting menu is completely identical. I've been trying to get magic lantern to work for ages on my t4i. Any help would be appreciated.




image hosting sites free

[Walter Schulz]

Top of page -> User Guide -> Install Guide/User Guide/F.A.Q.

[saulbass]

650D.105 - from dforts 105 firmware updater
working from dforts magiclantern-Nightly.2018Apr14.650D105

testing both mlv_lite and mlv_rec

clean install of ML.
mlv_rec  and frame rate changed (24fps)
(1728x972) - crash and stops recording as usual (data rate too high)

Code Select Expand

[99] raw_rec_task: NULL PTR (80c3e100,e1a00000)
pc=    ce28 lr=    ce28 stack=1abdd0+0x1000
entry=a56298(0)
e1a00000 e59ff014 e59ff014 e59f0034
e59ff014 e1a00000 e59ff010 e59ff010

Magic Lantern version : Nightly.2018Apr14.650D105
Mercurial changeset   : b7315277e327 (update-to-650D.105)
Built on 2018-04-14 15:57:11 UTC by rosiefort@RosieFoComputer.
Free Memory  : 127K + 3591K


clean install of ML.
only mlv_lite and frame rate changed (24fps)
(1728x972) - crash and stops recording as usual (data rate too high)

Code Select Expand

[85] raw_rec_task: NULL PTR (80c3e100,e1a00000)
pc=    c288 lr=    c288 stack=1ac1d8+0x1000
entry=a60f74(0)
e1a00000 e59ff014 e59ff014 e59f0034
e59ff014 e1a00000 e59ff010 e59ff010

Magic Lantern version : Nightly.2018Apr14.650D105
Mercurial changeset   : b7315277e327 (update-to-650D.105)
Built on 2018-04-14 15:57:11 UTC by rosiefort@RosieFoComputer.
Free Memory  : 128K + 3630K






(1280x720) - crash but keeps recording.

Code Select Expand

[85] raw_rec_task: NULL PTR (80c3e100,e1a00000)
pc=    c288 lr=    c288 stack=1ac1d8+0x1000
entry=a60f74(0)
e1a00000 e59ff014 e59ff014 e59f0034
e59ff014 e1a00000 e59ff010 e59ff010
[85] raw_rec_task: NULL PTR (80c3e100,e1a00000)
pc=    c288 lr=    c288 sta
Magic Lantern version : Nightly.2018Apr14.650D105
Mercurial changeset   : b7315277e327 (update-to-650D.105)
Built on 2018-04-14 15:57:11 UTC by rosiefort@RosieFoComputer.
Free Memory  : 128K + 3630K


then a second crash while keeping recording. (same crash code)

all mlv's well formed.




crash DAT archive here....

https://we.tl/8iQJgew0JJ