Canon EOS M

[IDA_ML]

@12georgiadis:

"Do we record in 10 bits or lossless 10/12/14 bits for continuous ?"

I don't own the EOS M but the 100D which should be very similar and has the same card write speed.  I can confirm that the 100D can record in the Movie Crop Mode (3xCrop) at:

 1)  8...11 bit LL, 1800x1008 resolution @23,976 fps WITH SOUND !!! - CONTINUOUSLY
 
 2) 12 bit LL, 1800x1008 resolution @23,976 fps WITH SOUND - for about 40 s.

 3) 14 bit LL, 1800x1008 resolution @23,976 fps WITH SOUND - for about 14 s.

The recording times in #2 and #3 depend on the fine detail and whether or not there are very bright areas in the scene.  With very contrasty scenes, underexposing by 0,5 to 1 stop may increase record times substantially.  Dual ISO works very well in such situations.  Video quality is fantastic!  No VAF filter in Movie Crop Mode necessary!

If you can live with somewhat lower (1728x972) resolution, recording in #2 is continuous!  If you do not underexpose, video quality at even ISO 6400 is perfectly usable!

The 100D used is so cheap at the moment that you could buy one to play around with just for fun.  It is the perfect replacement of the 7D which is not ready yet for crop_4K and as a bonus it solves also your sound issue, (no h.264 proxy necessary, sound sync is perfect). You also have in-camera playback in color in the above three modes. 

Get yourself a used 100D.  You will not regret!

[12georgiadis]

@12georgiadis:

"Do we record in 10 bits or lossless 10/12/14 bits for continuous ?"

I don't own the EOS M but the 100D which should be very similar and has the same card write speed.  I can confirm that the 100D can record in the Movie Crop Mode (3xCrop) at:

 1)  8...11 bit LL, 1800x1008 resolution @23,976 fps WITH SOUND !!! - CONTINUOUSLY
 
 2) 12 bit LL, 1800x1008 resolution @23,976 fps WITH SOUND - for about 40 s.

 3) 14 bit LL, 1800x1008 resolution @23,976 fps WITH SOUND - for about 14 s.

The recording times in #2 and #3 depend on the fine detail and whether or not there are very bright areas in the scene.  With very contrasty scenes, underexposing by 0,5 to 1 stop may increase record times substantially.  Dual ISO works very well in such situations.  Video quality is fantastic!  No VAF filter in Movie Crop Mode necessary!

If you can live with somewhat lower (1728x972) resolution, recording in #2 is continuous!  If you do not underexpose, video quality at even ISO 6400 is perfectly usable!

The 100D used is so cheap at the moment that you could buy one to play around with just for fun.  It is the perfect replacement of the 7D which is not ready yet for crop_4K and as a bonus it solves also your sound issue, (no h.264 proxy necessary, sound sync is perfect). You also have in-camera playback in color in the above three modes. 

Get yourself a used 100D.  You will not regret!

Thanks IDA_ML! It convinced me for a 100D!


Envoyé de mon iPhone en utilisant Tapatalk

[Malloy]

Hello,

I am new to ML so sorry if this question is already answered.
If I remove ML from a SD card by formatting it is the shutterbug also gone or is it persistent?

Thanks

[dfort]

Short answer, the shutter-bug isn't persistent.

The shutter-bug only happens on certain cards when ML is loaded and you are using an EF-M zoom lens (don't know if it is the zoom or the IS that is causing this). There are a few workarounds but the easiest is to use a SanDisk Extreme 32GB or smaller SD card. Others might or might not work. It is important that the card not be over 32GB.

[dfort]

Hey EOSM users. How about testing a new build that gets you up to 2520x1080 raw video or 1920x1080 continuous? Check out this post on the crop_rec on steroids topic:

https://www.magiclantern.fm/forum/index.php?topic=19300.msg196350#msg196350

[dfort]

New test build posted on my Bitbucket downloads page that resolves the black bar on the right issue with using FPS override with the Exact of Low Jello option like in this video by @loknar

[Teamsleepkid]

how do you do it?

[dfort]

how do you do it?

You mean get into zoom mode on the EOSM? Press the INFO button until you see the magnifying glass on the bottom right of the screen and press it to get into 5x zoom mode. Then when you go to the raw settings you'll have these huge resolution options.

If you mean how do I code--when I was a kid I used to stick various objects into electrical outlets to see what would happen. That's pretty much it.

[IDA_ML]

when I was a kid I used to stick various objects into electrical outlets to see what would happen. That's pretty much it.

Ha, ha, Dfort, my 3-years old grandson does this all the time and despite the fact that his father replaced the fuses with fast automatic ones, I am scared to death when I see that. Maybe, one day he will become a good code writer, who knows ... ? :-)))

By the way, how do you get continuous recording at 1920x1080 on the EOS-M?  Does it have write speeds of about 45 MB/s. Do you use the 8 ... 11bit LL mode and do you underexpose?  If yes, how many stops?  I only get about 29 s. on the 100D at these settings and about 40 s. if I underexpose by one stop.  Mine writes at 41,6 MB/s on a fast card.

[dfort]

I'm at work today and don't have any camera with me so I can't confirm it but I believe that setting zoom mode at 1920x1080 in 8..11bit lossless compression should give you continuous recording. The EOSM and 100D have pretty much the same card write speed but a fast card is still needed. I use 32GB Sandisk Extreme Pro (95 MB/s) cards on the EOSM because of the shutter-bug issue and they also seem to perform better for video than the larger and/or slower cards.

I don't underexpose. If anything, when shooting raw I expose as far to the right as possible--before clipping/pink highlights. Yes, there are situations where overexposing will stop the recording or maybe even crashes ML but too much underexposure creates other problems.

[theBilalFakhouri]

On my 700D x5 crop mode at 1920x1080 in 8..11bit lossless, 23.976 fps the continuous recording depending on the how much detailed scenes you shoot and maybe ISO also.
Sometimes I get continuous recording sometimes didn't but I still have long recording times about 30 second to 3 minutes or more (It's depend). So It's not 100% continuous.
BTW I use 32GB Sandisk Extreme Pro 95mb/s.
EDIT: With audio of course, mlv_snd turned on.

[Teamsleepkid]

very cool and not trying to downplay it at all but the problem with this mode is its impossible to use it for filmmaking because you can't really frame. theres no live view just the choppy 6fps preview looking thing. if we could see real time the frame then it would be useful. I used to shoot 1920x800 with it on the previous builds which would be best best res before but never used it because shooting 1800x768 in crop mode was wiser to frame and use. if somebody could get it so we could see the framing in real time this would be the best cheapest small camera on earth for filmmaking at this time. 2 cents

[a1ex]

Just thought this one might be interesting for EOS M users:

For EOS M, a long press on SET/Q can be made to open submenus, in the same way as a long joystick press opens the submenu on 50D/5D2/5D3/7D.

https://bitbucket.org/hudson/magic-lantern/pull-requests/722/eos-m-long-press-set-q-to-open-submenus/diff

Finally got it working in QEMU!

If you can compile from source, please give it a try and report back.

[dfort]

If you can compile from source, please give it a try and report back.

Yes! Great feature. Like the little animated progress indicator on the bottom right of the screen when you do the long press.

I wanted to see if QEMU shows that progress indicator but I've never been able to get the EOSM to show the Canon menus, much less the ML menus.

[EDIT] Tried the latest QEMU changes that includes a fix for the EOSM/EOSM2 menus but I still can't get it working. Compiling like this from the qemu-eos directory (noticed that changed recently):

Code: [Select]

make -C ../magic-lantern EOSM_install_qemu

[a1ex]

Also add CONFIG_QEMU=y to enable the menu browsing hack (only needed for M and M2), then open ML menu directly from the date/time dialog.

[dfort]

Hum, thought I read somewhere that CONFIG_QEMU=y is applied when compiling with EOSM_install_qemu option.

In any case, just tried it again and it never gets to the GUI. Just a blank grey QEMU screen.

[garry23]

Also, I just tried the latest Lua fix experimental, and I think I'm having a senior moment as Q doesn't work, i.e. it never has for me on the EOSM.

[dfort]

Also, I just tried the latest Lua fix experimental, and I think I'm having a senior moment as Q doesn't work, i.e. it never has for me on the EOSM.

Right, you need to use the touch screen to get into the submenus. The Set and Q button are combined on the EOSM and the "longpress" branch decodes a short press as Set and long press as Q. Don't know if that accessable from lua.

[garry23]

@dfort

Yes I knew that, but thought I was reading that Q was now accessible on the EOSM.

BTW I have faked it via keypress event, i.e. hyjacking a key, but, I don't have many keys on the EOSM and I'm already hyjacking most of them in my Toggler script.

[a1ex]

The Q trick was done shortly after the latest lua_fix build; I was just necroposting that old experiment, since I now had the tools to look into it. Will include it in the next one.

@dfort: are you able to get Canon GUI on EOS M without loading autoexec.bin? If not, can you show me a log with "-d debugmsg" ? Here it starts at the date/time dialog and can navigate Canon menu from there; if loading ML compiled with CONFIG_QEMU=y from the qemu branch, I can also navigate ML menu from the same screen (opened with the delete key).

To test longpress in qemu:

Code: [Select]

# platform/EOSM.202
hg up longpress -C
hg merge qemu
make clean
make install_qemu CONFIG_QEMU=y

The CONFIG_QEMU option is explained here: https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst?fileviewer=file-view-default#rst-header-config-qemu

and plain "make install_qemu" means "regular build, but copy it on the virtual card used for QEMU, not on the SD card".

[garry23]

@a1ex

Thanks.

BTW I also noticed that the DOF reporting looks and is 'wrong' in the latest fix, but I thought you had added in the new maths?

Diffraction is wrong on the EOSM I looked at.

Cheers

Garry

[a1ex]

Quick check: "hg diff -r ec86da538297 -r lua_fix src/focus.c" shows no differences since I've included your fix, and "hg diff -r ec86da538297 -r crop_rec_4k src/focus.c" only shows a change relevant to 100D.

So, I don't expect any changes since including your fix, but I didn't double-check the math either. If you have some numeric example, I can check that in QEMU too (can fake lens data - aperture, focal length, etc, by editing the MPU messages).

[garry23]

@a1ex

Just checked the source and you still appear to have the uncorrected math in there.

[a1ex]

Which changeset did you check?

https://bitbucket.org/hudson/magic-lantern/src/ec86da538297/src/focus.c#focus.c-121 - with your fix
https://bitbucket.org/hudson/magic-lantern/src/lua_fix/src/focus.c#focus.c-121
https://bitbucket.org/hudson/magic-lantern/src/crop_rec_4k/src/focus.c#focus.c-121

They are identical.

[garry23]

@a1ex

I looked at the source in the latest Lua fix.

In there the diffraction, for example, is presented in the old way.

Here are the changes I put in:

Code: [Select]



-    // Set up some dof info

-    const uint64_t  freq = 550;         // mid vis diffraction freq in nm (use 850 if IR)

-    const uint64_t  imag = (fd-fl)/fl;  // inverse of magnification (to keep as integer)

-    const uint64_t  diff = (244*freq*lens_info.aperture*(1+imag)/imag)/1000000; // Diffraction blur in microns

+    // Estimate diffraction

+    const uint64_t  freq = 550; // mid vis diffraction freq in nm (use 850 if IR)

+    const uint64_t  diff = (244*freq*lens_info.aperture/1000000; // Diffraction blur at infinity in tenths of a micron
As I say, looks like the latest Lua fix source doesn't use the tenth of a micron approach, to get round the integer math.