Messages

ML 2.3 from the website is the stable release, but it's a year and a half old and is missing features like raw recording.  If such features are important to you, you can install a nightly build.  While the nightly builds are not "stable" in the formal sense, they are decently well tested, and you are unlikely to encounter any major issues.  Of course, please report any issues that you do have, either on the 50D thread or on Bitbucket.

[raw_rec]

Assuming that you've installed a recent build, you need to enable either the raw_rec module or the mlv_rec module.  Then there will be a "RAW video" item on the Movie tab of the ML menu for turning on and configuring raw recording.  The MLV format has added metadata compared to the RAW format.

So, I just updated to the latest nightly build. The thing crashed when simply trying to turn on liveview. Here's the log, don't know if it's just something that happened when updating or something, but here we go anyway. http://pastebin.com/xue2GWDH

I've just tested the last few nightly builds, as well as Andy's latest build, and I don't encounter any issues with turning on LV.  What is the Mercurial changeset on the build you are using?  If you do a clean install (i.e., don't preserve any settings), do you still have problems with LV?  Can you try the latest nightly build?

My understanding is that a half-shutter press, the AF-ON button, and the * button all generate the same event that ML uses to trigger silent pictures, so it's not apparent how to distinguish between these three buttons.

These are the closest relevant threads I could find on the forum:
http://www.magiclantern.fm/forum/index.php?topic=9038.0
http://www.magiclantern.fm/forum/index.php?topic=1923.0

[skip_top]

Here's the optical-black screenshot for the 50D:


I've double-checked the skip offsets, and skip_top and skip_left are as small as they can be before a gap appears in the raw zebras.

Anyone can help me counting the pixels of each zone and write down their sizes?

For 5D2:

Code Select Expand

blue: 0;4 5792;26
green: 0;31 158;33
yellow: 158;31 5792;32
red: 0;34 158;37
cyan: 0;37 78;3804
orange: 78;37 158;3804

For 5D3:

Code Select Expand

blue: 0;5 5918;31
green: 0;32 122;41
yellow: 122;32 5918;41
red: 0;42 122;47
cyan: 0;47 122;56
orange: 0;56 122;3950

Edit: Add 5D3, but for other cameras I don't have RAW files.
Note: Coordinates origin is top-left(0;0).

Don't forget that there can be indexing differences between the CR2 files and the buffer that ML uses (that can be dumped with RAW_DEBUG_DUMP).  For example, ML intentionally skips the buffer ahead one line for both the 5D2 and the 50D to put the red pixel on even-parity lines, but there could be other discrepancies too.

[DIGITAL]

left optical black pixels:
as they come right before the pixels in the current line, they are used to update current line black level for this line.
...
in OB digital data we get not just the charge of the sensels, but also the correction value that updates.
as closed loop filters usually oscillate and converge to the target value slowly, the first few DIGITAL OB lines would be trash and only reflect the filter's learning phase.
same for the first few OB pixels in every line.

Here are some plots that I posted much earlier in this thread here, with accompanying explanation here, that show the effectiveness of the per-line black-level clamp for a normal exposure and a massive overexposure in the 50D.  Each curve on the plot is the histogram of a pair of columns in the left optical-black region, with the top curve adjacent to the actual image region.



You can see both oscillation and convergence, even for the normally exposed image.

You can see ted ramasola describe the bug here and here, and it's also brought up in later posts (with responses by a1ex here and here).  Perhaps ted ramasola inadvertently did something different to be able to not experience the bug when testing the Feb 24th build.

Are you using a nightly build, and if so, what's the date?  You're encountering a 5D2-specific bug that ted ramasola has been very interested in seeing fixed, and his latest test suggests that the bug is fixed as of the Feb 24 build.

For what it's worth, this bug has already been reported and is apparently specific to the 5D2:

http://www.magiclantern.fm/forum/index.php?topic=5533.msg98784#msg98784 (in the middle of the post)
http://www.magiclantern.fm/forum/index.php?topic=5533.msg101743#msg101743 (item 7, and see a1ex's response following)

Magic lantern's Default Video Resolution 1920 x 1080 30p i tried to over ride FPS but it gives only two options FPS over ride OFF or 2.504 Please help me set fps to 24 or 23.97

You can change the FPS value in the submenu for FPS override; open the submenu by pressing "FUNC".

[Makefile.user]

It looks like you may have accidentally skipped steps 16 and 17:

16. Double click on Makefile.user file

17. After GCC_VERSION= add "-" sign should now read:
      GCC_VERSION=-4.7.3

The missing hyphen is why the make command can't find the binary, which is arm-none-eabi-gcc-4.7.3.

In fact, you actually should be able to remove that line entirely from Makefile.user.  If you've properly updated the local repository (using hg pull and hg update), Makefile.user.default should (now) have that hyphen in its respective GCC_VERSION line.

[mlv_rec]

Turn on the camera. Turn on RAW recording with GD Allow. Several recordings go fine.

Then just switch recording from RAW to Standard. Recordings go fine as well, nothing changes.

Then I switch back to RAW recording (1584x892), making sure GD is set to Allow.

Now the GD during recording of RAW video starts to disappear. At first all texts and GD is gone, then the stripes disappear, so that while recording you do not have HD aspect ratio. It's a clean screen basically, with a camera sign and timer.

Thanks for the clarifications and your later screenshot!  I now understand and can reproduce the issue, so I (and others) can look into fixing it.  I've been testing primarily with GD set to "OFF" in mlv_rec, so I hadn't noticed this issue with GD set to "Allow".  This is precisely why it's so useful to get testing feedback from many people.  My guess is that this is not a 50D-specific issue, but a broader issue with mlv_rec.

Another glitch: when zoomed x5 the screen flickers, when x10 it is ok, Have to turn zoom x5 off to avoid that. TL has slightly different glitch -- it is not flickering, it just goes b/w with an ugly low resolution, only x5 zoom.

You didn't say so explicitly, but can you confirm that flickering glitch is no longer present in the latest nightly build?  What you were seeing in the TL build (blocky, grayscale preview in crop mode) is what you should now be seeing in the ML build, and is the default behavior (preview is set to "Auto" in mlv_rec).  You can set preview to "Canon" in mlv_rec to get the normal Canon preview, but the framing is off in crop mode.  The Canon x5 preview shows only a portion of the image that will actually be saved.

[mlv_rec]

On the Feb 8 nightly on the 5D3, I have GD on, but I set it to turn off during recording. Well, GD will be on, then I hit record, but once recording stops GD doesn't come back on until I turn the camera off and then back on.

Bug or am I doing something wrong?

Can you (and others) try the latest nightly build (Feb 14), which includes this commit?  When mlv_rec turns GD off during recording, it should now come back after the recording stops.

[mlv_rec]

Thanks for your testing report!  However, I'm not sure I understand your steps.

Regarding the Global Draw. It tends to disappear after 3-5 recordings. I was able to reproduce the problem like this:

- turn on the camera \ LiveView
- first recording

This first recording is using mlv_rec (as opposed to raw_rec)?  Is global draw set to "OFF" within mlv_rec?  What is the global draw behavior like?

- turn off the RAW recording in the movie menu
- recording "Standard" to .mov. Global Draw is ok
- turn back on RAW recording in the movie menu. now when you push Rec button you have 2 black stripes on the top and the bottom, BUT ALL INFO IS GONE

This just sounds like the normal behavior with mlv_rec with global draw set to "OFF" (the default setting).  That is, during the recording, global draw is disabled to improve the speed.  After you stop the recording, does global draw get restored?

- on the next RAW recording, even black stripes are gone, visible is the whole screen with aspect ratio 4:3 or whatever

I'm not sure why there'd be a difference in black stripes, but again, this sounds like the default behavior of disabling global draw during recording.

Did you start with a completely clean install of the nightly (e.g., no old settings files)?  Do you see different behavior when using TL?

Because of the new memory backend, the nightlies were just rebuilt.  As long as you download the nightly that says "Built on: 2014-02-13 15:16:33 -0500" (or the equivalent time in a different time zone), you will have all of the recent changes.

Definitely!  In particular, you should test out tonight's nightly builds because I added two important commits:

• TL backport: display filters (ML grayscale preview, anamorphic, etc.) work now
• mlv_rec: global draw is restored after finishing a recording

But test everything else too!

I finally was able to borrow that faster lens.  For the 50D, here's the register dump for the aperture sweep, from f/8 to f/1.4 and back:

https://www.dropbox.com/s/ihry3dq9drv2a05/50D-aperture.log

I can immediately see that the digital gain (0xC0F08030) is 0x1000 down to f/2.8, and then starts increasing, up to 0x147A at f/1.4.

Unless I'm mistaken, the 50D (along with other cameras of the same generation) cannot make use of Dual ISO in movie mode because it does not use ISO registers in the same way as in photo mode.  The error message is misleading because Dual ISO can be disabled because the ISO register is not defined, not just because RAW recording is not enabled.

For the 50D, here's the register dump for the ISO sweep, from 100 to 12800 and back down:

https://www.dropbox.com/s/7ftxovt2oqu2njn/50D-ISO.log

I'm not going to do the aperture sweep on my lenses because they're not particularly fast, but I can borrow a lens next week if someone else hasn't provided that register dump before then.

What are the new features of this build compared to the jan 14th?

The two items I'd highlight are:

• The indexing of the 50D's raw buffer was incorrect, which was throwing off RAW histograms and zebras and slightly throwing off black-level estimation.
• The file manager has much better performance for directories with many files.

This is not an exhaustive list; there have been other bug fixes and tweaks.

Edit: oh, there was also the fix to the Calibration Illuminant (see http://www.magiclantern.fm/forum/index.php?topic=10119.0)

Is it really stuck at 1600 ISO, or is it actually doing 400/3200?

It's really doing ISO 400/1600.  You haven't specified what camera model you're using, but the available recovery ISOs are restricted depending on the particular model.  I know that my 50D tops out at ISO 1600.  The technical reason for this restriction is that Dual ISO is implemented by changing the CMOS-gain registers, while the ISOs greater than 1600 on the 50D have the same CMOS gain as ISO 1600 (a different amplifier gets you to the higher ISOs).

[magiclantern-v2.3.NEXT.2014Jan29.550D109.zip]

Build  2014-01-26 17:23:15 -0800 on 550D crashes when trying to "Q" in to Vignetting options, battery has to be removed. However everything is fine if I just switch Vignetting on. I don't know what build I was on last, but it worked maybe some time in Nov or Dec.

Thanks.

This bug has been fixed as of tonight's nightly build (e.g., magiclantern-v2.3.NEXT.2014Jan29.550D109.zip).  You can test and confirm this on your end.

[raw_diag]

Once you've decreased the gain enough that your white level is dropping, you've already gone too far.  Note that even if the white level is unchanged as measured by raw_diag, it's still possible for the gain to be too low, because you may no longer have solid white highlights due to non-uniformity of saturation.  See these images to see what can happen in the highlights (there, from changing digital offsets rather than gain, but it's functionally equivalent).

[mini_iso]

Lowering the offset does increase DR.  However, it does not reduce noise (stdev) and the DR increase comes from the simple fact that DR = log2(saturation-offset/stdev).
...
With ADTG gain reduction, we do decrease the noise.  So IMHO, it's much more preferable (in increasing DR) then saturate offset.

If you take a look at my 50D numbers, you can see the following cases starting at Canon's ISO 100:

• changing just DFE gains: 1023..13432, stdev = 4.79 => 11.34 DR
• changing primarily offsets: 1024..15759, stdev = 5.76 => 11.32 DR

(Note that the 0.02 DR difference is below the uncertainty of the DR calculation and the reproducibility of the mini_iso calibration.)  It's true that changing the offsets doesn't decrease the noise as measured in ADUs, while the width in ADUs of the noise does decrease when reducing gain.  However, in both cases, the SNR at typical brightness levels hasn't actually changed.  Instead, what you get in both cases is increased range in the highlights.  Getting better SNR in the shadows requires you to ETTR to make use of this increased range.

B/W offset (which acts in the same manner) is more useful IMHO, because of bit depth.  B/W offset doesn't increase or decrease the DR of the signal, simply that it pushes the signal into a higher recorded bitdepth.  Here, the gain is bit precision for the entire signal.

This is not correct: B/W offset has no effect on precision.  If you shift the range of digitization from 1024..15000 to 2048..16024 by increasing the offset by 1024, you are using larger numbers, but the width of each bin doesn't change.