I transfer and restore 16mm movies using my 650D/T4i with Magic Lantern's silent.mo and mlv_rec.mo. I just bought an EOS M (cheaper and mirror-less) and discovered too late that Canon didn't bother to include a remote shutter connection. The camera STILL has mechanical parts operating with each exposure, so I must find a way to use Silent pictures with this camera.
If I load silent and mlv_rec in the EOS M, it still functions well with the "half shutter" button pressed. I can still use all recording modes by physically pressing this button. Please suggest a way I might do this with a switch closure from my own film controller(as I did with my 650D/T4i).
ML's audio trigger looks promising, and even works with the lower resolution modes of Silent pictures. When I try and use the audio trigger with full resolution video and DNGs, the first exposure is taken and the screen then goes black. No further trigger events are possible until I physically press a "half shutter". I may then audio trigger one more complete exposure and then everything stops as before. I am a poor coder and have no idea how to write and compile my own version of ML, but it seems like it might be an easy change for someone more experienced.
Is there any other possible solution? Do Lua scripts offer a solution? Any guidance or help in getting my EOS M working with event triggered Silent pictures (full-resolution) would be greatly appreciated.
Thank you for past help and I hope this one is interesting and doable.
(Sorry – had to post here because I can't seem to post in Camera-Specific discussion)
[EDIT: Oops--just found out that LiveView blacking out is an issue with full resolution silent pictures.]
Thanks. I know nothing of writing/running Lua but if the functionality is there, I'll may need to learn it. I don't normally code, but sometimes it is necessary for reaching goals.
Does the T4i remote shutter jack produce a different event than the physical shutter button? Why wouldn't they just be made electrically in parallel? If I use the physical button (on the EOS M), everything works great. I just can't do that for 30,000 pressings – I need to use my controller. If worse came to worse, I might have to consider opening up the camera and trying to wire in my own jack. Aside from the needed trigger, ML has everything else I need to do the job.
I deleted my prior post because it seems that the problem is with full resolution silent pictures. It doesn't matter if it is triggered by Audio Remote Shot or by a shutter half-press, the LV blacks out after a FRSP. I tried it on a 700D with the same results so there is something going on that should be fixed.
Just to say once more: With my EOS M, I can enable mlv_rec.mo and silent.mo, set the resolution to full raw, and then press on the shutter button halfway, and make multiple exposures to an mlv video file. I just tried it again. I can then extract all my frames as 31,877KB DNGs. There may be more to this issue, but if you are investigating my problem, please keep in mind that I can create full res MLV video files by using the button. I hope this leads to an answer. Thanks!
So you want liveview between the shots?
As far as I remember, the very first version of silent.mo has it.
Then it was removed to keep the battery.
Actually, it would be nice to have an option.
As I understand, Silent Pictures only runs in LiveView. What defines that in a mirrorless camera less clear to me. Any preview has to be live, because the EOS M has no optical view in the first place. The "Half Shutter" event is how a Silent exposure is triggered. Button pressing to "Half Shutter" does work as expected on the EOS M camera, but I need to trigger an exposure from a method which can be generated from an electronic controller (a switch closure). I am able to do this with my T4i.
Between exposures, I am still interested for the back display to show the current picture, but I still need to see the data like frame number and total card usage (which is normally displayed). In any case, displayed data isn't as important as being able to record the video using an external trigger.
To return to LiveView from full-res silent pictures, simply press half-shutter again after the exposure.
To trigger exposures without returning to LiveView, thus saving the battery, use long half-shutter presses.
Both cases should work with external signals. However, the EOS M is unable to accept external half-shutter signals, to my knowledge.
The rationale behind this behavior is around here (http://www.magiclantern.fm/forum/index.php?topic=12523.msg144564#msg144564) (basically, allow remote triggers to work without LiveView draining the battery).
The alternative would be audio (http://www.magiclantern.fm/forum/index.php?topic=11930.0) trigger (http://photography.grayheron.net/2017/01/a-killer-combination.html). However, it doesn't work with FRSP (https://www.magiclantern.fm/forum/index.php?topic=18787.0), but it's easy to fix.
Also, the intervalometer is synced from the real-time clock, so you may be able to use it without any sync signals (open loop).
Quote from: Meloware on February 22, 2017, 06:15:47 AM
As I understand, Silent Pictures only runs in LiveView. What defines that in a mirrorless camera less clear to me.
On EOS M, exiting LiveView means entering either Canon menu or the PLAY dialog. In these modes, the image sensor is inactive. The full-res silent pictures will switch to a "paused LiveView" mode (an artificial mode similar to PLAY dialog, where the image sensor is also inactive).
QuoteTo return to LiveView from full-res silent pictures, simply press half-shutter again after the exposure.
To trigger exposures without returning to LiveView, thus saving the battery, use long half-shutter presses.
Both cases should work with external signals. However, the EOS M is unable to accept external half-shutter signals, to my knowledge.
This describes how my EOS M works, when the shutter button is physically pressed, and how the T4i operates with a remote cable plugged in. Of course, this cable feature is unavailable on the EOS M.
Quote
The rationale behind this behavior is around herehttps://www.magiclantern.fm/forum/index.php?topic=18787.0 (https://www.magiclantern.fm/forum/index.php?topic=18787.0) (basically, allow remote triggers to work without LiveView draining the battery).
The alternative would be audio trigger. However, it doesn't work with FRSP, but it's easy to fix.
It seems the post you mentioned above does seem to describe the same problem. For myself, battery life is not an issue. This is a home designed, frame by frame movie-to-digital transfer station, and everything is powered by line adapters and power supplies.
The audio trigger module is where I would go, if I had the knowledge and resources to build my own version. I would think it would be a simple matter to substitute the "shutter" variable for the "Half-shutter" variable, and my troubles might be behind me.
QuoteAlso, the intervalometer is synced from the real-time clock, so you may be able to use it without any sync signals (open loop).
The intervalometer isn't an option because this is an asynchronous system. The camera needs to take an exposure when the larger system is ready. My station currently copies at about 10 frames a minute, although I hope to get it faster. It is my system ready signal (a switch closure) which needs to trigger the camera.
Yes, it needs to run for days to render out a 15 minute film. Even a short film is over 30,000 exposures, on the camera, and any mechanical operation would quickly wear it out. The Silent Picture feature is essential in making this home design possible.
I really hope this solution is fairly easy and interesting for one of you coding experts to help me with. The results of my work benefit a non-profit industrial history museum. All of the films at http://industrialhistory.org/education/videos/ (http://industrialhistory.org/education/videos/) were made without compensation and Magic Lantern is essential in my design. This may seem to be a novel use of ML, but I hope you get to look at some of the results and agree that this is a valuable tool in preserving historic films.
That's a cool application. The videos look nice and steady. Could you post some photos of your rig?
Years ago I experimented putting small video cameras on old Moviolas to convert 35mm film to 24fps QuickTime files. That was a big deal back then because we were using 3/4 inch Umatic videotapes. It worked ok and I called it the Digiola but I never followed up on it--too busy working and technology was moving fast. I still have that domain name and use it for my email.
Quote from: a1ex on February 22, 2017, 08:59:52 AM
The alternative would be audio (http://www.magiclantern.fm/forum/index.php?topic=11930.0) trigger (http://photography.grayheron.net/2017/01/a-killer-combination.html). However, it doesn't work with FRSP (https://www.magiclantern.fm/forum/index.php?topic=18787.0), but it's easy to fix.
Easy for you! Ok--I brought back the Audio Remote Shot on the EOSM (https://bitbucket.org/hudson/magic-lantern/pull-requests/645/enable-feature_audio_remote_shot-on-eosm/diff) and that was really easy so I'll look into this.
Seems to me that if we can detect when the silent module is active it might be possible to fake a long shutter half-press in shoot.c for the EOSM?
// take one shot, a sequence of HDR shots, or start a movie
// to be called by remote triggers
void remote_shot(int wait)
{
// save zoom value (x1, x5 or x10)
int zoom = lv_dispsize;
#ifdef FEATURE_FOCUS_STACKING
if (is_focus_stack_enabled())
{
focus_stack_run(0);
}
else
#endif
if (is_movie_mode())
{
movie_start();
}
else if (is_hdr_bracketing_enabled())
{
hdr_shot(0, wait);
}
else
{
take_fast_pictures(pics_to_take_at_once+1);
}
if (!wait) return;
lens_wait_readytotakepic(64);
msleep(500);
while (gui_state != GUISTATE_IDLE) msleep(100);
msleep(500);
// restore zoom
if (lv && NOT_RECORDING && zoom > 1) set_lv_zoom(zoom);
picture_was_taken_flag = 0;
}
The audio trigger already triggers simple silent pictures, and it doesn't do so by pressing half-shutter. So... the problem is elsewhere.
Clicking my last link will give you the place to look for:
Quote from: a1ex on January 21, 2017, 09:43:42 PM
The audio trigger only works when the camera is "idle" (either in photo mode or in LiveView, with no Canon menu active).
FRSP leaves the camera in either the QuickReview + paused LV state, or in plain paused LV state (depending on preview settings), so those modes should probably be allowed for listening as well.
Looking at the remote shoot code, the trigger only runs when display_idle() returns 1 (actually a short while after that, to avoid some false triggers from e.g. button or shutter noises).
So, one way is to modify display_idle() to consider the paused LiveView state as "idle". Other code that use this function must be checked for possible side effects (this would be the most time-consuming step if we pick this solution). A very simple example:
if (!lv && display_idle())
which refers to photo mode outside LiveView, without any Canon menus open (therefore "idle" or ready to take pictures). Entering the paused LiveView will make lv = 0 (PauseLiveView -> PROP_LV_ACTION set to 1 -> lv = !buf[0]). Therefore, the above condition will be true after taking a full-res silent picture.
Is it desirable to change this behavior? You can't answer without reviewing each piece of code that calls this function.
A refactor might help, but it's pretty complex code not covered by a test suite (other than manually trying the affected features).
Or, allow the extra mode just in the audio trigger (easy, will not break other functionality, but the resulting code may look a bit ugly). Probably not much worse than it already is.
Another suggestion:
Quote from: a1ex on October 20, 2016, 04:48:10 PMRight - playing with the functions called by mlv_snd might help. The audio side shouldn't depend on the display operation, but most likely, Canon's powersaving turns off both of them.
Another workaround would be to let audio remote shot work on top of Canon menu. That would reduce the power consumption a lot.
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. I tried faking a half-shutter press after saving the FRSP but was unsuccessful getting that to work. Maybe once the EOSM goes into the paused LV state only a button press can wake it from a coma. As a1ex noted this only happens with FRSP.
Quote from: dfort on February 23, 2017, 11:19:28 PM
...I tried faking a half-shutter press after saving the FRSP but was unsuccessful getting that to work.
How exactly was this attempted? Some sort of a script?
For my film transfer application, I would prefer the display to remain active. I need to monitor the frame count, so I can harvest my chip before it fills. Keeping the last captured frame in view allows me to see what is happening on the film. My station currently uses a 650D/T4i, and I have a web cam viewing the LCD display and am pumping the webcam video downstairs to my living room. Would the goal be easier if the display didn't get powered down? I don't want power save features. Everything is powered off the line and needs to be monitored continuously.
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.
For example - use externally clocked video mode and connect a remote release cable from the camera to a reed switch (magnetically operated). Then a magnet is attached to a gear on the projector that rotates once per frame triggering the video frame capture then waiting for the next frame allowing precise synchronization between camera and projector.
The big advantage of external clocking combined with 10 /12 bit video mode is that film capture involves about 1k frames per minute of film for amateur gauges and about 1.5k frames per minute for professional systems. So by combining storage savings of lower bit rates and taking video output directly into color grading apps, without intermediate processing, would be a big time savings. Also if using video mode can allow higher frame rate 15- 24 FPS capture then the old projectors can be used for film transport without needing to modify the drive speed using some kind of mechanical reducer.
If it's possible to not require ML scripting and only a simple external switching system to capture film into high-quality ML files it will enable a larger group of users to preserve the past. I am working with my cousin on our family film project and he built Pi powered project which works really well, you can read about it here http://spectrum.ieee.org/geek-life/hands-on/how-to-convert-old-film-reels-with-a-raspberry-pi (http://spectrum.ieee.org/geek-life/hands-on/how-to-convert-old-film-reels-with-a-raspberry-pi) Joe and I exhibited the project at the 2016 NYC maker faire and there was a lot of interest. Being able to use ML and the higher quality Canon sensors would be great.
If it helps - this video is a refresher on how a projector works https://www.youtube.com/watch?v=En__V0oEJsU (https://www.youtube.com/watch?v=En__V0oEJsU)
Mike
Quote from: DeafEyeJedi on February 24, 2017, 01:37:08 AM
How exactly was this attempted? Some sort of a script?
No, just tweaking the code.
Quote from: Meloware on February 24, 2017, 04:35:49 AM
...I would prefer the display to remain active...My station currently uses a 650D/T4i...Would the goal be easier if the display didn't get powered down?
I just tested full resolution silent picture on a 700D/T5i and it exhibits the same behavior as the EOSM and I suppose the same as the 650D which is to go into LV pause mode after the FRSP is saved. The 650D and 700D can use wired remotes and the EOSM has to rely on Audio Remote Shot and some way of feeding a signal to the mic to make up for the lack of a real audio remote but you can't wake the camera via Audio Remote Shot. Triggering via USB not possible on the EOSM so that's not an option.
What I discovered works, though it is exactly what you don't want, is to turn off image review. The first audio event will take a shot, the next audio event will reset, next will take a shot, etc. just like it does with your 650D setup. Live view remains dark though. Now if you set image review for any amount of time, even 2 sec., the EOSM goes into that LV paused comatose state indefinitely and only doing a physical shutter half-press will release it from that coma. Oh it would be so nice if it can just go back to regular LiveView like it does with simple silent picture.
Quote from: a1ex on February 22, 2017, 09:24:28 PM
So, one way is to modify display_idle() to consider the paused LiveView state as "idle".
Looked at display_idle():
int display_idle()
{
extern thunk ShootOlcApp_handler;
if (lv) return liveview_display_idle();
else return gui_state == GUISTATE_IDLE && !gui_menu_shown() &&
((!DISPLAY_IS_ON && CURRENT_GUI_MODE == 0) || (intptr_t)get_current_dialog_handler() == (intptr_t)&ShootOlcApp_handler);
}
???
I can confirm that with the EOS M. When the image review is turned off, the entire LCD display is off. The HDMI output also becomes inactive. This means the frame count and SD memory capacity and performance is not displayed. Using the audio trigger twice for each exposure would require more electronics to be built in my controller. The full res video does get recorded this way, but at the expense of important operational information. The image review is very nice but not as essential as the status data. Thanks for pointing this out. This same technology in an industrial camera might cost $5000, so if this is as good as it gets, I could build more electronics and use other computers to track frame count. The goal of getting the image sensor to record would still be possible. By the way, the audio trigger also appears to work by simply shorting the wires of the microphone jack. My remote trigger for the 650D uses an open collector switch closure. I don't know if this alone could be a reliable audio trigger, but I could gate some of my stepping motor clock as an audio source.
QuoteWhat I discovered works, though it is exactly what you don't want, is to turn off image review. The first audio event will take a shot, the next audio event will reset, next will take a shot, etc. just like it does with your 650D setup.
Instead of "Live View" we might call this "Blind View". This Blind View RAW recording does work, but only to a point. Even though the Image Review feature is disabled, the LCD powersave timer is still active, and cannot be disabled from the main menu. Eventually the timer value expires and the camera goes into standby. Camera Auto Off can be completely disabled, but the continued camera operation is still at the mercy of the LCD Auto Off timer.
The shore powered movie transfer station needs to run for hours at a time. The limitation is the capacity of the SD memory card. Might we put a "Disable" option in the LCD Powersave list? Another possibility is to disable the timer altogether when Image Review is turned off.
@Meloware
I think I came up with something that will work for you. I put a special build on my bitbucket download page: https://bitbucket.org/daniel_fort/magic-lantern/downloads/
The name of the build is: magiclantern-Meloware-hack.2017Feb25.EOSM202.zip
Yeah, it is a hack. I'm forcing it into LiveView after saving each shot:
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);
+ force_liveview();
}
If you use this with the shutter button you have to do a quick half-press to take a picture. A longer half-press will focus the lens. I actually like this much better. Guess I could remove that "Long half-shutter will take another picture" message because it is no longer relevant.
@a1ex -- Did I do a bad thing here? What are the consequences?
Keeping an eye on this too. thanks
Dfort, this is great! Hack or not, we now have Silent Pictures MLV video recording, on the EOS M and triggered by the audio. Here is a summary of what I found so far:
Camera: EOS M
ML build: magiclantern-Meloware-hack.2017Feb25.EOSM202
Canon Menu setup:
Image Quality – RAW
Image Review – Hold
Power Saving: (LCD auto off: 1 min), (Camera auto off: Disable)
ML modules enabled: mlv_rec, silent
ML features setup: Silent Picture (Full-res, MLV), Audio Remote Shot: ON (level 10)
External trigger is a audio loop, connected into the camera's microphone jack. There is a 200 ms 1000Hz burst followed by 7.8 sec of silence.
About 1 second after the tone burst, the display announces the first messages produced by the exposure. This message only appears for an instant and is therefore unreadable. The captured imaged then draws (which is probably what eliminates the initial message). At about 3.8 seconds, the summary data flashes on screen, which contains the over all frame count and total SD memory use. This is also where the message about using a long "half shutter" appears.
Of the two message events, the last one is most important. I monitor the LCD with a webcam along with a second webcam which continuously views the equipment (in case something unexpected happens). I watch these two displays from another room, while watching television or doing other work. The last status message tells me when the chip is getting full and needs to be exchanged. If the system runs beyond the memory capacity, I lose part of the film and need to waste time recovering.
The system exposure interval is hand adjusted on my own controller and it is set (by eye) to occur just after the appearance of the "long half shutter" message. This interval is generally around 6 seconds, depending on the write speed of the SD memory. The "long half shutter" message is my visual clue that the camera is ready for another exposure (too bad there is no "camera ready" signal to tap into).
With this build, the camera is unable to cycle again until the appearance of the "Audio Release On" message, which occurs about 7.8 seconds after the start of the tone burst.
Summary:
Show Stopper! The LCD powersaver remains active and stops the recording after it times out. It cannot be disabled in the main menu and effectively needs to be. A 64 GB SD card takes over three hours to fill and 128 GB obviously more. In order to be practical, the system needs to run unattended for these kinds of times.
The exposure cycle time for this build is 8 seconds. This is two seconds slower than I currently have with the 650D and a remote shutter. Every second counts when you need to copy 30,000 frames for a 12 minute film. With this build, the "long half shutter" message occurs 4 seconds before the "Audio Release On" message. I am presuming the current frame is saved once the "long half shutter" message appears, so waiting another 4 seconds before you can take another exposure may be a big waste of precious time. Please investigate how fast the camera may be made to recover. I am hoping this can be twice as fast without too much trouble.
The final message, containing the "long half shutter", frame count, and used memory are important to see in order to know when the system needs servicing. Can this be made to linger long enough to clearly read? The captured image and initial message are of little importance as compared to this last message.
This build runs reliably, otherwise! I am grateful for ML's support and interest. I hope to publicize the value of your project. Your work makes possible professional quality digital archiving of museum collections, on a budget affordable to most of us. Aside from movie transfer, high volume copying of fragile books, ledgers, and other documents (too fragile for the flatbed scanner), will now be possible.
I hope this application is an unexpected and welcome surprise to your group!
Chris Clawson
Museum of Our Industrial Heritage
http://industrialhistory.org (http://industrialhistory.org)
Wonderful work @dfort once again!
@Meloware
Hi Chris -- what would really help is a video showing your system running and comparing the 650D with the hacked EOSM build. Nothing elaborate, a cell phone video would be fine. I'll try to run tests here with my 700D and EOSM to see if there is anything that I can do to help get your system up to speed on the EOSM.
I'm curious how you trigger the 650D because it should need two shutter half-presses per exposure. Once to put the camera into LiveView and then a second half-press to take the picture.
I'm surprised that the Power Save timer doesn't reset every time a picture is taken but since silent pictures don't trigger the shutter it makes sense in this case. A while back I wrote a very simple lua script to keep the LV alive by "faking" a shutter half-press. Maybe this will work as long as it doesn't shoot a frame when it goes off. This will probably require making another build using the lua_fix branch. I'll give it a try and get back to you.
Note that @garry23 is also working on a similar issue (http://www.magiclantern.fm/forum/index.php?topic=18787.0). He wrote several useful lua scripts so maybe he'll come up with something that will work for you too.
My only camera is the 650D. The EOS M has no lens, and I have no smart phone. I want to support you in any way possible, but am not sure how watching my system run might help.
The 650D remote shutter jack has two contacts. One is the shutter, the other is the Half-Shutter.
I start a job by button pressing into live view (with Silent and MLV_Rec enabled). I then start my external controller. The controller forces the stepping motor (on the projector) to begin running to advance the next film frame. An optical switch stops the stepper when the beam is broken, by the shutter wheel, signaling my system that another frame is ready to capture. The controller then asserts a long "half shutter" switch closure, which begins the camera cycle, and takes the picture.
At this time, I also start a "wait for the camera to be ready, again" timer. This is the timer I set by hand by watching for the appearance of the "long half shutter for next exposure" message. Once the "long half-shutter message" appears, the camera leaves the display on long enough to clearly read the message, and then the LCD goes black. My manually set "wait for the camera to be ready, again" timer expires and trips the controller's "kick timer", starting the stepper again and the next cycle begins.
I only button press into Live View once, at the beginning when I install a blank memory chip. From that point on, the only action on the camera will be the "long half-shutter" remote trigger from the controller.
I am pretty sure it is the LCD Powersave timer which is shutting down the EOS M. The camera is dropping into standby and I can control when this happens by changing options for the LCD in the powersave menu. If this is coming from the Powersave, the option is to provide an extremely long timeout (two days?), provide an option to disable it from the menu, or have it automatically disabled when the camera is operated in this mode.
As far as speeding up the cycle goes, I guess it depends entirely on what the camera is doing, and when. My experience with the 650D/T4i is that the camera is ready for another exposure as soon as the "long half-shutter" message appears. As I mentioned, the EOS M won't audio trigger until Live View is again active and the "Audio Release On" message appears. I certainly hope the overall exposure cycle can be shortened. Right now (with dfort's hack) it is about 8 seconds. Is 4 seconds possible?
This is incredibly frustrating! Canon puts a large, professional quality APS-C image sensor, in the camera, and then doesn't let you use it. I got the EOS M because my application doesn't require an SLR or even a shutter. Oh Boy, a mirrorless camera! I can shoot forever, right? Wrong... the thing still has mechanical components that wear out. One hundred thousand cycles may sound like a lot, but that is only around three 12 minute films, for me. Magic Lantern works great with my 650D, but I wish I could free it up and use my new EOS M. ML is my best hope for a solution.
Looks like this project is pointing out areas in ML that could use some TLC.
It might be possible to do what you need with a lua script (https://www.magiclantern.fm/forum/index.php?topic=14828.0) but -- there doesn't seem to be a way to hook into the code that triggers AUDIO_REMOTE_SHOT (http://wiki.magiclantern.fm/userguide#audio_remoteshot). That could be handy for several applications especially on the EOSM because it doesn't have a wired remote.
Your application could benefit from lossless DNG compression (https://www.magiclantern.fm/forum/index.php?topic=18443.0) which will give you smaller files and thus more frames per card.
You'll probably experience a speed boost if you save to MLV (https://www.magiclantern.fm/forum/index.php?topic=7122.0) instead of DNG. In addition, MLV on the EOSM and several other cameras now has the ability to save as 12bit or 10bit (https://www.magiclantern.fm/forum/index.php?topic=5601.0). This will give you smaller files with virtually no loss in quality so it might be an even better choice than saving to DNG. However, this hasn't been applied to the silent module yet.
Oops--looks like this project just opened up a can of worms.
@Licaon_Kter -- I know you're watching but have you tried that test build I posted? It seems to me that FRSP and simple silent should have the same user interface. Isn't it strange that you need to wake up LiveView to see what you are shooting with FRSP after the first shot? A long shutter half-press is needed to get back into LV and a long half-press is also used to focus and Meloware is using an even longer half-press on the 650D to get into LV and shoot the next shot. I like the long half-press to focus and short half-press to shoot and keep LiveView active until the power savings setting turns it off.
Quote from: dfort on February 28, 2017, 04:43:56 AM
@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 (http://www.magiclantern.fm/forum/index.php?topic=12523.msg145189#msg145189). :(
Quote from: Licaon_Kter on February 28, 2017, 10:20:00 AM
The tricky black screen has been here for a while (http://www.magiclantern.fm/forum/index.php?topic=12523.msg145189#msg145189). :(
Right. The issue you pointed out was marked resolved (https://bitbucket.org/hudson/magic-lantern/issues/2265/turn-off-lcd-enabled-stops-intervalometer) 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.
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:
/* 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.
Fixed intervalometer. Mm, nice one.
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.
Quote from: miket on February 24, 2017, 03:44:14 PM
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. https://youtu.be/TtCu1tHlCk8
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?
I put in a feature request to add a lua hook for audio events (http://www.magiclantern.fm/forum/index.php?topic=19105.0). 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.
Quote from: dfort on February 28, 2017, 07:18:28 PM
The issue you pointed out was marked resolved (https://bitbucket.org/hudson/magic-lantern/issues/2265/turn-off-lcd-enabled-stops-intervalometer) 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)
Quote from: Meloware on March 02, 2017, 02:41:21 AM
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.
Quote from: dfort on March 03, 2017, 05:23:20 PM
I put in a feature request to add a lua hook for audio events (http://www.magiclantern.fm/forum/index.php?topic=19105.0).
That's certainly useful, but for solving this I think it's overkill. Fixing the audio remote behavior is probably a better idea.
Quote from: dfort on February 23, 2017, 11:19:28 PM
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.
Quote from: dfort on February 28, 2017, 04:43:56 AM
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.
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.
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?
Quote from: a1ex on March 03, 2017, 07:06:05 PM
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?
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();
Thanks! It runs forever now.
Let's try a small test. This goes to paused LiveView and enables audio meters on 5D3.
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).
quote from: Meloware on March 02, 2017, 02:31:18 AM
QuoteIf 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
QuoteMy 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 (https://vimeo.com/178795898)
quote from: Meloware on March 02, 2017, 02:31:18 AM
QuoteThe 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
@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:
[ 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.
Quote from: dfort on March 05, 2017, 03:02:50 AM
debug.c:(.text+0x6c0): undefined reference to `SoundDevActiveIn'
FF110D88 in 1.2.3.
Quote
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.
QuoteThe 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.
Quote
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.
Quote from: a1ex on March 05, 2017, 06:51:20 AM
Quote from: dfort on March 05, 2017, 03:02:50 AM
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.
Quote from: a1ex on March 04, 2017, 10:05:08 AM
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?
Quote from: a1ex on March 05, 2017, 06:51:20 AM
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.
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.
@dfort - I have updated the photo links. Thanks.
@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/
Quote from: a1ex on March 05, 2017, 09:12:23 AM
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:
/** 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.
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.
Quote from: a1ex on March 04, 2017, 10:05:08 AM
Let's try a small test. This goes to paused LiveView and enables audio meters on 5D3.
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!
Quote from: dfort on March 07, 2017, 01:18:22 AM
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
Quote from: Walter Schulz on March 07, 2017, 06:31:58 PM
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!"
(https://c1.staticflickr.com/4/3800/33309484755_cca176ed8d_z.jpg)
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.
(https://c1.staticflickr.com/1/634/33309484815_71be273e67_c.jpg)
Here's the branch I'm working on: https://bitbucket.org/daniel_fort/magic-lantern/branch/a1ex_tests
Quote from: josepvm on March 07, 2017, 08:15:47 PM
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?
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.
static int audio_meters_are_drawn_common()
{
return 1; // test for a1ex - this is where it goes
Now to continue with the test:
Quote from: a1ex on March 04, 2017, 10:05:08 AM
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:
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?
Quote from: Walter Schulz on March 07, 2017, 06:31:58 PM
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
Thanks, Daniel!
Will test it ASAP and report back.
@a1ex: Quick question ... should it look like this on 7D and 650D after power on?
No settings changed, just copied build to bootable card and started up in photo mode.
-> Flickering sound meters at bottom.
Download (Sorry for language mixup (http://filehorst.de/d/bfmbgafm)
EDIT: Visible in all ML menus in photo mode, GD off/on doesn't matter (restart applied).
audio_meters_are_drawn_common() always returns 1 (true), so the audio meters are always displayed after this change.
They may fight with other GUI elements when they are not expected.
Thanks!
First test with 650D and 7D:
FRSP with Audio RemoteShot working.
Walter Shulz:
QuoteFirst test with 650D and 7D:
FRSP with Audio RemoteShot working.
I there a build, for the 650D, which implements Forced Live view (with audio trigger) 650D? Did I miss this?
I am trying to determine the status of dfort's Forced LiveView modifications. I am currently using dfort's
magiclantern-Meloware.2017Mar03.EOSM202 build.
Is the modified source for this build available?
Are these features going to make it into the unified branch?This build fixed the problem of the camera dropping into standby (while in FRSP) from the timer set by the LCD display powersave value. I have found that same problem exist with Silent Pictures in Simple mode.
Is it easy to prevent the Powersave timeout on Silent/Simple resolution, as well?Currently, with the EOS M, the total exposure cycle for FRSP (recording to MLV) is about 6.5 seconds. I'd love to have this faster, but it is actually similar to the cycle time of my 650D and a true remote half-shutter trigger. The Simple resolution (with the EOS M and audio trigger) cycle time is about 2.6 seconds. It is harder to measure with the 650D, but it may be faster. I realize the memory chips used may affect this, but both of these cameras only seem to support first generation SD cards.
Is there any likely way of improving this cycle (or write) time, in the near future?The write cycle times for these SD chips increases as the memory fills. Without access to a "camera ready" signal, the worst case scenario needs to be guessed at and set. I had hoped to modify the use of the flash shoe to re-task as a "camera ready" status output. Any flash related code I can find is intimately tied to the shutter operation.
Is there any known possibility of forcing a flash event, without involving the shutter?The only other possibility I might see, is in generating some kind of flashing semaphore with the status LED, and detecting it with a photocell and external electronics.
The Lua scripting has a well documented API. I have not seen any documentation for an API which directly accesses the Canon functions (presumably as would be needed in writing the modules).
Could you please tell me where the Canon functions are defined? Are they all known?My camera had to sit on the shelf for two years, before I found my needed functionality in Magic Lantern. Thank you for the support and I hope to see great stuff continue to be developed.
Quite a few questions. I can answer some.
Quote from: Meloware on March 11, 2017, 12:26:15 AM
...a build, for the 650D, which implements Forced Live view (with audio trigger) 650D? Did I miss this?
I am trying to determine the status of dfort's Forced LiveView modifications. I am currently using dfort's
magiclantern-Meloware.2017Mar03.EOSM202 build.
Is the modified source for this build available?
Are these features going to make it into the unified branch?
We are running a test for a1ex to see if the camera can still "listen" while in paused LiveView mode. So far it is looking good. I experimented substituting a call to SoundDevActiveIn instead of force_liveview but haven't found the right way to do this yet.
For now I'd recommend keep using that build I made with the force_liveview for your film restoration project even though it probably takes a bit longer before the camera is ready for the next exposure.
The source I'm working on is here: https://bitbucket.org/daniel_fort/magic-lantern/branch/silent_FRSP_fix
This needs some more tinkering with the code before it is ready for a pull request and then tested under various conditions before merging into unified.
Cycle time: your best bet is to record raw video at some low frame rate - this method is already optimized pretty well for file writing speed. If your hardware cannot work with exact timing (that would allow some open-loop sync), you can probably discard some frames in post, but you'll need to find out transitions between frames (basically some sort of clock recovery (https://en.wikipedia.org/wiki/Clock_recovery) from the video stream). An advantage of this method would be increased dynamic range (don't know if you need that, but since you asked for flash, I assume you do) if you average multiple digitally recorded frames (of the same static scene - in your case, one film frame) to get one output frame (with less noise, therefore more DR).
There is even hardware support for adding video frames in Canon's image processor (therefore, averaging a few LiveView frames to save a single frame can probably be done) - see EekoAddRawPath (http://www.magiclantern.fm/forum/index.php?topic=13408.0).
I'm also considering a modification to raw recording to save only those frames where half-shutter is pressed (or even only one frame on half-shutter transition).
Flash event: no idea how to trigger it without a picture; this may help (http://www.magiclantern.fm/forum/index.php?topic=17596.0), but I'm afraid the decision appears to be taken by the MPU (http://www.magiclantern.fm/forum/index.php?topic=18123) (secondary processor that controls a lot of I/O), probably to sync it with shutter motion. There might be some debug commands, but currently the MPU firmware not very well understood.
Where Canon functions are defined? The sticky topics from the Reverse Engineering board should answer this, however it's probably best to get started with something easier.
A1ex: thank you and dfort's patience with my somewhat ignorant questions. I very much appreciate your efforts to solidify the use of Live View and audio triggers, and didn't fully realize the recent posts on this thread were working on just that.
I am not sure you understand my context in mentioning "Cycle Time" and the use of a flash shoe without also triggering the shutter. My work with these Canon cameras and ML are to produce a poor man's movie film transfer and digital restoration system. ML allows budget minded, professional quality transfer, and Blender's compositor feature allows an amazing set of post production tools, before the result is sent for final rendering in AVI Demux.
A ten minute sound film requires 14,400 individual frames to be captured in the camera. This number of cycles would destroy the shutter of my 650D, and to my horror, the mirror-less EOS M still employs mechanical components which would quickly wear out under this kind of use. My only option, with these cameras, is ML and the Silent Pictures feature.
Although I am recording raw video, the system is synchronized to only take one exposure for each frame of film.
With so many frames, it takes days of frame by frame image capture to digitize an average movie. My definition of the term "Cycle Time" refers to the interval required for the camera to capture an image, save it, and then recover and be ready for the next frame. The MLV_Rec feature is great and allows frame capture at a rate superior to saving individual DNG images. My film capture system would still benefit greatly from any improvement in the time it takes to save images.
The flash shoe question was related to my quest to find a way for the camera to indicate to my external equipment that it is ready for the next exposure. As a SD memory fills, it takes longer and longer to save each successive frame. Right now, my system has to "guess" when the camera is ready, before it initiates an exposure. This worst case guess is what defines my cycle time, for each frame. If I could generate a machine readable "yes, I'm ready" signal, that would be my trigger to initiate another exposure (rather than using a worst case dumb timer). I had hoped I might use the flash shoe switch closure to signal this. If that use isn't possible, my only other option would be to flicker the camera's status LED in a machine readable pattern, and have a photocell or photodiode sense the event and signal my equipment.
Between you and dfort, I appreciate you addressing most of my earlier questions. I will wait now for you guys to have something to test.
The only remaining issue from my earlier post, is the problem of preventing my EOS M from dropping into Power Save standby, when recording in Silent Pictures/Simple resolution. This mode would be very useful and fast for 8mm capture. Simple resolution may be about all standard 8mm needs, given it's very small frame area. It seems that the camera drops into power save standby, as defined by the LCD timeout value. Could this be over-ridden when using the camera in forced Live View? Keep your priorities, but please also consider this one in due time.
This mod might be useful as well: http://www.magiclantern.fm/forum/index.php?topic=17069.msg181236#msg181236
(half-shutter trigger for mlv_lite; experimental build already available). You should be able to simply connect your trigger signal to half-shutter, and mlv_lite will record one frame on every half-shutter transition (with buffering, fast write speeds etc). In mlv_lite, powersave is not an issue.
To get a machine-readable signal that camera is ready, you can probably use the display backlight, the card LED or a beep. This may require minor changes to the silent picture code. Not sure if there is any usable signal on the external monitor cables - it's pretty easy to switch the display between external and internal monitor from code, so if you can get an electrical signal out of this, it might be a good option.
On old cameras there is a blue LED, which is pretty strong and not used by Canon firmware under normal conditions. That might be an option as well.
It's also possible to interface the camera with an Arduino over USB.
Those are some good suggestions -- for other cameras. The EOSM is severely limited when it comes to doing a remote trigger. There is no jack to plug in a remote and I don't think there has been much success using the USB port. There is the IR remote but most users seem to be using AUDIO_REMOTE_SHOT.
According to @Meloware it takes longer to save an image as the card fills up so perhaps the camera should be the master and the film scanner the slave? Not sure about the EOSM having a blue LED but maybe there is a way to turn the focus light on and off? I got this idea from a movie I worked on years ago where they used a laser pointer synced to the camera's shutter so that they could get the actors' eye line to follow a CGI character that obviously wasn't there during the shoot.
I have been experimenting with SoundDevActiveIn but haven't been successful. The only thing that is working for me is force_liveview. I was thinking of creating a menu option for Full-res that always goes to LiveView instead of leaving the camera in QR or paused LV.
Maybe call it "Full-res with LiveView" ?
I am beginning to think about building other render stations for some of the 8mm formats. My controller was built out of my TTL parts drawer and it proves how far behind the times I am. A Raspberry Pi (or Arduino as a1ex suggested) would be far easier to use, these days, and I would be able to publish a design which would be easier for everyone to duplicate. All the clock, sense and control signals could be done, with the Pi, and could even support different modes of operation. The only other components would be the projector's optical shutter position sensor, the stepping motor, the $12 Chinese stepping motor controller, and power supply.
A big question is if the camera can be made to send ML control messages out of it's USB port. I agree with dfort that it should be the camera that needs to be master in this system. Everything else can wait until the camera is ready, but without a "camera ready" signal, the system needs to rely on a "worst case" dumb timer. Has anybody been able to make any use of the camera's USB port? All of the cameras, in the ML family, have USB, right? This has some real potential. Please speak up if you have some experience accessing the camera's USB interface. I am a long ways away from trying to tackle this, myself.
As an alternative, the code-pulsed LED is awkward, primitive, but doable with known ML function calls. A Raspberry Pi could help here, too, but a true USB connection would obviously be superior. The IR remote is only an input, right? Even if it was to be used as a exposure trigger, it still wouldn't serve for a "camera ready" status signal.
In the mean time, thanks for the continued effort in dealing with the Live View issue.
Ok -- here we go:
(https://c1.staticflickr.com/4/3709/33408769306_17a0979431.jpg)
This works with audio remote. It is also great if you want to keep an eye on the intervalometer counter. Getting this working was challenging and it could probably use some finessing but it is working so I'm putting up an EOSM test build on my download site:
https://bitbucket.org/daniel_fort/magic-lantern/downloads/
Source code is here:
https://bitbucket.org/daniel_fort/magic-lantern/branch/silent_FRSP_fix
I'll make a pull request once I test it out on the 700D and 5D3.
What about one of those?
- add an option that would be valid only when full-res is selected (similar to slit-scan mode)
- listen to Powersave in LiveView setting (avoids YAMLMO, but may be less intuitive and increases coupling)
In both cases, you avoid the need to check for both full-res modes.
We can also hide the options that are not valid in the current mode, rather than just graying them out.
Also it's probably best to keep the image review delay, as configured in Canon menu. However, that's a bit tricky, as the delayed_call routine runs from a timer interrupt, rather than a regular task. That means, checking whether we are in LiveView and sending a fake keypress are OK, but waiting for the action to finish, or any kind of delay (msleep, waiting at semaphores or long computation) are not.
So, you'll need a routine similar to display_off_if_qr_mode() - except the actual switching to LiveView would probably have to be delegated to silent_pic_polling_cbr. I somehow doubt "pressing" the LiveView button will cause Canon firmware to exit the paused LiveView mode, but might work for QuickReview (so I'd expect this method - of sending a LiveView press from the timer interrupt - to work only with image review enabled). The other one - delegating the LV switching action to the polling CBR - should work in both modes.
Had to Google YAMLMO - Yet Another Magic Lantern Menu Option.
I'll check into your suggestions. Tested it with various image review settings on the Canon menu and it is working fine on all settings.
This works great for my purposes! Using my EOS M, dfort's build, and a SanDisk Ultra HC1 SD memory:
Full Resolution cycle time (from audio trigger to ready for next exposure) is about 6.47 seconds (saved to MLV video file).
Simple Resolution cycle time is about 2.7 seconds.
Theoretically, this means a 10 minute sound film can be copied in 26 hours (in full resolution). (Don't gasp! That is actually practical when expensive equipment isn't tied up in doing the work).
8mm movie frames are much lower resolution, and those transfers may not benefit from FRSP. A Silent/Simple resolution transfer will be 60% faster than FRSP.
With Silent/Simple mode (and LiveView), the camera is no longer dropping into standby, based on the LCD powersave timer. This can't be an accident! You fixed that, as well, right?
I'd like to develop this application to the point where I can define it and publish it. With these features, ML can now offer an important, affordable way for historic, non-profit organizations to perform digital transfer of their movies and create digital collections of fragile books and documents! My earlier post mentioned using an Arduino or Raspberry Pi, as a next generation system controller. Arduino seems to be more inclined to market kits with specific functions, where I need to quickly design and build a hardware controller. Pi may be the way to go.
I now have a Oracle VM now capable of building ML. I was able to compile unified and run it in my camera. I haven't had the nerve to modify any code yet, but as I learn more I may hope to have some intelligent optimization questions. Unfortunately, the older cameras don't seem to support the newer generation, faster SD memories' high speed functionality.
Thank you again for the great support, and I hope to soon be able to offer some video and documentation of the valued uses for this feature!
Quote from: Meloware on March 16, 2017, 12:45:41 AM
With Silent/Simple mode (and LiveView), the camera is no longer dropping into standby, based on the LCD powersave timer. This can't be an accident! You fixed that, as well, right?
a1ex fixed that and it is now in unified.
https://bitbucket.org/hudson/magic-lantern/commits/c46ffb21e7a7bb2fab56f83f97b1fd121a8dfcd6?at=unified
He also started a topic on writing modules starting from a simple "Hello World" module. I already got a lot out of it.
http://www.magiclantern.fm/forum/index.php?topic=19232.0
An update:
I am grateful for the modifications in ML made to support this thread. I am still planning to make a video explaning my setup, but in the mean time it might be okay to post a link to an 8mm movie film I copied with the EOS-M, using these special Magic Lantern builds. My final post-processing was done in Blender, and the resulting frame sequence was encoded with Avidemux and uploaded to YouTube. Please enjoy! https://youtu.be/CZevC9i2JGU
amazing you could do that. capture 8mm film to archive it. looks great.
Amazing work @Meloware and thanks for sharing us with what @dfort could help make possible on your end. An excellent way to archive ancient films. This is evolution in the making!