Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - dlrpgmsvc

Pages: [1]
General Development / 50D and 7D DUAL_ISO in MOVIE mode PORTING thread
« on: October 14, 2014, 11:54:35 AM »
This thread is for concentraring all the findings, discoveries, and tries to port the dual_iso feature in movie mode for the 50D and 7D (currently it works only in photo mode on both cameras).
All bits of useful informations on how to obtain this goal are welcome here.

Why 50D and 7D together in a single thread ? Just because 50D has the same display filter method used on 7D, so, if someone discovers something on 50D or 7D, then the other camera can benefit immediately of the same findings.

Everyone that tried or is currently active into porting this feature on the above cameras, is invited to post here his current efforts, in order to be of help for others and to be helped from others also.

This first post is kept updated with the last findings highlights and with the current porting status.



[1] The unified method used into current "dual_iso" module, regarding dual iso in MOVIE mode, seems not applicable for 50D and 7D.
     A completely NEW method seems to be discovered and developed for these cameras. But works are in progress to validate this thinking.
     As stated by 1% : "the only real hope would be finding other regs for dual ISO that directly configure the digic/sensor".

[2] 50D has the same display filter method used on 7D, so, if someone discovers something on 50D or 7D, then the other camera can benefit immediately
      of the same findings. So, feel free to take advantage of findings found on both cameras, without concentrating only on a specific one when reading there.

[3] Starting from 7D to discover how to do dual iso for movies, is the hard but only way if you own only the 7D. Instead, based on point [2] of the findings section,
     it is a better and easier way to find how to do this on 50D, and then, once discovered, the porting on 7D will be likely an (almost) copy-paste matter.


[1] Based on 1% and other valuable developers current experiences, SLAVE debugging will get you nowhere : Dual_ISO for photo on the 7D is on the master, so likely it is also for video.


[1] You can find the dual_iso module sources by following this source path : " Magic Lantern / modules / dual_iso / "

[2] You can open the file " dual_iso.c " and find the line number 675 where the function " static unsigned int isoless_init() " is defined.
     Inside this function, you can find all the constants definitions subdivided by camera model. Concentrate on the block that is for 50D or 7D.
     You can see there is a constant declaration serie named " PHOTO_CMOS_ISO_xxxx ", where " xxxx " are various names: these are for PHOTO mode.
    We have to find the constants named " FRAME_CMOS_ISO_xxx ", present on other camera models blocks definitions, that are for VIDEO mode.

[3] The values to find are the following (WARNING: be careful trying to find them, it seems that a new method must be developed, read further down) :
     FRAME_CMOS_ISO_START = it is the CMOS register 0000 - for LiveView, ISO 100 (check in movie mode, not photo!)
     FRAME_CMOS_ISO_COUNT = it is the number of different ISO values from ISO 100 to xxxx, where xxxx is the max ISO value allowed for 50D or 7D
     FRAME_CMOS_ISO_SIZE  = it is the distance between ISO 100 and ISO 200 CMOS registers addresses, in bytes
     You can simply add these constants declarations into the 50D or 7D block and compile, then you can see if the values found are right or not by running ML on camera,
     by activating dual iso in movie mode and start recording, then evaluating the resulting recorded video file. Beware: possible camera brickings are your
     responsability only. Nor me or ML can be held responsible for any damage caused by these experimentations on your camera or equipment.

[4] Example PHOTO findings for 550D (WARNING: be careful reading this, because it seems that a new method must be developed, read further down) :
     By examining the disassembly of the 550D ROM, the following was found :
     00 0000 406941E4               = 100     ISO
     00 0024 406941F6               = 200     ISO
     00 0048 40694208               = 400     ISO
     00 006C 4069421A               = 800     ISO
     00 0090 4069422C               = 1600   ISO
     00 00B4 4069423E               = 3200   ISO
     Hence, the registers values are :
     PHOTO_CMOS_ISO_START = 0x406941E4;  // CMOS register 0000 - for photo mode, ISO 100
     PHOTO_CMOS_ISO_COUNT = 6;                 // from ISO 100 to 3200
     PHOTO_CMOS_ISO_SIZE  = 18;                 // distance between ISO 100 and ISO 200 addresses, in bytes

[5] On 50D or 7D SLAVE, just compile with the switch GDB=Y and use the ADTG_LOG module. 1% have the addresses in his repo where all the functions are :
      Copy the 50D or 7D addresses to whatever ML you are compiling and get rid of whats there. the modules only work for one camera at a time.
      As per 1%, uncomment whatever the ones you need. The reg on 50D or 7D should show up in the logs pretty quickly, ISO value matches photo mode values. Changing it did nothing
      so you need to find a completely new method to dual ISO or see what is going on. For more info on this method, see point [3] under "INSTRUMENTS YOU CAN USE IN GENERAL
      (50D AND 7D SLAVE MODE ONLY)" under here. However, if you are on a 7D, BEWARE on point [1] under "7D UP-TO-DATE FINDINGS": in SLAVE mode there is nothing to find, so you
      have to use this method under MASTER processor, but in this case you have to "sign" the BIN (see point [1] on "7D UP-TO-DATE DIRECTIONS" just here below).


[1] Please, note that 7D has TWO processors inside. So, debugging is a bit more complicated: two different processors (the "master" and
     the "slave") must be debugged separately in order to find complete informations.
     The processor on which ML is based is the SLAVE. It can run ML code with a simple compiled BIN file, like for the majority of the other cams.
     The MASTER processor, on the other hand, can run ML code only if the BIN file is "signed" with a particular private "signing key" (known only to few
     ML developers, because it cannot be of public domain, peraphs for Canon copyright reasons). So, if you want to debug the MASTER processor,
     you have not only to compile the BIN as usual (by using the same procedures for the SLAVE processor), but you have, as the final step, to
     "sign" it, making it becoming a file with .FIR extension. You can try to ask devs for the key, or you can ask them to sign your BIN for you, but
     they have to agree to your request, and this is not assured by any way. Compiling for MASTER is useful (for now) only to find registers changes and others
     manipulations done by the master, but then, once discovered these operations, you can implement them down to the SLAVE without problems.
     Like 1% says, you can read/write small amounts of data to the master through canon provided mechanisms (using the SLAVE processor), and this is enough
     for headphone/fps and few registers. Taking over canon functions (ie: to do GDB or registers logging on MASTER) needs our own code running there (on MASTER).
     You can follow directions and you can start compiling for the MASTER processor in the 7D MASTER processor branch here:

[1]  On dmilligan advice, you can use a more visually engaging and immediate debug method by using ADTG_GUI module you can find here:
       you can compile it and then you can put the compiled files inside the other modules directory, then you can select it from the ML modules menu.
       Also, you need a special compilation switch when compiling the main BIN file: follow the directions inside the above link.
[2]  As on 1% advice, GDB (a log file debugging method) can be used in order to discover behaviors and registers on 50D and 7D. GDB is a debugging
      environment that is loaded into camera like the normal ML main program and in LIEU of it. This writes debug data to a
      log file inside the memory card, from which you can analyze data inside it by downloading and reading it through a PC and a card reader.
      More info and files to download in order to get started can be found here:

[3] You can use ADTG_LOG module. It's similar to ADTG_GUI module as on point [1], but it's not visual, and instead of writing registers on screen, it
     writes results on a log file inside a directory located on camera memory card. Also, you cannot write into register as you can do in ADTG_GUI.
     You can find 1% version on his repository here (disregard it's for 6D):
     or, alternatively, you can find it on the unified original ML repository here:


[1] Same as point [2] under previous section (read it for more info) but there is a difference:
      in order to work inside the 7D MASTER processor, based on 1% instructions, you need to set up code in the 7D master branch
      (there are skeletons in there for other registers), but then you need to "sign" the bin in order for it to be run on MASTER: more info on this
      can be found above under "7D UP-TO-DATE DIRECTIONS" at point [1]. The 7D MASTER branch can be found on 1% repository there:
      or it can be found also under the official ML repository there :

[2] Same as point [3] under previous section (read it for more info) but there is a difference:
      in order to work inside the 7D MASTER processor, based on 1% instructions, you need to "sign" the resulting BIN in order to make it running on
      MASTER processor: more info on this process can be found above under "7D UP-TO-DATE DIRECTIONS" at point [1].

Forum and Website / ML features page lack
« on: October 02, 2014, 10:30:11 PM »
The ML features page here:

[1] Lacks into the differentiation of "dual_iso" module use for photo and for video: some cameras can use dual iso both for photos and videos, and some others can only use dual iso feature only for photos. But there is no indication here.
Do it is possible for someone to add this differentiation ? Many thanks !

[2] Lacks into the differentiation of "fps_override" feature for RAW and for H264 modes. For example, 7D is only able (for now) to use fps override only in RAW mode and not in H264 mode.
Do it is possible for someone to add this differentiation ? Many thanks !

I can help maintaining this features page for my small contribution (limited to 50D and 7D) if needed. Let me know !

Feature Requests / USB keystrokes sender / receiver
« on: February 26, 2014, 02:09:24 PM »
There should be a "simplified" version of "ML controller for Android" where we use an android tablet only to simulate the camera keystrokes, and we can see the results on a HDMI external monitor. Not a full ML menus replication on the tablet: this full replication will require a continuous updating effort to catch-up with the latest ML version: unfeasible.
Also not a canon lcd-to-tablet replication with full ML overlays, because also this will require a continuous versions catch-up. For monitoring with full ML overlays, we will use a simple HDMI monitor.

This "only keystrokes sender/receiver" will be useful for jib cranes operations and other similar cases where a remote controller station is a must.

I'm thinking we can arrange an "Android/pc USB keystrokes sender" on the remote side, and a "usb keystrokes listener" process inside ML (as a module will be perfect), based on a polling or (best) on interrupt.
We can arrange a standard "USB command-to-camera key" mapping table, and then all the subsequent new ML versions will be 100% compatible with the unified "Android/PC - to - Canon camera" remote protocol.

Obviously, we can add also the classic PTP protocol part, used for follow-focusing, changing the aperture and so on with a single command.

The setup will be : external HDMI monitor + Tablet pc / Android canon camera remote control surface (there will be only depicted on screen the various camera buttons, each pushable by a tap).

Programmatically speaking: for the receiver side (ML code), we can write a USB-command listener routine (activated by interrupt) that, upon receiving the key-press command from remote party (pc or android, via USB), triggers artificially the corresponding canon body key-press event interrupt routine. So that the rest of the ML code will remain untouched. Do some ML coders here can confirm that this is feasible ?

What I have found so far that can be useful :

General Help Q&A / The ML resources directory
« on: August 31, 2013, 02:55:23 PM »
This thread wants to be of help as a reference links directory repository to all the ML resources.
This main first post is constantly updated, and if someone knows other links to ML or related interesting resources, please: chime in by writing into this thread ! Many thanks in advance for everyone that will contribute !

======== GENERAL INTEREST ==============================================================

It is a Google docs spreadsheet maintained by user "dlrpgmsvc" where all video and photo recording experiences from various ML users can converge.
The spreadsheet is read-only in order to keep it clean, coherent and precise, but everyone can give his contribution by submitting his experiences on the submission spreadsheet. Periodically, all the submissions will be transferred to the main spreadsheet after a minimal check. Important: if you see your camera-resolution-card has already been covered, don't hesitate to give also your data, because results vary within the same camera models and cards, so, the more results we have, the more we can know on how to expect about the variance between the same cameras and cards!
main           :
submissions :

It is a Google docs spreadsheet maintained by user "Roman" where all raw recording capabilities of various ML cameras are listed.
Inside this spreadsheet there are also many other sheets where various technical caracteristics are listed for every camera, most are specialistics for developers only, while others are ineteresting also for the normal user.
The spreadsheet is open for modifications to all.
main :

Feature-by-feature supported ML functions for all ML supported cameras

This thread explains how to contribute to the big unified Magic Lantern Manual. This is a one-place manual that is automatically spanned over the Magic lantern Wiki, over the Magic Lantern Unified builds and inside the on-camera help system. So don't hesitate to actively contribute !
main :

======== ONLY FOR DEVELOPMENT ==============================================================

This teaches in a very detailed way how to start developing in Magic Lantern the easiest and fastest way.
english language :
italian Language  :

This is a spreadsheet where to converge in order to log all the discoveries made about the ADTG registers for every camera

[1] Create a BitBucket account (go to "" and select the "sign up" option.
    At the end, bookmark your bitbucket page and write down his web address (url). If, for example, we have chosen
    "dlrpgmsvc" as our username, we will end up with our bitbucket address as follow : "")

[2] Once inside our bitbucket account, we need to "fork" the magic-lantern project. In order to do that, we must go
    again to "" (you will see that now we are logged in in bitbucket because
    in the upper right corner you will see a man-symbol, that represent you) and then push the upper right button named
    "fork". In this way, all the current and up-todate magic lantern sources are copied inside our bitbucket account: wait
    for the finish of the copy process, and at the end, if you return to your account page (""
    in our example) you will find "Magic Lantern" listed as a fork: now click on the name "Magic Lantern" and you will enter
    inside your fork (parallel derivative project), inside which you can work as you desire. But for this moment leave all
    as-is. Write down our complete fork address, that is, in our example : ""

[3] Download and install "Virtual Box" (go to "" and select "downloads" to the left, then select
    the version suitable for your operative system ("windows", in this case)
[4] Download the virtual machine of the developing environment (ubuntu) from here :
    (go inside the VirtualBox folder and download the file : "MagicLantern.ZIP" clicking on it with the left mouse button.
    The Windows system will start to download the file.
    After the download is done, decompact it somewhere on your pc, but remember where, because we will need it in the next steps.
    The User/Root password of the ubuntu system is "123456" (without quotation marks). It will be useful in the future if the
    system will ask you for it.

[5] Launch "Virtual Box" that we previously downloaded (if warning windows will appear, push OK or IGNORE on all of them, don't
    worry about them) and then load inside Virtual Box the ubuntu developing environment that we already downloaded
    (menu "machine" then "add" and select the file "MagicLantern.vbox" that is located where you decompacted the virtual machine),
    then start this virtual machine (select it from the left column with a sigle left button mouse click, so it become with the
    blue background, and then you push the big green arrow on the upper part that point toward right named "start"). Then wait
    patiently the start of the ubuntu environment. During the loading, some windows will appear: answer OK or IGNORE to all.
    At the end of the loading process, DO NOT CLICK INSIDE the window but instead click on the upper menu bar like described
    in the next step.

[6] Activate the wired netword from the upper menu of Virtual Box (if the windows pc is connected by wire to the network)
    with this procedure:

   [ A ] Select from the Virtual Box upper menu bar of the ubuntu window the "Devices" item and then "Network cards...".
              be sure that the option "Enable network card" is checked, and inside the option "Connected to:" select
              "Card with Bridge". Under the option "Name:" will appear the name of your netword card installed on your pc.
              Under "Promiscuous mode:" select "permit all".
        [ B ] Press "OK" on the lower part and the configuration is done, and it will be retained also for the next future

[7] Now click inside the ubuntu window: the system will ask if you want to capture the mouse: answer affirmatively (press the
    "capture" button. Once inside the environment, enter into the folder named "magic-lantern" from the icon "Home" that is
    located in the upper left corner (double click with the left mouse button over it). In order to exit with the mouse from
    the environment, you must press the rightmost keyboard key CONTROL (CTRL), once. To return inside the environment, click
    with the left mouse button once, inside the the ubuntu window.

[8] Erase all the content of the folder where you are into (magic-lantern), all but the file "makefile.user" that is optimized
    for the ubuntu environment and must be left alone and not deleted

[9] Download inside this folder the new up-to-date sources, following this procedure :

   [ A ] Push the right mouse button inside an empty space inside the folder and select the command prompt from the
              manu that pops up

   [ B ] Issue this command: "hg clone -r unified".
              This command connects to the internet and downloads the latest Magic Lantern sources, and it generates,
              starting from the folder where you are into (magic-lantern) a new folder (magic-lantern) and it puts
              inside this new generated folder all the up-to-date sources.

        BEWARE : If the sub-folder named "magic-lantern" is yet present and it is full of the old sources and you want to
                 update them, FIRST YOU MUST DELETE this sub-folder along with all its content. Otherwise, the "clone"
                 command will give you an error. After deleting and then cloning, remember to copy inside the new created
                 sub-folder the file "makefile.user" that we saved from the deleting at previous point [8].

[10] Duplicate this new sub-folder with the up-to-date sources and name it "magic-lantern-mymodifications" (or whatever you want)
     with copy-paste. In this way, startig from the root, we have "magic-lantern" inside which we have the file "makefile.user"
     and two folders: "magic-lantern" and "magic-lanter-mymodifications"

[11] Copy the file "makefile.user" inside sub-folder "magic-lantern" and also inside sub-folder "magic-lantern-mymodifications".
     Now you will work inside the folder "magic-lantern-mymodifications" and we will leave alone "magic-lantern" subfolder as
     a reference from which to start for other modifications, generating everytime a new copy of this sub-folder for every
     modifications we would want to do.

[12] Go to the root folder "/home/magiclantern/magic-lantern",press the right mouse button inside an empty space and launch the
     command prompt. At this point, write the command "hgtk" or "thg" followed by ENTER key. A new window will open then.
     On the left column all the repositories will be listed that are inside your local environment (they are the folders that
     contain your sources). It will be listed "magic-lantern" and no more. In order to make listed also our new
     "magic-lantern-mymodifications" folder we created, you must evidence in blue (by clicking once with the left mouse button
     over it) the word "default" that is over the word "magic-lantern", that is the root, then right mouse button in an empty
     space in the left column under the word "magic-lantern": in the appearing menu select "Add repository" and then select
     "magic-lantern-mymodifications". Now your new repository is listed in the left column as well.
     Now right mouse button over "magic-lantern-mymodifications" and select "settings". In the new windows that appears, on the
     left select "commit" and on the right, at the "Username" parameter put your bitbucket username you selected (for example,
     in our case, "dlrpgmsvc" without quotation marks). then push OK in the lower right side. Now close the "Tortoise Hg"
     window (push the X in the upper right corner, like in Windows style). The username will be remembered by the system
     as long as the folder "magic-lantern-mymodifications" will not be deleted. So, this operation has to be executed only once
     at the beginning and then no more. If you do not set the "username", the "commit" operations will give you an error and
     will be aborted, so it's important not to jump this step. What is "commit" operation will be discussed later.

[13] Now we can enter into the "magic-lantern-mymodifications" sub-folder and we can start to study and modify the sources files
     that we want. Once your modifications are terminated, go to the root of the folder "magic-lantern-mymodifications", right
     mouse click inside an empty space and in the resulting menu select the command prompt and type the following command:
     "make clean" (without quotation marks) and push ENTER key on the keyboard. This clears out all previous temporary files.
     Then type "make" (alone, this time) and push ENTER. This command will compile and generate all the .BIN
     files of all the cameras models, and also it generate the unified .BIN (the one that is good for all the camera models
     but that is bigger in size). if you want to save compilation time, type "make <camera model>", for example "make 550d.109":
     in this way you will compile only the .BIN that is relative to your camera, so compiling time is shorter and the resulting
     .BIN file is smaller altogether. The .BIN files are the ones that are to be copied inside your camera, and they are the
     result of the compiling phase. They are located :
     - Into the folder "/platform/all" for the unified .BIN (the one that is valid for all camera models)
     - Into the folder "/platform/<camera model>" for the camera model-specific .BIN. For example, for the Canon 550D, the
       corresponding .BIN file is located into the folder "/platform/550d.109" or where "xxx" is another number and
       correspond to the Canon firmware version of that camera model.

[14] Now we must "take out" the .BIN from our developing environment. We will use an USB memory stick. Insert it inside a free
     USB port of your computer. Windows will immediately recognize it. Now we must go to the Virtual Box upper horizontal menu
     bar of the ubuntu window and select "Devices" and then "USB Devices" : it will appear a list where, on the bottom, there is
     the name of your memory stick you have inserted some moments ago. If there isn't, go to "Machine" then "Settings" then "USB"
     and then click with the left mouse button to check the option "Enable USB controller" and then "OK" in the lower part.
     Return to "Devices" -> "USB Devices", then click once with left mouse button over the usb key name. It will disappear from
     Windows but then ubuntu will see it. Now we can copy onto this usb memory key our .BIN file we just created.
     Then detach phisically the usb key from the port, then re-insert it so Windows can see it again.
     Now access the key from Windows, and copy the .BIN file to the Hard Disk and then on the camera memory card, or directly
     on the camera memory card (connected to our computer by a card reader or by the camera and usb cable).
     I don't advise to copy directly the .BIN file from the ubuntu environment to the camera card, or in the opposite way
     (from camera to ubuntu), because linux environment makes many hidden files and folders, which interfere with Windows
     filesystem and camera filesystem. If you use a usb memory key as intermediate, you will not face any problem.

[15] When the on-camera testing of your modifications are completed succesfully, you can proceed to share your modifications
     with all the Magic Lantern community. The process consists into submitting your modifications to the Magic Lantern
     developer board. If they will agree, they will fuse your modifications inside the official Magic Lantern last "nightly build".
     After some stress-testing time, the last nightly build will become the official stable release. But this usually require
     many months or years.
     All this translates in the following operations :
     - do a "commit" in local, that will produce a listing of all the source files modified
     - do a "push" from local to our online magic-lantern fork (inside our bitbucket account) of all the source files modified
     - do a "pull request" from our online magic-lantern fork to the official online Magic Lantern repository
[16] Go to the root folder of "magic-lantern-mymodifications", right click on an empty space and fire up the command prompt.
     Then type "hg commit". A new windows will open. it's a simple editor. It asks for a single line of text describing your
     modifications. The cursor is at his correct location: you have only to write a short description about your modifications,
     for example: "third menu item modified", and then push CONTROL+X on your keyboard. it will ask if you want to save the
     file that contains the sum of all your modifications to the source files: press Y on the keyboard. Now it asks to you where
     to save and the filename: leave the default ones and press ENTER on the keyboard. You will then be returned to the command
     prompt. Done.

[17] Staying on the root of the folder "magic-lantern-mymodifications", issue the command on command prompt:
     "hg push" and press ENTER. Obviously, "dlrpgmsvc" must me swapped with your
     bitbucket account username. This command will update your bitbucket magic lantern fork repository.
     It will ask to you your bitbucket username and password: issue them. While you will insert username and password, not even
     asterisk will appear: nothing is echoed to the screen. This is normal. Don't worry and keep typing. Beware upcase and
     lowercase: respect them always. Then press ENTER at the end of field inputting.
     The operations done will be displayed and the number of changesets (one, that is the one generated with the "commit"
     command issued on the previous point and that contains all the modifications you have done), the number of changes you have
     done, and the number of source files you have modified. At the end you will return to the command prompt.
     Now your online repository is up-to-date with your local modifications. Close the command prompt windows with the big X
     located in the upper right corner of the command prompt window itself.

[18] Before launching a pull request, we must be aware that meanwhile we was busy to do our modifications, the official magic
     lantern repository was active and modifying itself thanks to other developers like you that sent their request and some of
     them was also yet fused inside the official repository. So, if at the time of your pull request, your local fork repository
     is not up-to-date with the official one, your pull request will not be accepted and an error will be generated !
     So, to avoid this, proceed as follow: Go to internet by using Windows, and enter your bitbucket account. In our example:
     "". Push now the upper button "Compare". On the left make sure you have
     your repository ("dlrpgmsvc/magic-lantern" in our example) and just below this line make sure to select "unified". On the
     right make sure you have "hudson/magic-lantern" and just below this line "unified". Just below you will see the modifications
     YOU have done compared to the official repository. If no modifications were detected, it will say "There are no changes".
     If this happens, and you have done modifications, make sure you have issued the "push" command at point [17], and you have
     done "commit" at the point [16]. After you checked your modification, now you must see how the offical repository changed
     during your modifications time. You can do that by selecting "Swap source and destination" just under the "Hudson" right
     block. Wait a while and you will see all the modifications that was done while you was busy by programming your magic
     lantern modifications. Now you HAVE to update your local repository with these modifications, otherwise you pull request
     will be refused automatically by the BitBucket system. To do so, push the "Merge" button on top of your repository right
     block. A window will appear: you can press "Merge" at bottom. Wait and you will then see "There are no changes". Ok !
     Now you can proceed with your pull request at the next point [19]: do it without waiting, or other modifications could
     appear to the official repository and so invalidating your pull request.

[19] Now, the last step: submitting our modifications to the Magic Lantern community for review and, eventually, acceptance and
     fusing. Go to internet by using Windows, and enter your bitbucket account. In our example:
     "". Push now the upper button "Pull Request" (the button, NOT the menu item
     in the lower part that says "Pull requests"). Verify that the source (the left part) is "dlrgmsvc / Magic Lantern" and
     "unified" and that the destination (the right part) is "hudson/magic-lantern" and "unified".
     In the lower part, put a description title about your modifications inside "Title" and a more long and extended description
     into "Description". Then push the blue button in the lower part "Create pull request". Now our request is sent.
     They will analyze your modifications, and they may ask to you some questions about: you must answer to them and follow
     your modifications discussions until they are accepted or refused.

[20] In order to follow your modifications destiny, go to "" and push the blue button
     "Pull requests (n)" where (n) is a number that represents the number of pull requests that are in this moment under
     scrutiny. Verify that, among them, there is also your modification request. At the right of each request there is a
     baloon with a number: this is the number of comments received, and a circle with a checkmark: if present, the modifications
     was accepted. It is important to follow your modifications destiny to the end, otherwise, even if ok, they could be
     refused simply because you didn't answered to a question. Once accepted, your modifications will be included in the next
     automatic nightly build. The latest nightly build can be downloaded from here : ""
     by clicking on the last file on the bottom with .ZIP extension.

[NOTE 1] From time to time, a little explosion symbol may appear on the ubuntu machine: they are updates to the operative system.
         You can do them but they are very long to install and download and... no more magic lantern compatibility is assured...
         proceed at your full risk...

[NOTE 2] In order to shut down the virtual machine retaining all the modifications to the files you have done, press on the
         blue circle in the upper part where is a little white mouse drawing, and from the resulting menu select "LOG OUT"
         and then select "SHUT DOWN". Then wait until all is closed correctly.

[NOTE 3] To open "terminal" or the "command prompt", select the menu option "Open terminal here"

[NOTE 4] To modify a source file, right click it and select "Open with Leafpad"

[NOTE 5] The source files are inside the folder named "SRC"

[NOTE 7] After finishing a set of modifications and after the modification is merged (or refused) to the main ml repository,
         and verytime you start a new modifications set, you MUST delete and recreate che subfolder "magic-lantern" by starting
         at point [8] and subsequent points. This way you will work always on the most up-to-date source files.

[1] Crearsi un account su BitBucket (andare su "" e selezionare l'opzione "sign up". Al termine bookmarkare la propria pagina e segnarsene l'indirizzo. Se ad esempio abbiamo scelto lo username "dlrpgmsvc", avremo il nostro indirizzo bitbucket come segue: "")

[2] Una volta dentro al nostro account bitbucket, occorre "forkare" il progetto magic-lantern. Per fare questo basta andare nuovamente all'indirizzo "" (vedremo che ora siamo loggati in bitbucket in quanto in alto a destra troveremo il simbolo di un omino, che siamo noi) e poi premere il tasto in alto a destra "Fork". In questo modo ci verranno copiati tutti i sorgenti attuali di magic-lantern dentro al nostro account bitbucket: attendiamo la copia, ed al termine se torniamo al nostro account "" troveremo listato il fork "Magic Lantern": cliccando sul nome entreremo nel nostro fork (derivazione parallela) che potremo lavorarci come desideriamo. Ma per ora lasciamo tutto stare così com'è. Segnamoci che l'indirizzo completo del nostro fork è : ""

[3] Scaricare ed installare Virtual Box (andare su "" e selezionare "downloads" a sinistra) selezionando la versione adatta al nostro sistema operativo (in questo caso "windows")

[4] Scaricare la virtual machine dell'ambiente di sviluppo (ubuntu) da qui : (andare dentro alla cartella VirtualBox e scaricare il file : "MagicLantern.ZIP" cliccandoci sopra col tasto sinistro del mouse. Il sistema Windows attiverà lo scaricamento. Dopo averlo scaricato, scompattarlo da qualche parte e ricordarsi dove lo si è messo, in quanto ci servirà dopo. Tenere presente che la User/Root password del sistema è "123456" (senza virgolette). Ci potrà servire in futuro.

[5] Lanciare Virtual Box (se appaioni finestre di avvertimento, premere OK o IGNORA su tutte) e caricarci dentro l'ambiente virtuale Ubuntu di sviluppo (menu "macchina" e poi "aggiungi" e selezionare il file "MagicLantern.vbox" che si trova dove abbiamo scompattato la macchina virtuale), poi farlo partire (lo si seleziona dalla colonna di sinistra con un solo clic del pulsante sinistro così diventa a fondo blu, e poi si preme in alto la frecciona verde che punta verso destra che si chiama "Avvia") E si attende pazientemente che parta l'ambiente. Durante il caricamento appariranno delle finestre: dare OK o IGNORA su tutte. Al termine del caricamento NON cliccare all'interno della finestra ma sul suo menu superiore come descritto nel punto successivo a questo

[6] Attivare la rete via cavo dal menu superiore di Virtual Box (se il pc windows è collegato ad internet via cavo) con questa procedura:

   [ A ] Selezionare dal menu della finestra dell'ambiente virtuale Virtual Box "Dispositivi"  poi
            "Schede di rete...". Assicurarsi che l'opzione "Abilita scheda di rete" sia spuntata, e sull'opzione
            "Connessa a:" selezionare "Scheda con bridge". Sotto l'opzione "Nome:" apparirà il nome della vostra
            scheda di rete installata nel vostro computer. Sotto "Modalità promiscua:" selezionare "permetti tutto"

   [ B ] Premere "OK" in basso e la configurazione è stata completata, e sarà memorizzata anche per le successive
            sessioni a venire

[7] Ora cliccare dentro alla finestra dell'ambiente virtuale: il sistema chiederà se si vuole catturare il mouse: si risponderà affermativamente (premere il pulsante CATTURA). Una volta dentro l'ambiente, entrare nella cartella "magic-lantern" dalla icona "Home" in alto a sinistra (doppio clic col tasto di sinistra sopra di essa). Si ricorda che per uscire col mouse dall'ambiente basta premere il tasto CONTROL (CTRL) di destra, una volta. Per rientrarci, basta cliccare col tasto sinistro del mouse una volta dentro alla finestra dell'ambiente

[8] Cancellare tutto il contenuto della cartella dove ci si trova (magic-lantern), tranne il file "makefile.user" che è ottimizzato per l'ambiente e va lasciato

[9] Scaricare partendo da quella cartella i sorgenti nuovi ed aggiornati al momento, seguendo questa procedura:

   [ A ] premere col tasto di destra in uno spazio vuoto dentro alla cartella stessa e scegliere
       il prompt dei comandi dal menu che ne appare

   [ B ] digitare questo comando : "hg clone -r unified"
            Il comando si collega ad internet e scarica gli ultimi sorgenti, generando a partire dalla cartella
            in cui ci si trova (magic-lantern) una nuova cartella (magic-lantern) e scaricandoceli tutti dentro

   ATTENZIONE : Se esiste già la sottocartella "magic-lantern" con dentro i sorgenti, e si desidera ri-scaricarla
                     per aggiornarli, PRIMA VA CANCELLATA (contenuto e cartella compresa). Altrimenti il comando
                     "clone" darà inevitabilmente errore. Dopo aver cancellato e clonato, ricordarsi di ri-copiare
                     nella cartella appena creata e scaricata, il file MAKEFILE.USER che ci siamo salvati !

[10] Duplicare la nuova cartella con dentro i sorgenti e chiamarla "magic-lantern-miamodifica" con copia-incolla
    In questo modo, partendo dalla radice, abbiamo la cartella "magic-lantern" dentro la quale avremo il file
    "makefile.user" e due cartelle: "magic-lantern" e "magic-lantern-miamodifica"

[11] Copiare il file "makefile.user" sia dentro a "magic-lantern" che dentro a "magic-lantern-miamodifica"
     Ora lavoreremo sul repository "magic-lantern-miamodifica" e lasceremo "magic-lantern" come riferimento dal
     quale poi partire per altre modifiche, generando ogni volta una copia di questo repository

[12] Andare nella radice della cartella "/home/magiclantern/magic-lantern", premere il tasto destro in uno spazio libero e lanciare

il prompt dei comandi. A quel punto, digitare al prompt "hgtk" oppure "thg" seguito da invio. Si aprirà una finestra.
Nella colonna di sinistra vengono elencati i repositories (cartelle contenenti i sorgenti), nella fattispecie "magic-lantern" e

basta. Per far apparire "magic-lantern-miamodifica" prima evidenziare in blu, cliccando una volta col tasto sinistro del mouse, la

voce "default" che è sopra alla voce repository "magic-lantern", che è la radice, poi premere con il tasto mouse di destra nella

colonna di sinistra sotto al repository "magic-lantern" in uno spazio vuoto e dal menu che ne appare selezionare "Add repository" e

scegliere quindi "magic-lantern-mia-modifica" Ora apparirà anche il nostro repository nell'elenco nella colonna di sinistra.
Ora tasto destro su "magic-lantern-mamodifica" e selezionare "settings". Nella nuova finestra che appare, a sinistra selezionare

"commit" e sulla destra, alla voce "Username" metterci il vostro nome utente, ad esempio, in questo caso, "dlrpgmsvc" (senza

virgolette). Poi OK in basso a destra. Poi chiudere la finestra di "Tortoise Hg" (X in alto a destra, come in Windows). Lo username

verrà ricordato fintantochè la cartella non verrà cancellata, quindi questa operazione va fatta solo una volta all'inizio e poi

basta. Se non si setta lo username, l'operazione di "commit" darà errore e verrà abortita, quindi è importante non saltare questo


[13] Ora possiamo entrare nella cartella "magic-lantern-miamodifica" ed iniziare a modificare i sorgenti che ci
     interessano. Una volta terminate le modifiche, andare alla radice "magic-lantern-miamodifica", premere col
     tasto destro in uno spazio vuoto e dal menu che ne appare selezionare il prompt dei comandi e lì dentro
     digitare il comando "make clean" e dare invio. Questo comando pulisce eventuali files temporanei di compilazione precedenti.
     Poi digitare solo "make" e dare invio. Questo compila tutti i files .BIN di tutte le versioni di fotocamera
     compreso il .BIN generale (unified, unificato) che può essere copiato in qualsiasi fotocamera.
     Se si vuole risparmiare tempo, digitare "make <nomefotocamera>", ad esempio "make 550d.109" : in questo modo si
     compila solo il .BIN per la propria fotocamera, e si risparmia un sacco di tempo.
     I files .BIN sono quelli da copiare nella fotocamera, sono il risultato della compilazione, e si trovano:
     - Nella cartella "/platform/all" per il .BIN unified
     - Nella cartella "/platform/<nome camera>" per il .BIN specifico di ogni fotocamera, ad esempio, per la
       Canon 550D, si troverà nella cartella "/platform/550d.109" oppure dove "xxx" è un'altro numero

[14] Ora dobbiamo "tirar fuori" il .BIN. Per farlo ci serviremo di una chiavetta di memoria USB. Inseriamola.
     Windows la vedrà subito. Ora andiamo nel menu in alto della finestra Virtual Box dell'ambiente di sviluppo
     e selezioniamo "Dispositivi" e poi "Dispositivi USB" : apparirà un elenco in cui, in fondo, c'è il nome della
     chiavetta appena inserita. Se non c'è, andare in "Macchina" poi "Impostazioni" poi "USB" e spuntare
     "Abilita controller USB" e poi OK in basso. Tornando a "Dispositivi" -> "Dispositivi USB", cliccare una volta
     col tasto sinistro sopra al nome della chiavetta. Essa sparirà da Windows, che non la vedrà più, ma inizierà
     a vederla il nostro ambiente di sviluppo. A questo punto possiamo copiare su di essa il .BIN da noi creato.
     Fatto questo, stacchiamo la chiavetta fisicamente. Poi reinseriamola, affinchè Windows possa vederla nuovamente.
     A questo punto entriamoci dentro da Windows, e copiamo il .BIN su hard disk o direttamente sulla scheda di
     memoria della fotocamera collegata al nostro computer. Si sconsiglia vivamente di copiare direttamente dall'ambiente
     Linux alla scheda di memoria che poi inseriremo nella fotocamera, o viceversa di copiare da scheda di memoria
     all'ambiente Linux, in quanto Linux genera diverse cartelle e files nascosti che poi vanno ad interferire con il
     filesystem della fotocamera. Stesso discorso vale per copie fra Linux e Windows (da hard disk a hard disk) e viceversa,
     per lo stesso motivo di interferenze fra filesystems. Passando da chiavetta, invece, i files nascosti e di sistema
     Linux si creano ma non danno problemi di interferenza.
[15] Quando i tests sulla fotocamera hanno dato esito positivo, possiamo procedere alla condivisione delle nostre
     modifiche. Essa consiste nel proporre le nosre modifiche ai gestori del progetto Magic Lantern. Se essi le
     riterranno valide, le fonderanno nel progetto. Tutto questo si traduce nell'eseguire le seguenti operazioni:
     - Eseguire un "commit" in locale, il quale farà una lista di tutti i files modificati
     - Eseguire un "push" da locale al nostro fork magic-lantern del nostro account bitbucket dei files modificati,
       vale a dire la copia dei files sorgenti da noi modificati dal nostro computer (ambiente di sviluppo virtuale)
       alla fork magic-lantern (insieme di files sorgente) dentro al nostro account bitbucket online, su internet

[16] Andare nella radice della cartella "magic-lantern-miamodifica", premere il tasto destro in uno spazio libero e lanciare il

prompt dei comandi. A quel punto, digitare al prompt "hg commit". Si aprirà una finestra di editor molto semplice. Ciò che chiede

ora è solo di dare una riga descrittiva delle modifiche fatte. Il cursore è già al posto giusto, quindi basta scrivere ad esempio

"Modificata la terza voce di menu", ed al termine premere su tastiera CONTROL+X : verrà chiesto se salvare il file del riassunto

delle modifiche: premere il tasto da tastiera Y. Ora chiede la posizione dove salvare ed il nome del file: lasciare quello che

propone premendo INVIO sulla tastiera. Fatto questo si torna automaticamente al prompt dei comandi. Fatto.

[17] Restando sempre nella radice della cartella "magic-lantern-miamodifica", digitare al prompt il comando "hg push" a premere INVIO sulla tastiera. Ovviamente "dlrpgmsvc" andrà sostituito con il nome

con cui avrete creato il VOSTRO repository su BitBucket. Con questo comando andiamo a caricare le nostre modifiche dal nostro pc in

locale al repository online su BitBucket. Ovviamente ci verrà richiesto lo username e la password che avremo scelto al momento della

registrazione su BitBucket, altrimenti chiunque potrebbe caricare files nel nostro spazio e sporcarcelo, così, a piacimento. Alla

domanda "user: " digitare il vostro username, ed alla domanda "password: " digitare la vostra password. Notare che mentre digitate

la password non viene scritto nulla sul video, nemmeno pallini o asterischi: ciò è normale. Premete INVIO alla fine. verranno

scritte le operazioni eseguite. Al termine si torna automaticamente al prompt dei comandi. Abbiamo finito con l'aggiornamento dei

files nel nostro repository online. Ora i files nel nostro repository online sono "allineati" o "in sync" o "sincronizzati" (vale a

dire UGUALI) con quelli che abbiamo in locale sul nostro computer. Possiamo chiudere ora con la X in alto a destra la finestra di


[18] Prima di lanciare una pull request, dobbiamo essere coscienti che nel frattempo che noi stavamo facendo le nostre modifiche
     al codice di magic lantern, anche altri ne hanno fatte ed hanno aggiornato il repository principale.
     Questo è importante, in quanto, se al momento della nostra pull request il nostro repository forkato non è aggiornato con
     quello principale, il sistema bitbucket darà errore e la nostra pull request non sarà accettata in modo del tutto automatico.
     Per evitare questo, procediamo come segue: andiamo in internet tramite Windows, ed entramio nel nostro account bitbucket.
     Nel caso del nostro esempio, andiamo in "". Poi premiamo il pulsante in alto
     "Compare". Poi alla sinistra assicuriamoci di avere il nostro repository ("dlrpgmsvc/magic-lantern" nel nostro esempio) e
     subito sotto assicuratevi di selezionare (se non lo è già) "unified". Alla destra assicuratevi di avere "hudson/magic-lantern"
     e subito sotto "unified". Subito sotto vedrete le modifiche che VOI avete fatto, rispetto al repository originale. Se non
     avete fatto modifiche, ci sarà scritto "There are no changes".
     Dopo che avrete verificato che le vostre modifiche ci siano, dovrete verificare anche le modifiche che il repository ufficiale
     ha nel frattempo fatto rispetto al vostro fork online. Per fare questo, selezionate "Swap source and destination" appena
     sotto il blocco "Hudson" alla destra della pagina web. Attendete un poco e vedrete tutte le modifiche che sono state fatte al
     repository principale mentre voi stavate lavorando alle vostre modifiche. Ora voi DOVETE aggiornare il vostro repository
     alle ultime modifiche che gli altri hanno fatto, altrimenti la vostra richiesta di pull request sarà rifiutata. Per fare
     questo, semplicemente premete il pulsante "Merge" sopra al blocco di destra rappresentante il vostro repository. Apparirà una
     finestra: premete "Merge" in basso. Attendete e poi vedrete che la finestra sparirà e sotto ci sarà scritto "There are no
     changes". Ottimo ! Adesso potete procedere alla pull request al prossimo punto [19]: vi consiglio di farlo al più presto
     senza aspettare oltre, altrimenti se nel frattempo dovessero essere inglobate altre modifiche al repository principale, la
     richiesta di pull non adrebbe a buon fine.

[19] Ora abbiamo il nostro "fork" o "derivazione" di magic lantern aggiornata online, ma è sempre una "nostra" modifica.
Se vogliamo fare in modo che tutti possano beneficiare dei cambiamenti che abbiamo apportato, occorre generare una cosiddetta

"pull-request" o "richiesta di tirar dentro".
Cioè chiediamo ai gestori del progetto magic lantern di voler tirar dentro ai loro sorgenti le modifiche che noi abbiamo fatto.
In questo modo, se loro accetteranno, la prossima compilazione automatica notturna (nightly build) produrrà un file AUTOEXEC.BIN

generale (unified, vale a dire valido per tutti i modelli di macchina fotografica) che comprenderà anche le nostre modifiche, siano

esse generali (valide per tutti i modelli di macchina fotografica) che particolari (valide solo per il modello per le quali sono

state fatte, ad esempio solo per la canon 550D).
Andiamo su internet ed entriamo nel nostro repository BitBucket relativo a magic lantern (nel nostro esempio andremo all'indirizzo

"") ed una volta acceduto lì dentro premeremo il pulsante in alto "Pull Request" (il

pulsante, non la voce di menu in basso "Pull requests". Verifichiamo che la sorgente (la parte a sinistra) sia "dlrgmsvc / Magic

Lantern" e "unified" e che la destinazione (la parte a destra) sia "hudson/magic-lantern" e "unified". Sotto, mettere un titolo

descrittivo breve delle nostre modifiche in "Title" ed una descrizione più estesa ed esauriente in "Description". Premere poi il

pulsante BLU in basso "Create pull request".

[20] Ora dobbiamo seguire l'iter della nostra richiesta di pull fino alla sua accettazione o rifiuto: accediamo al repository

originale di magic lantern: "" e poi premere sulla scritta BLU (NON il pulsante in alto

"Pull Request") che recita "Pull requests (n)" dove (n) è un numero che indica le richieste di pull attualmente in fase di

valutazione. Verificheremo che ci sia anche la nostra. A destra di ogni richeista di pull vedremo un fumetto con un numero accanto,

il quale indica quali commenti sono stati ricevuti (richieste di delucidazione, opinioni ed altro), e un tondino con una spunta, che

se presente indica l'accettazione della richiesta. E' importante seguire la propria richiesta di pull sino alla sua accettazione o

rifiuto, altrimenti potrebbe restare lettera morta se non rispondiamo ad eventuali richieste di delucidazioni in merito. Una volta

accettata la nostra richiesta di pull, ritroveremo le nostre modifiche nella successiva compilazione automatica notturna, che

potremo (noi e tutti gli altri) scaricare da questo indirizzo: "" cliccando sull'ultimo file

in fondo, con estensione .ZIP.

[NOTA 1] Per chiudere la macchina virtuale salvando tutte le modifiche fatte fino a quel momento, premere sul cerchietto in alto a

sinistra blu con disegnato un topolino bianco e dal menu che ne esce selezionare la voce "LOG OUT" e dalla finestra che ne appare

selezionare il tastone "SHUT DOWN". Attendere che si chiuda tutto.

[NOTA 2] Per aprire il "terminale" o "prompt dei comandi", selezionare l'opzione di menu "Open terminal here"

[NOTA 3] Per modificare un file, cliccarci sopra col tasto destro del mouse e selezionare da menu "Open with Leafpad"

[NOTA 4] I sorgenti si trovano nella cartella "SRC"

[NOTA 5] Dopo aver portato a termine una modifica e dopo che è stata inglobata (o rifiutata) nel repository principale, e
         appena prima di iniziare una nuova tranche di modifiche, ricordatevi SEMPRE di cancellare la sotto-cartella "magic-lantern"
         e di ricrearla da zero, ripartendo dal punto [8] e proseguendo ai successivi. In tal modo lavorerete sempre sui sorgenti

Tutorials and Creative Uses / Unified Magic Lantern manual
« on: June 18, 2013, 02:17:37 PM »
This is to unify all the ML informations into a unique collaborative manual.

In the official ML repository there is the official manual. It's located here :

This is in different pieces: txt's, png's, bmp's, jpg's, drawings and so on. They are all organized into a precise structure, with chapters and so on, and this structures is as follows (but changes continuously as the manual develops) :

include(o, "FEATURES.txt");
include(o, "MANUAL.txt", 1);
include(o, "MENUSTART.txt");
include(o, "MN-AUDIO.txt");
include(o, "MN-EXPO.txt");
include(o, "MN-OVERLAY.txt");
include(o, "MN-MOVIE.txt");
include(o, "MN-SHOOT.txt");
include(o, "MN-FOCUS.txt");
include(o, "MN-DISPLAY.txt");
include(o, "MN-PREFS.txt");
include(o, "MN-DEBUG.txt");
include(o, "MENUEND.txt");
include_indent(o, "FAQ.txt");

This structure is controlled by scripts, so you can add chapters to it. All the scripts are in the doc directory ( is for pdf, mkdoc-cam for help bmp's, wikidoc for wiki output - but needs some tweaks). You need latex to compile them.

Each TXT file is plain text, you can edit it online, or offline and then commit it. The syntax is RST ( and can contain references to images (living in the same directory of the txt)  in this way :

.. figure:: 02.expo.png
    :align: center
    :width: 5cm

To add images, commit them like normal files to the official ML repository.
You can add files, sections, whatever.

The good of this system, is that, by modifying this manual, it's modified the help PDF in the nightly builds, it's modified the BMP ML help system inside the cameras and, if anyone fixes the wiki scripts, we can update the online version as well, all from a single source !

Feature Requests / RAW video skipped frames marking
« on: June 14, 2013, 09:08:33 PM »
For everyone interested, like me, to film RAW with skipping frames allowed (for higher resolution sake), and then interpolate the skipped frames in post, there is no clue to see where are the skipped frames. I dunno if the problem is "raw2dng.exe" extractor or the raw recording mechanism, but there is no trace about the skipped frames. It can be implemented as a jumped DNG numbering, or even a 0 (zero) bytes DNG, but something must be done in order to apply a post intervention. Many thanks !

Modules Development / Bolt trigger module test results (
« on: June 09, 2013, 12:56:21 AM »
Updated October 20th by Renato for a quick how to guide:

Two versions available, one with ring-buffering option ( +  and one without ring buffer (  The ring-buffering option allows to record more frames before and after the bolt while  the only record one or a few frames after the bolt.  Also there are some compatibility issues for the ring-buffering options as noted below.
Ring-buffering option can be used with cameras that have a CF card.   Tested cameras: 5D3 (works best), 7D with Tragic lantern for fps override.
Raw Video:  (This is an older so do not load current at the same time)
Bolt Trigger:
Copy these modules to the modules directory. 
Load the modules, camera in M mode, camera in video mode, enable Bolt Trigger RAW video and Bolt trigger Pre Buf modules located on Movie tab.  Set fps override to 15 with Low light option i.e  fps=14.985.  When you enable Bolt trigger the shutter speed should drop to 1/16, if this does not happen you will get more damaged frames.
For 5D3 I change the default  setup of Bolt trigger to:  Post-bolt frame count to 50, Abs trigger enabled ON, Rel: trigger enable OFF
For 7D leave the default settings.
Set your ISO to 100 and play these settings until you think you understand how this works.
Press Record button and the ring buffer will fill up but no recording (red led) will begin until the trigger detects a flash or light.  Test this with a flash or a bright light (on-off). When finished recording press the stop button (recording button) and then use the RAW  video playback found in Bolt Trigger RAW video to see the results.  When all works as expected download the raw file and have a look a the frames captured.
-------------------------------- is the second option. This works on cameras with SD and CF cards.  Tested cameras: 5D3, 5D2, 7D, 550D, 600D, maybe will work: 60D and 650D
Copy this module to your module directory.
Load the module, camera in M mode, camera in video mode, enable Bolt trigger  located on Movie tab. 
Set fps override to 15 with Low light option i.e  fps=14.985. 
When you enable Bolt trigger the shutter speed should drop to 1/16, if this does not happen you will get more damaged frames.
I have only tested default settings and work.  May have to adjust  Trigger value or take Auto exposure if you do not like how it exposes.  This feature changes the f-stop to adjust the scene exposure.
Set your ISO to 100 and play these settings until you think you understand how this works.
Press Record button and BOLTS CAPTURED  should stay at zero until a flash is detected and the captured frames will be recorded (red led).  Test this with a flash or a bright light (on-off).  When finished recording press the stop button (recording button) and then use the RAW  video playback to see the results.   When all works as expected download the raw file and have a look a the frames captured.

Jump to this post for more information:

Here is more info from mk11174 on how to use other features of!!!

My favorite feature I added was Autoexposure option, not sure if it works on any other camera though, but works perfect on the 550D, this allows me to walk away and control my video cameras while the autoexposure feature adjusts the trigger line right above the graph by controlling the aperture value and I made it slow so it does not re adjust when a flash happens, only when the sky changes gradually during a storm. Without this feature you have to watch the trigger line the whole time, if you want a bolt captured your goal is to keep that trigger line right above the graph to catch even the weakest bolts and since you have to do this, you will have to keep adjusting the aperture manually to keep the graph under the trigger line. The only thing you have to remember, is I set it to react slow, so when you first set your cam up at the sky you have to give the feature a chance to settle the graph under the trigger line, once it does, then you can start recording.

If the sky has a dark cloud layer and a medium grey layer it is best to use 1 scan line because the module will see the dark clouds and will adjust brighter which is bad cause then sky will get over exposed, that is why I added ability to see scan lines so you know what the detection lines are aimed at, if you have a nice even gradient sky, and it fills your view then you can use all scan lines with no issues.

The way I have it set up now allows me to turn it on and walk away and when I come back I have many bolts to enjoy without even touching the cam. So when used correctly which will take practice in my experience, it works really well.

The timelapse is a neat feature I added to it, but not always used, I only use it when I get really cool textured skies that I know will be worth a timelapse, it just saves a frame by itself while it captures bolts, it basically just sets off a false detection every so many seconds. Post gets harder because you have to manually separate the timelapse captures from the bolt captures so you don't get uneven motioned timelapses.


Original post by dlrpgmsvc

This thread was created for mk11174 in order to publish tests results of a module developed by gg30s. This module should start a raw video recording triggered by light and/or motion variations.

In this thread we will concentrate our efforts to port DNG silent pics feature (normal and burst mode) to the 550D

Current state-of-the-art : Simple & burst mode works, but from time to time there is a screwed-up frame (pink noise where you can guess some subjects contours) inside a BURST sequence, at least one DNG wrong inside the burst every 30 or so burst, as a mean value

Lets concentrate here all our efforts to port raw zebras & C. to 550d !

Current state-of-the-art : all the menus are enabled for raw visualizations of zebras & C., and now they all works correctly, thanks to "xaint" and his invaluable work !

Raw Video / 550D/T2i raw video recording port official thread
« on: May 22, 2013, 12:11:45 PM »
Here we will concentrate our efforts to port raw video recording to 550D, and continuously making it better and better !

Current 550D with RAW video builds (older ones are first, newer ones are the last towards the bottom of this post) :
To install: install the latest ML stable version, then substitute (overwrite) the files into the card with these


The main thing is the ability to save RAW settings after restart.

Includes Magic and Tragic as well and Mem fix.

Anyone having hard time deciding which record module they like best out of Magic Unified vs the Tragic version, this will help you.
You will have 2 new option within Magic Lantern.
When you decide which you like best, just delete the other module or just keep both, your choice.

Obsolete link removed - Please use the official nightly builds //Audionut


Anyone wanting to try out Alex's experimental variable buffer Raw Record, this build is all updated and has AUTO ETTR, File Manager and Pic View Module as well.

Obsolete link removed - Please use the official nightly builds //Audionut


Alex disabled debug code and added a bit more speed as it says on the changeset.

Obsolete link removed - Please use the official nightly builds //Audionut


Latest changes to everything. Includes modules, Raw_Rec, File_Man, Pic_View and ETTR, oh and a requested res of 1200 and aspect 2.42:1

Obsolete link removed - Please use the official nightly builds //Audionut


raw_rec module from pravdomil's source:

Raw_rec has some tasty features like black bars and auto global draw off while recording.

I've noticed a tiny but consistent frame count increase with this. For example, with my previous build i've got about 500–510 frames with 1200x496 at 24 fps, now i'm getting 550-570.

Also, there is a small present for those of you, who dare enough to shoot the tv works on 550d — nice 3X4 cropmark (useful for PAL world ).

Other stuff is from unified.

Notice: I have removed a large set of resolutions (useless for my works), and added 1200 and 1.42:1
This build also includes ETTR, file_man, pic_view.

Thread about this module :


Incredible milestone: all the previous raw stuff, plus the DUAL ISO feature for PHOTOS AND VIDEO !

Obsolete link removed - Please use the official nightly builds //Audionut

Current state-of-the-art :

Problem : Raw video recording works, finally ! Now we need to try to get more Buffer Memory like the other cams, even the 500D has 95Mb, while 550D only 75Mb as current development (68Mb was the memory available at the beginning of this development). With 500D, one gets higher res than on 550D, with no skip, thanks to the expansion of this memory.
You can see the status from the "0101" menu in ML : scroll down to "Free Memory", then press "Set" button on 550D and you will see the "shoot_malloc total" is 75mb : that needs to be al least 95mb (better if more, obviously). On 500D, this memory is native 95mb, without any intervention... we cannot understand why...

What to do :

[1] It seems we must enable sRAW option, but while on other cams it works, on 550D and EOSM it gives a "err70" error ( that bricks the camera (can be un-bricked, however). We have to solve this problem.

[2] Some hints of past tryouts can be found here :!msg/ml-devel/AyPANkaXbp0/PMwkzwuVy14J

[3] There are clues that, in order to make room for the raw_video_rec module, we used the shoot_malloc memory to put there the ML code, so shrinking it, so we cannot have more shoot_malloc memory anymore... look at this :

[4] Anyway, the source file to play with about this thing, is: src/exmem.c

[5] Without using sRAW option, %1 user managed to expand (even if by very little) the shoot_malloc memory by using this system : This is where he got more memory.

[6] Following point [5], we can play with these values :

[7] exmem.c - line around 147 -
hsuite = shoot_malloc_suite (max_size + backup_size - 8 * 1024 * 1024)
in this manner, the old version, we obtain 68Mb of shoot memory, good to serve as buffer for raw video (more memory, more resolution)
hsuite = shoot_malloc_suite (max_size + backup_size - 1024 * 1024)
in this manner, the new and current version, we obtain 75Mb of shoot memory
Our goal is to raise this shoot memory as high as possible, at least the 95Mb of 500D, but the maximum I managed to obtain is :
hsuite = shoot_malloc_suite (max_size + backup_size)
in this manner, we can have 76Mb of shoot memory
If you try even a :
hsuite = shoot_malloc_suite (max_size + backup_size + 1024 * 1024)
the result is 0 of shoot memory !
However, the interesting thing is that the autoexec.bin memory is not affected by the increase of the shoot memory.
I have hitted a wall here...  :'(

[8] - Modifying the "backup_size" (by upsizing or downsizing it), doesn't sort any effect at all.
     - Changing the probe size from 4 to 2 and then to 1 (just to dig out more memory chunks), doesn't sort any effect at all.
     - Forcing "size" to zero into the shoot_malloc allocation function, just to force it to allocate the maximum size, takes the camera to stack
        overflows and freezes that need to pull out the battery: no luck...

[9] By a1ex hint: use CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP, but it's defined as "dangerous" by a1ex himself (bricking camera risk ?)

Feature Requests / ML overlays sent out to USB tethering
« on: May 09, 2013, 12:32:14 PM »
It will be useful and cheaper to use a tethered tablet as a field monitor, but ML graphics are not sent to it: only live video is.
Do this can be done ?

Hardware and Accessories / DSLR Controller for Android problems
« on: May 09, 2013, 10:41:58 AM »
The last DSLR Controller version shows the live images from the camera (550D) but NOT the Magic Lantern (last version 2.3 stable) graphics and overlays.
What I'm doing wrong ? Do there are some options to enable/disable ?  ???

Feature Requests / Improved vectorscope
« on: February 09, 2013, 11:13:16 PM »
I propose some improvements to the vectorscope :

[1] Instead of a simple point, draw the four-squares little grid of strict confidence
[2] Draw also the four corners of large confidence aroud each point
[3] Think about adding the option to draw a bigger vectorscope, that occupy all the display space, in order to see it more precisely
[4] Think about adding the option to use a user-defined level of transparency for this tool
[5] Add the option for the marks to be valid for PAL or NTSC (user-defined switchable)

See here for an example :

Many thanks !

Feature Requests / [ALREADY DONE] Light intensifier night visor
« on: February 09, 2013, 10:46:17 PM »
Do it is possible, in movie mode or photo mode, to sum-up two or more (user-defined) frames with one or more criteria (for example only luma or luma+chroma and other summing algorithms) and display them on Live View display in real-time as they are summing one-by one or after every sum cycle, and then save every summed resulting frame as a photo or as a frame of a movie ? and/or saving a photo or movie frame of the current sum result at the pressure of a key ?

Feature Requests / [SCRIPTING] Multi-point focus hard stops
« on: February 09, 2013, 10:30:46 PM »
It will be useful, in some situations, to have some programmable focus hard stops. A user-defined numbers of focus points would be perfect, along with a user-defined sequence to follow (for example: 1-2-3-2-1 or 1-4-2-3-1-2 and so on)

Feature Requests / [ALREADY DONE] Motion detection windows
« on: February 09, 2013, 10:15:50 PM »
Do it is possible to set one or more user-defined windows (x size, y size and x,y position for each) inside the photo frame, so that only inside them the motion detection will take place ?

Feature Requests / [WONTFIX] RGB and YCbCr waveform monitor
« on: February 09, 2013, 07:50:32 PM »
Do it can be implemented, as an option, to have also a RGB and a YCbCr waveform monitor in addition to the Y-only waveform monitor ?

Do it is possible to have a function in the script language that can read the absolute and/or the relative light intensity that is coming through the camera lens, like the little vertical cursor on the exposure scale of the camera already does, so we can program an intervalometer exposure ramping without guessing the values by pre-setting them, but by directly read the light and then set the iso/aperture/time values in consequence ?

Pages: [1]