Silent Pictures with the EOS M

[Licaon_Kter]

@Licaon_Kter -- I know you're watching but have you tried that test build I posted?

Not yet, I'll try it asap.
The tricky black screen has been here for a while.

[dfort]

The tricky black screen has been here for a while.

Right. The issue you pointed out was marked resolved but I just tested it and the intervalometer issue is still there on the EOSM. Adding another force_liveview when using the intervalometer does "fix" the problem so that the EOSM works the same as other cameras.

Code: [Select]

    if (is_intervalometer_running())
    {
        /* keep the display on, up to "image_review_time" seconds (as set in Canon menu) */
        /* but do not block during this time */
        /* (will set a timer - if we are still in QR mode, turn off the display) */
        int intervalometer_delay = get_interval_time() * 1000;
        int intervalometer_remaining = intervalometer_delay - capture_time - save_time - 2000;
        int preview_delay =
            image_review_time ? COERCE(intervalometer_remaining, 0, image_review_time * 1000 - save_time)
                              : 0;
        delayed_call(100, display_off_if_qr_mode, (void*)preview_delay);

        /* EOSM needs to be forced into LiveView */
        #ifdef CONFIG_EOSM
            force_liveview();
        #endif

        /* reset the powersave timer */
        powersave_prolong();
    }

So this resolves the EOSM intervalometer issue while the "hack" I made for Meloware changes the UI for all platforms. I'll post a test build as soon as bitbucket allows access to the download pages--it is currently down.

[EDIT] There's more than one way to write the code to apply to a certain camera. Another method is:

Code: [Select]

        /* EOSM needs to be forced into LiveView */
        if (is_camera("EOSM", "2.0.2"))
            force_liveview();

Which one is preferred?

I think that the intervalometer fix for the EOSM is ready for a pull request but the change so that FRSP has the same user experience as simple silent needs some more discussion.

[Danne]

Fixed intervalometer. Mm, nice one.

[dfort]

Ok--got a test build up:

https://bitbucket.org/daniel_fort/magic-lantern/downloads/

This is for the EOSM, has the intervalometer fix and also the return to LiveView after each FRSP. Please post feedback.

[Meloware]

I am very interested in using ML to transfer a collection of family films.  I have been following the 12/10 video bit thread closely and wanted to ask if the video mode frame rate can be externally clocked (not advanced by an internal timer) to accomplish the film capture.
Mike

miket, I am not familiar with all the technical detail you were providing with your post. My choice of Canon cameras are largely due to the APS-C image sensor and the fact that they may be used with ML. Both my EOS M as well as my T4i/650D have native HD video recording modes in 1080p. What format are you family films in? My gut says 8mm is less quality than HD and that 16mm can benefit from HD. My goal in this forum is to get folks to appreciate the benefit of supporting this application and to help assist in the changes needed to support the very inexpensive EOS M for frame by frame capture.

Big frame images take a large amount of memory and processing time. Raw frame capture in very large images won't be possible in real time film running because of the amount of data involved. My frame by frame system steps the projector a frame at a time (with a stepping motor) and operates the camera with my home built controller. The speed of the system is largely limited because of the amount of data required by these raw images. If this is what you want, please help me in encouraging ML development in this direction.

If you want fast, quick and dirty, why not use a simple film chain? I doubt the 8mm format beats 1080p, and the only forgivable issue may be the rolling brightness from the projector shutter. These cameras will operate without a lens attached. Take your film projector, replace the projection lamp with a good daylight color LED bulb, and focus the projector on the camera sensor. Then, just shoot 1080p video. Here is an example with 8mm. It is not perfect, but it is fast and easy.

[Meloware]

dfort, thanks for the new build. I understand this version addresses the intervalometer, but did make some observations. The status messages are still wiped out and unreadable, as before, with the silent pictures and audio trigger. However, the intervalometer maintains an display of the timer interval and total frame count. Maybe it would be easier to use this same method to provide me with a running frame count and memory use status line! I don't care where the message comes from, as long as it is there.

The other observation is that the camera never drops back into standby, due to the LCD Powersave timer. This latest build still drops into standby, when using silent and audio trigger. Why does my combination of features get affected and not the intervalometer?

[dfort]

I put in a feature request to add a lua hook for audio events. That should be a relatively simple task though it is beyond my current skills.

So instead of forcing the camera into LiveView after each full resolution silent picture (FRSP) the lua script could send a short or long shutter half-press when the audio level reaches a predetermined level. This is similar to what AUDIO_REMOTE_SHOT is currently doing except with control over the type of shutter press. I'm not sure what type of shutter press AUDIO_REMOTE_SHOT is using with FRSP but it isn't resetting the power save timer while a lua shutter half-press does reset the timer. In addition, a lua shutter half-press puts the camera back into LiveView without having to force it.

[a1ex]

The issue you pointed out was marked resolved but I just tested it and the intervalometer issue is still there on the EOSM.

Just tested on 5D3 and could not reproduce it. Can you give some details about what happens on EOS M? (maybe a video)

This latest build still drops into standby, when using silent and audio trigger. Why does my combination of features get affected and not the intervalometer?

Easy to fix: move the powersave_prolong call outside the if (intervalometer) branch.

I put in a feature request to add a lua hook for audio events.

That's certainly useful, but for solving this I think it's overkill. Fixing the audio remote behavior is probably a better idea.

The problem is that full resolution silent picture leaves the camera in a paused LV state and it seems that the EOSM also turns off the audio when the LV is paused so the camera cannot listen for an audio event.

This one is tricky, as the EOS M (and some others too) appear to turn off the audio device when you are not recording H.264. Both the audio meters task and the remote shot code contain workarounds for this, which attempt to re-enable the audio. I'm not sure whether both are needed, as it doesn't happen on any of my models, so it takes a bit of experimentation to find out. Probably it's best to enable the audio meters when audio remote shot is activated, so the workarounds for those tricky models should kick in.

Will look into it, but I'll need a live session (maybe IRC chat) with a EOSM/650D/700D owner with basic programming skills.

Oops--looks like this project just opened up a can of worms.

Some more: the file saving can be done in a different task, pipelined with the image capture. Canon does this, but in the silent picture module I simply didn't feel the need for speed, so I kept it simple.

I've been following the discussion since it started, but unfortunately, during the last two weeks I was just too tired to do any kind of programming or testing (let alone using the camera). Sorry for not helping earlier.

[dfort]

Thanks for the detailed reply. Looks like there is a lot to do. I've also got a limited amount of energy to put into this because I've got too many tasks on my todo list. I'll work on preparing a video showing the issues and try your suggestions. If the planets align just right we can do a live session--I've got EOSM, 700D, 5D3 and as you know very very basic programming skills.

[Meloware]

I might have similar skills to dfort (but less experience on ML), and am willing to try and help out any way I can. I am east coast US, have an EOS M, and 650D, have written a couple of thousand lines of code, and am responsible for this last round of trouble.

For my application, fast cycle time is top priority and power is not an issue. I have been monitoring the Silent Pictures status (especially frame count to estimate remaining capacity) and using the last message to determine when I can take the next exposure. I mentioned earlier in the thread that it would be great to have a “camera ready” signal. It occurred to me that this might not be too hard!

After the current exposure is saved, why not use the flash mount to signal a “camera ready” event? These cursed memories take varying times to save frames and I currently need to wait for the worst case write times. As the chip fills, the time it takes to save gets longer and longer. If the flash shoe could trigger, once the camera was ready for another exposure, then the automation could run reliably and as fast as possible! I would use the “camera ready” signal, instead of relying on a guessing analog timer. In addition, There might be menu option to set a maximum frame count desired for the session, and once the count expired, “camera ready” would no longer be asserted. I could load the thing up, and go to bed! The system would stop recording when the memory was full and the next movie frame would be in place for the next blank chip. Is this dreaming or getting too greedy?

[dfort]

move the powersave_prolong call outside the if (intervalometer) branch.

Brilliant. That took care of the show stopper. Now the power save timer resets after each exposure.

@Meloware - I made a new build for you to try out.

https://bitbucket.org/daniel_fort/magic-lantern/downloads/

Using force_liveview to fix the intervalometer on the EOSM seems to do the trick. It doesn't seem to be necessary for AUDIO_REMOTE_SHOT now that powersave_prolong is out of the if branch but then you're shooting blind so I added another force_liveview there too. It seems that force_liveview is adding a delay before AUDIO_REMOTE_SHOT is ready for another exposure. I tried switching to MLV and it shaved off about a second compared to DNG.

Right now the forced_liveview is only used on the EOSM. I take it that this is the right way to do it so that the module is portable?

Code: [Select]

    if (is_intervalometer_running())
    {
        /* keep the display on, up to "image_review_time" seconds (as set in Canon menu) */
        /* but do not block during this time */
        /* (will set a timer - if we are still in QR mode, turn off the display) */
        int intervalometer_delay = get_interval_time() * 1000;
        int intervalometer_remaining = intervalometer_delay - capture_time - save_time - 2000;
        int preview_delay =
            image_review_time ? COERCE(intervalometer_remaining, 0, image_review_time * 1000 - save_time)
                              : 0;
        delayed_call(100, display_off_if_qr_mode, (void*)preview_delay);

        /* EOSM needs to be forced into LiveView */
        if (is_camera("EOSM", "2.0.2"))
            force_liveview();
    }
    else
    {
        bmp_printf(FONT_MED, 0, 106, "Long half-shutter will take another picture.");
        int preview_delay = MAX(1000, image_review_time * 1000 - save_time);
        delayed_call(100, display_off_if_qr_mode, (void*)preview_delay);

        /* EOSM needs to be forced into LiveView */
        if (is_camera("EOSM", "2.0.2"))
            force_liveview();
    }

/* reset the powersave timer */
powersave_prolong();


[Meloware]

Thanks! It runs forever now.

[a1ex]

Let's try a small test. This goes to paused LiveView and enables audio meters on 5D3.

Code: [Select]

static void run_test()
{
    msleep(2000);
    PauseLiveView();    /* powersave.h */
    display_on();
    SoundDevActiveIn(0);
}

audio-common.c:
 static int audio_meters_are_drawn_common()
 {
+    return 1;

Two questions:

- with these changes, does it work on EOS M, 700D, 650D, 100D, 70D? (for last two, please use nikfreak's repo)
- if yes, does it still work if you remove the call to PowerMicAmp from audio_meters_step?

On 5D3, SoundDevActiveIn appears to use a reference counter and calls PowerMicAmp (only once) or UnpowerMicAmp (when the reference counter goes back to 0). Therefore, on this camera, SoundDevActiveIn is enough.

On the other hand, mlv_snd calls SoundDevActiveIn, but the audio meters will also call PowerMicAmp on the above models. Therefore, a test that does not require any changes to the source code would be to check whether mlv_snd works with global draw off (therefore no audio meters and no calls to PowerMicAmp) on the above models.

Anyone can run the mlv_snd test on any recent nightly, so please report for all the above models, and additionally on 600D and 7D. Also try mixing mlv_snd with H.264 (both recording and playing) or alternating between global draw settings. Make sure you include a mlv_snd test with camera started with global draw off (not just by turning it off from menu).

[miket]

quote from: Meloware on March 02, 2017, 02:31:18 AM

If you want fast, quick and dirty, why not use a simple film chain?

Meloware, Thank you for your reply to my somewhat off topic post.  For my project I did use the canon video mode to make the initial reference copies of our 130 movies for review.  The movies are amateur shot in 8MM, 16MM, and a few Super 8, the oldest films are from the late 1930's.  My Canon video results looked about the same as from your link.  You can see a photo of the rig I used for 16mm in the photos below.

quote from: Meloware on March 02, 2017, 02:31:18 AM

My gut says 8mm is less quality than HD and that 16mm can benefit from HD

I agree in general but it also depends on the camera used to shoot the original movie.  I think the results from my cousin Joe's Pi system look really good at HD, here is an 8mm example - https://vimeo.com/178795898

quote from: Meloware on March 02, 2017, 02:31:18 AM

The speed of the system is largely limited because of the amount of data required by these raw images. If this is what you want, please help me in encouraging ML development in this direction.

The information and development within this post is fantastic.  I agree that speed and data volume are limiting factors for film transfers, and I would add that complexity of the setup is also limiting for many ML users. 

What I am asking, let’s call it a feature request, is adding a frame by frame advance feature to 10 bit RAW video capture.  Instead of using FRSP, use the ML RAW video hacked even further so that video frame advance is connected to audio remote shot or half press on the shutter allowing the ML video to synchronize with the projector.  I'm not a programmer and I can’t say if this is even possible, to pause the ML RAW video frame rate timers and wait for external triggers to advance one frame.

If external clocking of video is possible then the capture speed might be much faster and the 10 bit video much smaller in file size for easier post production.  I think there are several other benefits to this method.  The crop mode video helps to solve the magnification issue of capturing 8mm and 16mm film onto the much larger Canon sensor.  Higher than HD vertical video resolution settings using allow cropping easily in post since alignment of the projector/camera combo during capture is only approximate. Running the movie projector a little slower than normal speed is easier than modifying the drive system for a stepper motor. Anything to simplify the process will help a larger group of users take on a home movie transfer project with their own collections.

16mm projector with 5d2.  The optics are a reversed and stripped down 50mm f1.8 Nikkor on 105mm of extension tubes. 
https://drive.google.com/open?id=0BxP1ckq84DqoUERUX0ozQTV5WXc

https://drive.google.com/open?id=0BxP1ckq84DqoRUJLLTZBbndWYWs

For the 8mm projector rig I used the reversed 50mm f1.8 Nikkor on the front of a 200mm f4 Nikkor with a couple of extension tubes (about 5x Macro).
https://drive.google.com/open?id=0BxP1ckq84DqoRHo3U0QtY3RrYzQ

https://drive.google.com/open?id=0BxP1ckq84DqoR1BHTzNLMjdnVkE 

[dfort]

@miket - Love that old time film look. Really interested in seeing your rig but those last two images on your post have broken links.

@a1ex:

Back to testing. I lined up an EOSM, 700D and 5D3.113 to do this test. I'm sure I got this right, put the first part of code in debug.c so it will activate with "Don't click me!" adding powersave.h to the include list and finally adding "return 1" to the end of the audio_meters_are_drawn_common function in audio-common.c. Compiling the EOSM and 700D versions went fine but got this error with the 5D3:

Code: [Select]

[ LD       ]   magiclantern
debug.o: In function `run_test':
debug.c:(.text+0x6c0): undefined reference to `SoundDevActiveIn'
make: *** [magiclantern] Error 1

I really wanted to see what happens on the 5D3 but on the EOSM and 700D, both showed the same results. The camera went into a sort of a paused mode where the LiveView froze on a frame and was just stuck. Unsticking this state by going out of LiveView resulted in a state where the ML menu couldn't be activated with the trash button. Turning the camera off then on cleared it up, no battery pull needed. So I didn't see the audio meters activate.

The next test using a regular nightly download and recording an MLV file with audio and global draw off resulted in audio being recorded fine. Note that when recording MLV global draw turns off before recording anyway on these cameras using the unified build. I believe that the 10/12bit experimental build allows global draw to be on while recording. Bottom line, audio recording with no audio meters (and therefore no calls to PowerMicAmp?) works.

I was setting up to demonstrate the EOSM intervalometer issue but something strange happened. In order to get two EOSM's running side by side with the exact same settings I first cleared the Canon settings and after getting things set up for Full Resolution Silent Picture, the intervalometer behaved the same as on the 700D and 5D3. The issue with the intervalometer running with a dark LiveView screen was gone. Great, another mysterious Canon setting must have triggered this issue. However, I did observe something interesting. On the build with the forced LiveView you can see the intervalometer counter while on the unified build the intervalometer counter never came up after the first shot on any of the cameras.

Another interesting observation with the build that always forces LiveView after each FRSP is that it allows AUDIO_REMOTE_SHOT to work on both the EOSM and 700D. I suppose this is true with other cameras that support AUDIO_REMOTE_SHOT.

Looks like there is more testing yet to come.

[a1ex]

debug.c:(.text+0x6c0): undefined reference to `SoundDevActiveIn'

FF110D88 in 1.2.3.

The next test using a regular nightly download and recording an MLV file with audio and global draw off resulted in audio being recorded fine. Note that when recording MLV global draw turns off before recording anyway on these cameras using the unified build. I believe that the 10/12bit experimental build allows global draw to be on while recording. Bottom line, audio recording with no audio meters (and therefore no calls to PowerMicAmp?) works.

If global draw is turned off by MLV, then you have already seen the audio meters before recording (so, there was a call to PowerMicAmp). That's why I said to include a test with camera starting with global draw off.

The camera went into a sort of a paused mode where the LiveView froze on a frame and was just stuck.

Yes, the paused LiveView state behaves that way. If you enable FRSP, the silent module will let you exit this mode with a short half-shutter press.

So I didn't see the audio meters activate.

Just for kicks, let's try calling both SoundDevActiveIn and PowerMicAmp from our test routine, or maybe only the latter.

[dfort]

debug.c:(.text+0x6c0): undefined reference to `SoundDevActiveIn'

FF110D88 in 1.2.3.

Let me dwell on that for a bit. So the reason that the build failed was because SoundDevActiveIn is not defined in stubs.S for the 5D3. Looking at my disassemblies I see this:

FF110D88 in 1.2.3 - Yep, there it is. Using this as a springboard--
FF1111F4 in 1.1.3
FF110D90 in 1.3.3
FF110D90 in 1.3.4

So shouldn't these be added to stubs.S?

Ok, got it to build on the 5D3.113 and got the exact same results as the EOSM and 700D.

This goes to paused LiveView and enables audio meters on 5D3.

Paused LiveView I see and can exit that mode by enabling FRSP and doing a short half-shutter press but how do I know if the audio meters are enabled?

Just for kicks, let's try calling both SoundDevActiveIn and PowerMicAmp from our test routine, or maybe only the latter.

Going deeper down the rabbit hole PowerMicAmp is another one that is missing from the 5D3 (all versions) stubs.S but it is clearly there in the disassembly (ff138a54 in 5D3.113) so same question, should it be added? Just wondering at this point, will these new stubs possibly allow AUDIO_REMOTE_SHOT on the 5D3? Seems strange that it doesn't work on that camera.

Getting late here and drifting off topic so I'll have to continue these tests when I'm fully awake.

[a1ex]

On 1.2.3 I could see the audio meters moving, but otherwise the user interface was stuck. I ran the test in photo mode, M, if that helps.

As I've explained earlier, PowerMicAmp is called by SoundDevActiveIn in Canon firmware (5D3), so there's no need for us to call it manually.

[miket]

@dfort - I have updated the photo links.  Thanks.

[dfort]

@miket - Wow, those are impressive rigs. You are getting great results with them. I'm not sure how it would be possible to sync the camera with the projector. Going the film scanner route where you verify that you're capturing one frame at a time really slows down the transfer but the quality is amazing. Check out some of the film to digital transfers @Meloware is doing: http://industrialhistory.org/

On 1.2.3 I could see the audio meters moving, but otherwise the user interface was stuck. I ran the test in photo mode, M, if that helps.

I assumed you were on 1.1.3 so I switched over to 1.2.3 but got the same results. I can't see audio meters moving. Also tried calling both SoundDevActiveIn and PowerMicAmp then only PowerMicAmp on the 5D3.123 and EOSM.202 with the same results -- no audio meters.

Another observation on the 5D3 stubs.S. There seems to be some inconsistency here:

Code: [Select]

/** ASIF **/
NSTUB(0xFF110D88,  SoundDevActiveIn)                        /* present on 7D.203, 6D.113, 700D.111, 650D.104, EOSM.202 */

/** Audio **/
// NSTUB(    ???,  sounddev_active_in)                      /* present on 7D.203, 500D.111, 60D.111, 700D.111, 5D2.212, 600D.102, 650D.104, 550D.109, 1100D.105 */

I'll shoot a video of the intervalometer and AUDIO_REMOTE_SHOT test builds running on various cameras to better illustrate the issues I'm seeing.

[dfort]

Here we go, a video to illustrate the intervalometer, Audio Remote and a surprise discovery at the end.

I am forcing the camera into LiveView after each Full Resolution Silent Picture which is very useful for the intervalometer and pretty much necessary for Audio Remote but I'm also making the case to force LiveView in "normal" FRSP mode. While doing this video I discovered that a 50mm prime lens was showing a dramatically different exposure from a 17-55mm zoom even though both lenses were set at the same focal length and f/stop. Not really a part of this test but worth showing--hope I didn't open up yet another can of worms.

[Walter Schulz]

Let's try a small test. This goes to paused LiveView and enables audio meters on 5D3.

Code: [Select]

static void run_test()
{
    msleep(2000);
    PauseLiveView();    /* powersave.h */
    display_on();
    SoundDevActiveIn(0);
}

audio-common.c:
 static int audio_meters_are_drawn_common()
 {
+    return 1;

Two questions:

- with these changes, does it work on EOS M, 700D, 650D, 100D, 70D? (for last two, please use nikfreak's repo)
- if yes, does it still work if you remove the call to PowerMicAmp from audio_meters_step?

Willing to test for 7D and 650D, but I don't know which source file(s) to edit. Help, please!

[josepvm]

While doing this video I discovered that a 50mm prime lens was showing a dramatically different exposure from a 17-55mm zoom even though both lenses were set at the same focal length and f/stop. Not really a part of this test but worth showing--hope I didn't open up yet another can of worms.

Perhaps related to this old issue?

http://www.magiclantern.fm/forum/index.php?topic=12523.msg145567.msg#145567

[dfort]

Willing to test for 7D and 650D, but I don't know which source file(s) to edit. Help, please!

You need to edit debug.c and audio-common.c. I'm pretty sure I got the debug.c right, it needs to go in run_test so that you can run it from the Debug menu "Don't click me!"



I'm not sure I did the audio-common.c change properly because I'm not seeing the audio meters come up on the 5D3.123.
[EDIT] Looking at it again I'm sure that I put the "return 1" in the wrong place.



Here's the branch I'm working on: https://bitbucket.org/daniel_fort/magic-lantern/branch/a1ex_tests

Perhaps related to this old issue?

Yes, it sure does look like it. So add the  EF-S 17-55mm 2.8 USM to the list. The EOSM's had EF-M 22mm lenses mounted on them. I was using f/22 so maybe that had something to do with it?

[dfort]

Ok--got back to this and found out that I was right about being wrong. The place to put the "return 1" is at the top of the function.

Code: [Select]

static int audio_meters_are_drawn_common()
{
return 1; // test for a1ex - this is where it goes

Now to continue with the test:

Two questions:

- with these changes, does it work on EOS M, 700D, 650D, 100D, 70D? (for last two, please use nikfreak's repo)
- if yes, does it still work if you remove the call to PowerMicAmp from audio_meters_step?

For the EOSM and 700D:

• Yes! In Photo Mode the meters show audio levels before and after the test when LiveView is in paused mode.
• Yes! In Video Mode the meters show audio levels but in Photo Mode the meters don't show audio levels before the test. After running the test they do show levels when LiveView is in paused mode.

Removed the call to PowerMicAmp this way:

Code: [Select]

static int audio_meters_step( int reconfig_audio )
{

    if(audio_meters_are_drawn())
    {
        if(!is_mvr_buffer_almost_full())
        {
            BMP_LOCK( draw_meters(); );
        }

        if(RECORDING)
        {
            reconfig_audio = 0;
        }
        else if(!reconfig_audio)
        {
            #if defined(CONFIG_600D) || defined(CONFIG_7D)
            audio_configure(1);
            #elif defined(CONFIG_650D) || defined(CONFIG_700D) || defined(CONFIG_EOSM)
//            void PowerMicAmp();
//            PowerMicAmp(0);
            #endif
            reconfig_audio = 1;
        }
    }

So this minion will not be cast into the Gorge of Eternal Peril -- or is there a third question?

Willing to test for 7D and 650D, but I don't know which source file(s) to edit. Help, please!

Walter -- you got this? I made a pull request on my repository so you can see the changes. Never mind the 5D3 stubs, you've got SoundDevActiveIn on both the 7D and 650D.

https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/3/a1ex-tests/diff