Messages

Yeah, I imagine Timer A is doubled for the same reason that the CMOS gain is doubled: each row in a row pair will use one of the halves.  However, I can't think of a clear benefit from mismatching the two halves of Timer A, unlike with CMOS gain and dual ISO.

"hg: command not found" means that either Mercurial is not installed, or it's not in the path.  Mercurial is invoked when building a module because information about the last change to the module is added to the module's help screen.

[cr2hdr]

Yes, I understood that all.  Don't use BarracudaGUI.  Try calling cr2hdr directly.

Hmm, my rear wheel works fine in menus, even when in LV.  Can you provide more specifics?  Which build are you running?  Are both Canon and ML menus affected?

The first decision I need to make is... do I run virtual linux or cygwin? Does anyone have an opinion on that?

On Windows, I use a Linux VM in VirtualBox, and it works fine.  I haven't tried any other approach.

I had this at first on my 5DIII - until I updated the .sym file in the modules directory.

When you rebuild, it should create a 7D_203.sym file in the platform directory, copy this to the modules directory on the card and see if it helps.

I recommend running "make zip" from the appropriate platform directory, which will create a nightly-build-like zip file which has the correct directory structure with files in the right places.  You don't want to be in a situation where you can inadvertently mix files from different builds.

(Alternatively, do "make install", as @dmilligan suggests.)

[cr2hdr]

Part of the confusion is due to your original question.  You asked how to get CR2 files, and the short answer is that you don't.  What you can do, with appropriate processing tools, is to convert dual-ISO files to normal-looking DNG files.

It sounds like BarracudaGUI may be designed only for handling dual-ISO photos (which would saved by the camera as a CR2 file), rather than also frames from dual-ISO movies (which would be converted by MLV tools to DNG files).  Try cr2hdr.

How are those values used, I can't make any sense out of the number which is used in timer A
6d
                  Photomode           Video(1080)
Timer A       5970597               2210221
Timer B          e8d                          63f
...
But I can't make anything out of the numbers in timer A 

Timer A, which are 0x597 and 0x221 in your two examples because it is doubled, is the number of clock ticks to wait before each successive row is read out.  Thus, it should not be set shorter than the time it takes to read out a single row of the image (i.e., the width), but it can be set longer depending on the needs of a rolling shutter or an exact frame rate.

This mode is called junkie mode, and it's actually mentioned on the Help tab.

Yes, the 50D can do raw video.  All of the development work in that 180-page thread is included in Magic Lantern.

Feel free to ask 50D-specific questions in this thread.

One recent new discovery is the capability for full-resolution silent pictures.  You may be interested in a post by a1ex in the nightly build thread that lists some of the works in progress.

I have a question though; I know that the maximum width of the 50Ds RAW recording had to be decreased from 1584 to 1568 for ML codebase portability concerns, but will this restriction ever be lifted?

Probably not, no.  It'll be hard to ever show conclusively that such resolution non-multiples that cause problems on some cameras do not cause any subtle problems on the 50D, and thus it's hard to justify the minor increase in area.

That won't accomplish what you're thinking because the ADTG/DFE amplification comes after the CMOS amplification.  The brightness at which you saturate in the first stage will still be saturated in the second stage, so you really can't reduce the gain of the second stage all that far before it becomes pointless (the effective ISO stops decreasing).

[enum]

just one change: use it as enum and define metadata (0), video (1) and audio (2) enum values.
so it is extensible

Are you recommending an actual enum?  I'm not sure how that would work since I can't include an enum as part of the structure due to size, and it'd be clunky as a separate global.  I'll use preprocessor constants to remove the magic numbers, and then I'll issue the pull request.

Edit: pull request

EDIT: these four registers, seems to be some amplifiers and are per color channel, the first two are Red and Blue(or vice versa), the last two seems to be the two Green channels
EDIT 2 :Looking at the pictures now in lightroom, every 4th pixel is missing, so it's not used per color channel.

You might be interested in this description that I wrote in another thread.  Because of how the colors are distributed between the vertical lines, you are somewhat correct in that the red pixels are affected by only 2 of the 4 registers (and the blue pixels are affected only by the other 2), but all 4 registers will affect green pixels.

For the purposes of the investigation in this thread, we've been setting all 4 registers to the same value, but Canon has some fine-tuning differences (as you can see in your table), which were presumably/hopefully determined from their calibration of the electronics.

1792 should also be an option (50D)

Thanks for the links. Yes it would appear that what I am seeing is the 5D2 and low FPS bug. Should I raise a bug report?

You can chime in on the existing Bitbucket issue.

The issue reported by @1anl is an old one that was thought to be specific to the 5D2 and low FPS: http://www.magiclantern.fm/forum/index.php?topic=10689.0.  In that thread, I link to a bunch of relevant posts.  I don't think there's been any further progress on fixing that bug, but I'm not positive.  Here's the Bitbucket issue.

The symptom does sound quite similar to the OP's issue, but that's on a 5D3 at 24 FPS, so a completely different situation...

Here's an ML benchmark of what is presumably the same card – http://www.magiclantern.fm/forum/index.php?topic=12630.msg121914#msg121914 – showing the >~100 MB/s read speed and the ~60 MB/s write speed.

But the important question is: did you spend $315 for something that's going for $100 on Amazon?

[mlv_play]

@g3gg0
I've been trying to improve the performance of exact playback of MLV files (on my 50D), which struggles on >~1 GB files due to out-of-sequence blocks.  Canon FIO has poor performance with reading backwards, with increasing delays the further into a file (presumably it's loaded from the beginning).  Consequently, increasingly more frames need to be skipped the further past >~1 GB, and eventually, around 3 GB, it's no longer possible to read block headers fast enough to catch up with the FPS timer and playback stalls.

The issue is that mlv_play reads the header of every block during playback, and all of those FIO_ReadFile calls start becoming too expensive.  I've tried some sub-optimal solutions – skipping over blocks, but that skips metadata blocks too, or flushing the timer queue when too far behind, but then playback isn't exact anymore – but I think the "right" solution would be to add information to the XREF block in the generated IDX file so that it's possible to know whether a block can be skipped (VIDF) in playback without needing to read the block header (again).

Here's my implementation: https://bitbucket.org/ayshih/magic-lantern-50d/branch/mlv_play_fix3
https://bitbucket.org/hudson/magic-lantern/branch/mlv_play

I split off a byte from the unused variable empty in the structure mlv_xref_t, and this new frameType variable is set to 1 if the block is VIDF and thus skippable.  This changes the format specification, but I'm hoping the ramifications will be minor because the structure variable was unused and the size of the structure hasn't changed.  (Existing on-camera IDX files would need to be re-generated.)  Playback starts to drag deep into a 4 GB file, but now playback completes and maintains >2 FPS.

What do you think?  This frameType variable could be extended to discriminate all of the different block types, if useful.

This is according to a video where I recorded a high-precision stopwatch from my LCD screen (60Hz). Can anyone suggest a more accurate procedure?

If I understand you right, you're running a stopwatch program on a computer with a typical 60 Hz display.  That means, from frame to frame on the display itself, you'd expect to see a ~17 ms time difference between frames.  Even if you were to then record the display at 1000 fps, you would still only see a new frame every 1/60 of a second, and that new frame would have a displayed time ~17 ms after the preceding frame.

So, it's not clear anything is wrong from your data.  The ~33-ms gaps are when the recording misses one frame of the display, and the ~50-ms gaps are when the recording misses two frames (23.976 fps is ~42 ms per frame, while two 60-Hz frames take only ~33 ms).  The other timing inaccuracies are likely due to inaccuracies in the display of the stopwatch.  Unless this stopwatch program was designed to have high accuracy (rather than just high precision), OS-level graphical calls probably have variability and delays that are contributing.

It's neat to try to test the accuracy of the FPS timer, but you need a better setup.  If there aren't (cheap) real-world high-precision stopwatches with displays that have high refresh rates, you could instead build one (e.g., a microcontroller plus LED digits).  Alternatively, you could try a kookier setup that makes use of a spinning laser or the trace of an analog oscilloscope.

[display_is_on()]

Thanks for the detailed description of the problem!  It may not make a difference, but can you try switching out of LV yourself before starting the DotTune scan?

It sounds like this may be a 1.2.3-specific problem, and the relevant check that is failing is:

Code Select Expand


...
if (!display_is_on() || !display_idle())
...

That is, ML keeps toggling the info screen because it either thinks the display isn't actually turning on (display_is_on() is returning false) or that the display, while on, isn't idle (display_idle() is false).  If there isn't a bug with one of those functions, then another possibility is that the module is not waiting long enough before checking to see if the display is idle.  Here's a build of dot_tune.mo where I have increased the wait time and added some information to the error message you are seeing.  Can you give it a try?

Can any other 5D3 users chime in on whether DotTune works for them, on either 1.1.3 or 1.2.3?

Edit: resolved

It sounds like you may be having the same 32-bit/64-bit issue discussed earlier in this thread.  See the solution a few posts above yours: http://www.magiclantern.fm/forum/index.php?topic=991.msg112954#msg112954

To be clear, multiverquantique's workaround just resolves a symptom, but not the underlying issue: you only encounter a FONTS.DAT issue when you have not correctly installed the nightly build.  As stated by Walter, you have to delete everything associated with the previous ML build.  Current nightly builds do not have and do not need the FONTS.DAT file.

Now you're gonna kill me: I've deleted a bunch of code, is it still working?

Yup, still works on 50D.

Ah, the 6D is one of the cameras that can set two different AFMA values at the ends of a zoom lens, so it's almost certainly related to that.  On a related note, if you haven't ever set two AFMA values in the Canon menu for this lens, the registry may not be properly initialized.  Hopefully the "all lenses" AFMA values are correct, and then you can simply switch back to "this lens" and manually set the values using the Canon menu.

Note that this module itself is currently broken towards being able to handle a zoom lens and two AFMA values.