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.

Show posts Menu

Topics - stevefal

I'd like to record RAW with an external monitor that has it's own waveform, histogram, zebras etc. But I don't understand the relationship between pixel values send via HDMI and the values recorded. I'm under the impression that normally, what I get via HDMI throws 1 bit off the top and the remainder off the bottom. If this is correct, my external monitor would show clipping 1 bit before it's actually happening. Can you correct me on this?

Finally, ML has LV brightness, contrast and saturation settings for the internal monitor, but they do not apply to the external output. Is that a camera limitation, or is it possible to send via HDMI, say the RAW 8 MSBs for highlight preservation, or even a low-contrast version?
Feature Requests / MLV/REC simpler status indicator
July 30, 2014, 07:14:27 PM

- remove "None" MLV record status mode
- remove "Icon" MLV status mode and display clip time and time remaining in LVINFO (design TBD)
- put all internal info to "Debug" mode, and make it an independent toggle that splatters LV as today


Currently MLVREC "Icon" mode displays an icon and three lines of text to indicate status. I think two of the lines are not useful in practice - bitrate and idle time. Also, the icon and text are drawn over the video image, encroaching on composition space. LVINFO is designed for status information.


The "None" status mode is worthless. Correct my if I'm wrong, but I can't imagine anyone wanting their camera recording with no indication of the fact.

This suggestion is to simplify display by removing unnecessary information in the normal case, and moving it out of the way. It also add the important "time remaining" feature, which is hopefully possible.

Finally it simplifies the menu by removing any options besides "Debug" which is for developers/troubleshooting.
Feature Requests / RAW/MLV record time remaining
July 30, 2014, 06:41:00 PM
Running out of storage during an important take is a real bummer. It would be great if, in addition to current clip length, the estimated time remaining on the current card was displayed. This could be based on a short moving average record bit rate in RAW/MLV, and storage space left on the card since the clip started, worst case.
Feature Requests / Useful space remaining indicator
July 30, 2014, 06:32:36 PM
Currently the space shown remaining on my CF card does not update unless I power cycle my 5D3. It would be great if this was updated more frequently. Recording RAW eats space fast, and power cycling is not convenient in that situation.
General Development / Building dual_iso
March 21, 2014, 03:20:32 AM
Any idea the issue here?

Quotefalconmacbook::steve [modules]$ make

Building module raw_rec...

Building module mlv_rec...

Building module mlv_play...

Building module mlv_snd...

Building module file_man...

Building module dual_iso...
[ README   ]   module_strings.h
[ CC       ]   dual_iso.o
[ MODULE   ]
[ STRIP    ]
[ EXPORTS  ]   dual_iso.sym
00001368 dual_iso_calc_dr_improvement
000013c0 dual_iso_is_enabled
000013e0 dual_iso_get_dr_improvement
00001560 dual_iso_get_recovery_iso
00001580 dual_iso_set_recovery_iso
[ DEPENDS  ]   dual_iso.dep
Will load on:
Not checked (compile ML for these cameras first):
    1100D, 500D, 50D, 550D, 5D2, 600D, 60D, 650D, 6D, 700D, 7D, EOSM
[ gcc      ]   cr2hdr
clang: error: unknown argument: '-mno-ms-bitfields' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
make[3]: *** [cr2hdr] Error 1

WARNING: module dual_iso failed to build, deleting

[ RM ]  dual_iso.o dual_iso.sym dual_iso.dep module_strings.h *.o *.d *.dep *.sym hgstamp
[ RM ]  cr2hdr cr2hdr.exe
Any idea?

Quotefalconmacbook::steve [magic-lantern]$ make
make -C  /Users/steve/magic-lantern/platform/5D3.113
[ VERSION  ]   ../../platform/5D3.113/version.bin
[ VERSION  ]   ../../platform/5D3.113/version.c
[ CC       ]   version.o
make -C ../../tcc
make[2]: Nothing to be done for `all'.
[ LD       ]   magiclantern
arm-none-eabi-gcc-4.7.3: error: unrecognized command line option ''
make[1]: *** [magiclantern] Error 1
make: *** [5D3] Error 2
Raw Video / Regular zebras and RAW video
March 07, 2014, 08:45:13 PM
Since RAW zebras don't work (for me), does anyone know a rule of thumb for using the regular zebras while recording under rawrec? For example, if I knew that raw video clipped 1 stop over where normal zebras kicked in, I could simply open 1 more stop from there.
When shooting a scene with a hairlight just outside my 1920x872 frame, ETTR was showing OVER unless I tilted down so the light was not hitting the sensor at all. Likewise the histogram showed a bunch of highlights that were not in the recorded image.

It seems like the overlay math is considering data that's not part of the recorded image. This an issue as the hints are potentially worthless depending on the shot.

Am I missing something, or is this fixable?
Hardware and Accessories / Lexar Rev. A versus Rev. B
January 16, 2014, 03:10:13 AM
Searching the forum I only found one mention of a Lexar CF revision number. I have four 64GB cards, and was benchmarking them with Blackmagic Disk Speed Test. I noticed that one seemed slower. Checking the labels, sure enough that one shows Rev A, Copyright 2011, and the other three are Rev B, Copyright 2012.

Unfortunately, the benchmarking tool yields varying results. Just as we've noticed with ML, disk speeds can increase after the card "warms up". But I have also noticed with the BMDST that they can also slow down during a long run.

In either case, it seems like the Rev B cards average about 10-15MB/s faster than the Rev A. Especially noticeable is how the Rev B cards achieve their top speed pretty quickly, whereas the Rev A seems to take some time. I only have one Rev A to test.

Anyone else have two (or more) revisions? Able to measure a difference?

[EDIT] I've benchmarked again and can't repro the difference reliably. In one case a Rev B card came up fast and then dropped to 75MB/s for a while. I suppose I should try the ML tool or some other long-run benchmark.
General Development / Player UI proposal
October 29, 2013, 08:05:15 PM
This implies an architectural leap with respect to LV_info, or it could be a one-off:

(from discussion at
I have been running a set of workflow benchmarks in order to determine which best preserve the fidelity of original ML raw footage. My personal goal is to edit in high quality without proxies. In order to accomplish this, the workflow needs to:

-  generate clean, high DR clips that are playable in real-time
-  recover, correct, grade footage in high fidelity, in-place while editing (with GPU)

I use Adobe Premiere Pro CS6 and I feel that this is attainable, as I have already come close.

However, the process is still mysterious in that every possible codec and plug-in effect is essentially a black box that has untold capabilities and flaws. In the worst cases, components claim to do one thing but actually do another if you look at output quantitatively.

The best looking output I've achieved so far is MLRAW-> DNG -> AE ACR -> Animation format -> PPro. Using synthetic high bit-depth gradients, I have confirmed quantitatively that the Animation format preserves bit-depth within PPro better than any other format I've tested so far. Mind that specific settings while rendering in AE are critical.

This benhmark allows me to test the actual impact of certain effects. In some cases PPro level controls are operating in 8-bit even though the overall effect is advertised as 32-bit. This discovery was disheartening but I'm glad I figured it out. The result will be a personal workflow that favors certain effects for certain tasks, and avoids others at all cost.

This is all fine, but since my workflow starts in ACR, the DNG -> ACR -> AE process is still a black box, with unknown impact on bit depth. Note that when using ACR with photoshop, you are given the option to open the resulting image as 8 or 16 bit. No such option is offered when using ACR with AE. So what IS the bit depth?

In order to measure this remaining part of the workflow, I would need to have an original MLRAW or DNG image with known bit-depth and dynamic range. With such an image I can use the same process I am currently using in PPro to determine end-to-end bit depth. I can explain that technique if anyone is interested.

So here is the question. Is anyone able to generate a fake MLRAW or DNG image that is, say 12-bit depth and a simple horizontal grayscale ramp? Using this source frame, a wide variety of black box solutions can be tested to see what they actually do to dynamic range:

- Adobe ACR -> After Effects
- OSX Raw2DNG Prores output
- Adobe PPro CC CinemaDNG support
- GingerHDR DNG support
- Cineform convertor
- etc, etc.

TLDR; I need a 14/16 DNG file with a 12-bit ramp that looks like this:

General Development / Bars facelift
September 28, 2013, 08:50:23 AM
I'd like to propose a facelift for the top and bottom LV bars. The goals are:

- better visibility in more situations
- more information displayable
- neutral coloring
- uniform layout

- Backgrounds are semi-transparent a la histogram background
- Bottom bar uses Argand 28 rather than 32 - greater density and more visible - no outlines
- Items are neutral white unless caution (yellow) or warning (red)
- Justified spacing - shifting is possible when data changes
- Using symbols is encouraged to save space
- Shoot the moon? Individually hide-able, sizable (S-23, M-28, L 32) and configurable content
General Development / Small facelift
September 24, 2013, 03:52:55 AM
I'd like to propose a small facelift to the main layout, taking into account the new fonts and other improvement opportunities.

General Development / misaligned branch destination
September 22, 2013, 03:18:37 AM
This happens occasionally when I merge the main repo into my fork at It's happening again as of today when I merged 4b3129d and 35 commits behind it:

magiclantern.bin: 425560 bytes
[ CC       ]   reboot.o
/var/folders/2g/_y7xb5b53735j6886z2zxb740000gn/T//ccStxfiE.s: Assembler messages:
/var/folders/2g/_y7xb5b53735j6886z2zxb740000gn/T//ccStxfiE.s:17: Error: misaligned branch destination
make[1]: *** [reboot.o] Error 1
make: *** [5D3] Error 2
falconmacbook::steve [magic-lantern-crop]$

Any idea what's going on?
General Development / Keeping forks up to date
September 10, 2013, 10:31:47 PM
I'm experimenting with ML on my own fork (

I understand that if I had a branch on the main ML repository, I'd be able to merge new commits into my branch. But I want to push my work for backup and sharing. So since I don't have write permissions on the the main repo, I have forked instead.

Question is, can I merge the latest mainline commits into my fork? I use SourceTree and don't have much experience with mercurial.

Too bad it requires the CC subscription. Adobe has me looking for an alternative to Premiere Pro.
I took a crack at solving my own issues with raw_rec cropmarks, and other on-screen stuff that gets in my way. This adds three options to the RAW video menu.

+ Cropmarks                 OFF
+ Verbose status           OFF
+ Buffer status              OFF

It also subtracts one:

- Digital dolly

With everything OFF, the only info displayed while recording is file name and running length. Everything ON is like standard raw_rec, but with the info pushed further out of the way.

This works on via HDMI with my SmallHD DP6 as well. No trashed output and no greyscale. Yay! (Playback still hangs via HDMI)

[EDIT] For 5D3, based on - 4380d31 , Oct 5 2013 . At your own risk, of course:
Feature Requests / Kill help menu
September 07, 2013, 12:47:30 AM
I think the Help menu is mostly worthless and not likely a priority in the future. I'd rather see continued effort into overall usability, intuitive design and in-context assistance. For example, individual menu items could have Help sub-items (or INFO press) for in-depth information as needed.

Clean out the dead wood.
Feature Requests / Configurable top bar and bottom bar
September 07, 2013, 12:14:49 AM
Let users set what's in the top and bottom bars:

       Top bar                                         ON
                Size                                     Small
                Time                                    OFF
                Display preset                       OFF
                Picture profile                       OFF
                Temperature                        ON
                Rawrec buffer                       ON

        Bottom bar                                   ON
                Size                                     Large
                Focal length                          OFF
                Aperture                               ON
                Shutter speed                       ON
                ISO                                      ON

In the simplest implementation, just lay out left-to-right. If it spills over, the user has to turn something off.

Small vs large is simply by font size.

Note e.g. Rawrec buffer above – let modules add stuff. Custom meters/glyphs etc can be implemented via fonts:

RAW ■■■■□    ♪ ■■■■■■■■□□□    f/1.2    1/100    4500°

Ideally all information is offered in both top and bottom bars, with reasonable defaults.

General Development / Need help compiling on mac
August 28, 2013, 07:53:28 AM
I'm trying to build on mac. I've gotten this far. Any ideas?

  $ make
  make -C  /Users/steve/magic-lantern/platform/5D3.113
  [ VERSION  ]   ../../platform/5D3.113/version.bin
  make[1]: truncate: No such file or directory
  make[1]: *** [../../platform/5D3.113/version.bin] Error 1
  make: *** [5D3] Error 2

The only lines I've so far changed in makefile.user are


My PATH contains:

General Development / Hourly builds
August 26, 2013, 01:04:54 AM
So many commits, so many cameras - wouldn't it be nice if hourly builds were available for anyone to test?

If I dedicated a machine to the task, anyone interested in writing a script to buildall and push bins to a branch every hour?
continuing form another thread...

Quote from: stevefal on August 25, 2013, 05:04:47 PM
Another possibility that may have already been discussed is an electronic slate.

Instead of marking the head of the audio clip with SMPTE, mark it with spoken marker ID# and an electronic clap. The audio would be stitched together from short samples and triggered by a button (at any time) and optionally on record start:

  "Mark one three two .... BLIP"

The BLIP is a tone that lasts one frame and is synced with a synthesized marker frame in the video, that contains the text e.g. "Mark #132". Not sure how that could be implemented - pre-made RAW blocks?

I suggest mark numbers because time codes are longer and therefore less convenient. When the mark counter is reset, the numbers will be super short.

The video marker could include, say, 10 frames of blue and one frame of red corresponding to the BLIP. N frames makes it easier to find them when shuttling.

The audio fragments could be file-based for easy localization.

If this is interesting I'll offer to contribute professionally recorded audio samples in English, and testing. I could also contribute RAW source material for video markers if that was appropriate.

Quote from: stevefal on August 25, 2013, 05:20:13 PM
To be clear, the idea of the slate system is that the camera would output the audio slate, and you would record it on a spare channel of your external recorder. In post you would then manually align audio to video using the markers, and then link or nest them as appropriate to keep them together. Of course it's not true sync, but it would be really useful as a poor man's tool.

Quote from: mageye on August 25, 2013, 05:29:09 PM

The RAW record already makes a bleep sound when you record. I have already tested this. So far I have been using a real clapper board but then I decided to test the viability of just using the bleep and an external recorder. I found that if you align the blip one frame right of the beginning of the DNG sequence it synchronises. At least it did in the few tests that I have done. I am not sure how consistent (or accurate) the timing is for the bleep but it I did manage to get a pretty tight sync.

For my initial tests I recorded the clapper and aligned to the bleep to see how much offset there was (with the clapper). As I said, I found it to be about a frame to the right of the start of the video recording.

Quote from: stevefal on August 25, 2013, 06:01:05 PM
Yep, so that part works. The auto-slate idea adds automatic clip identification in order to match audio-video content.

Quote from: mageye on August 25, 2013, 06:19:27 PM
I am all for anything that makes sound synchronisation automatic or 'more automatic'. So I am not against your suggestions. Remember also that in the conventions for the MLV format there should/will be support for sound. It looks to me like, if what is proposed in the outline of the format comes to fruition, then full sound and synchronisation will be supported (to a high degree of accuracy too). I have faith. I look forward. ;D

Quote from: AnotherDave on August 25, 2013, 06:27:31 PM
Why can't we just Jam Sync the current time to an audio recorder?  This doesn't need to output during recording at all.  It just needs to provide a way to sync with the camera's time before you record...

I'm (hopefully) picking up a used Tascam HD-P2 today to test this out.

We would only need to be able to lock the TOD from the camera to the free run TC of the recorder... And this should be doing this already.

Shouldn't it?

Not sure exactly what you're thinking - sync the audio recorder's clock what by what means? SMPTE LTC?
RAW 1080x818 > ACR, AE > Premiere Pro

Seems a nit, but I think the focus confirm 'green bars' would be way more visible if the unfocused color was black, rather than light gray/white. Currently there is little contrast between the two states.

Magic zoom is awesome!
The current text-based info displayed during rawrec recording is handy for storage troubleshooting, but things are working well enough for me now that I'm ready to for them to go away. Can we make that output optional? I suppose the error text such as when video is unexpectedly stopped should still display.

In its place I offer these bitmaps to display where Canon normally shows the tally light:

raw video:

raw video + audio:

Input is welcome and I'm happy to create other needed icons.
Currently the recorded area is outlined in a white box. This request is to (optionally?) replace that with a black opaque mask that blocks out everything not being recorded. I think this will look cleaner but most importantly it'll create a clear effect of what is being recorded, for composition purposes.

Maybe some button could temporarily hide the mask in order to see what's behind it, but that wouldn't me important to me.
Feature Requests / [WONTFIX] Battery fade indicator
June 08, 2013, 04:06:27 PM
I recall some post about losing battery charge while the camera is off, and I get the impression that's happening on my 5D3 now. But I have no simple way to tell. If losing battery power during off mode is a real possibility due to ML features or bugs, some kind of diagnostic would be helpful.

How about a debug feature that records time and battery charge upon power off and power on, and then provides a metric in the debug menu?

"The battery lost X% charge in N minutes while last powered off".

The values would have to be reset if the charge value goes up (significantly), or the battery ID changes.
I'm not sure if it's intentional, but the focus peaking indicators are strong while changing focus rapidly, but then diminish when you change focus slowly or stop. For me this creates a kind of hysteresis, because the diminishing indicators make me think I've overshot focus, when in fact I may be dead on.

The suggestion is to keep the indicators at the same intensity whether focusing fast or slow, or to at least make this an option.
I find that when looking at a histogram, the information I'm typically trying to get is expressed with the barest sliver of pixels, so I set out to design an indicator that exaggerates the extremes that I care about.

The goal was to show any number of near-clipping pixels within two stops in both directions, the fraction of clipping pixels, and for all of luminance, R,G & B.

If this is discernible, I shouldn't have to explain much, so here goes:

Clip Indicator (200%)

Details regarding thresholds and other logic are TBD. Thoughts welcome.
Feature Requests / RAW video file extension
June 06, 2013, 05:53:47 PM
Current RAW video files are created with a .RAW file extension. Suggestion is to use something unique in order enable OS file/app association without conflicting with existing RAW audio and image formats.

How about .MLR?
Currently (252af02) certain widths and aspect ratios show up in pickers even though they are unselectable due to mode constraints. This makes selection more complicated because you have to look at help text to see what you are actually getting.

The suggestion is to pre-compute valid selections and only display those. Then the help text can say something like "Use 5X zoom mode for more available widths", etc.
Feature Requests / Custom RAW aspect ratios
June 06, 2013, 12:34:47 AM
Related to

I know that things started out with width + height, and then moved to width (aka "resolution") + aspect ratio, but it would be nice to have both. Today I wanted to record a super wide clip that I could pan in post, but the current model doesn't let me choose anything wider than 3:1.

How about three menu items:

Aspect ratio

Selecting an aspect ratio from the perf-optimized list would compute Height like today (252af02), but selecting a custom height that is not relevant to one of the listed ratios could display the computed aspect ratio as "Custom: X.XX:1". That custom item would be transient and disappear when you chose one of the blessed ratios directly, or indirectly by picking width/height values that amount to a blessed ratio.
Feature Requests / RAW2DNG-HDR
June 04, 2013, 05:12:04 PM
How about blessed HDR RAW modes that write tags to the RAW file, instructing RAW2DNG which bits to patch together from alternate frames?

Clean 16-bit anyone?

If the 10-12 bit in-camera truncation exercise pans out, maybe alternate frames could even be written as 4 bits of clean shadow in order to minimize bit rate.
How about features to help conserve actuations and power drawn by liveview (i.e. backlight) between shots?

Imagining a full day of shooting video, I'd love to be able to lock the mirror whenever the camera is on, but with my control over whether liveview is drawing power. This way I can power down liveview to save power, without feeling like I'm burning actuations unnecessarily.

Basically the suggestion is a RAW video mode where each of 'standby', 'preview' and 'recording' states are power-optimized, and transitioning between them does not involve the mirror.

How aggressive could a 'standby' state be without turning off the camera?
Suggest to put current folder/file in titlebar of dialog, and rely on Q to back up the tree:


File Browser               <Q

File Browser               <Q

...would become:

File Browser               <Q

A:/                            <Q

... and at the file level:

M31-0945.RAW          <Q

This saves having to 'dial' down every time when forward navigating, and it adds the current location in all cases.
Raw Video / RAW video: Movie vs Still mode
May 30, 2013, 07:49:29 AM
Currently (on the 5D3) you can shoot RAW video in either Movie or Still mode. Are there benefits/drawbacks to one over the other? If not, isn't it a good idea to settle on only one, and avoid having to implement, test and explain the other?

Or are there features that are unique to each?
Maybe its a temporary condition and subject to more improvement, but currently playback of RAW video in-camera is at a slow frame rate, hence slo-mo. The suggestion is to purposefully skip frames in order to represent 1X playback, albeit at the low frame rate. Bonus would be to measure frame rate and calculate the skips dynamically in order to maintain as close to 1X as possible, accommodating organic variations in frame size, read rate, cpu, etc.
Sometimes RAW recording stops due to insufficient card speed, capacity or whatever. However it's easy to miss this event if you're not looking at the display when it happens. Playing a distinct error sound would be useful.
I like the approach this tool is taking to organize the split RAW DNGs:

But can't this be done in-camera? Rather than to create a single file that then has to be split in post, why not create a folder for each clip and write the individual files from the start:

-- M0000001
---- 000000.dng
---- 000001.dng

This would eliminate the need for RAW2DNG, and all it entails in development and post.

I assume this would be at the expense of certain efficiencies, but it may be a net benefit all things considered.
I've spent today trying to research the Canon image dataflow, i.e. 14-bit sensor > 8-bit video, and I'm still unclear on a few things. Too bad Canon makes this stuff so opaque.

Like everyone else, I want to get the most out of the measly 8-bits, and I'm looking to third-party picture styles as well as in-camera and potentially ML settings to optimize things.

I've come to the conclusion that a lot of people use and promote picture styles without necessarily understanding what they do, or which problems they can and can't solve. Everything is about tradeoffs, and making them takes solid understanding.

It seems the biggest concept people trip over is what happens when a 12 or 14 bit image is converted to 8-bit. People need to understand that 14-bit data can be clipped, scaled linearly or non-linearly, or a combination of all three in order to produce the 8-bit version that's recorded.

This discussion over on the BlackMagic forum is a good example of confusion/debate about this even among qualified people:

When data is clipped, the image loses detail in highlight areas. When data is scaled linearly (dropping least significant bits), detail is lost in shadows. If data is modified non-linearly through high-gamma or s-curves, highlights and/or shadows can be retain at the expense of lower color resolution (flatness) in the mids. The only way not to suffer these losses is to avoid conversion to 8-bit. RAW is great because you sidestep this issue until you're ready to grade in post.

Another breakdown I see is people choosing a low-contrast style because that's how to "get the film look" or to enable grading. While that is valid in some cases, what's invariably absent from the discussion is what scene you are shooting in the first place. If the scene I'm shooting has 5 stops of dynamic range, compressing that down to 3 stops is pointless and even counterproductive.

If we're all trying to capture the most of what we want from a scene, whether it's shadow detail, highlights, great skin-tone or whatever, we need to first know how much dynamic range is in the scene, and, assuming that it's greater than 8 stops/bits, what we want to sacrifice from those bits beyond 8.

This brings me to my questions. A1ex said this in another thread:

Quote from: a1ex on October 31, 2012, 11:23:08 AM
1) From ARM you can only see it as 8 bit, with all curves applied. The pipeline seems like this:

- 14bit data
- linear transformation (digital ISO gain, black level)
- HTP (nonlinear) - if enabled
- 14 to 12 bit reduction (suggested by 14_12 strings and by lack of shadow detail in aggressive Flaat styles, compared with digital ISO gain)
- nonlinear curves (like picture style)
- result: 8-bit 422 (codenamed Craw or HD buffer, almost 1080p, see Debug menu for exact size).
- Craw is downsampled for LV display
- Craw is fed directly to H.264 encoder, where it becomes 420 and slightly upsampled to 1080p.

1) When experimenting with "contrast" within a picture style, my impression is that lowering contrast brings a little more information from the 14/12 bit domain, via scaling, into my image (at the inevitable expense of more banding). Is this correct, or does contrast merely alter gamma within the 8-bit space?

2) The Picture Style Editor's curve UI seems only to alter dynamics post 8-bit conversion. That is, you can't use it to recover highlights or shadows from the RAW 14. Is that right?

3) If #1 and #2 are correct, my most important question is whether 3rd party picture style developers have access only to the mostly pointless parameters in the Picture Style Editor, or do they have back-door access to parameters governing the actual 14/12>8 bit conversion algorithm?

4) If it's the latter, what freedom is available for controlling the balance of truncation versus scaling during the conversion? Why don't style developers simply explain what their profiles do in terms of scaling and truncation? This is a math problem, but people seem to treat it as black, uh, magic.

When preparing to shoot a scene, I would like to measure the scene's physical dynamic range using a light meter or camera (or ML feature!) and then based on those measurements and a well documented set of 14>8bit conversion profiles, pick the best one for the shot.

P.S. Does anyone know exactly what HTP does? Does it linearly scale 14>12? Or does it non-linearly scale the top few bits of the 14 into the top few of the 12? Something else?
Forgive me if this is already there somehow.

Rather than to disable autoboot, I'd like to have a master switch, say, in preferences. When I use it, absolutely every ML feature is bypassed - it's 99.99% Canon until you press TRASH, at which point you get an ML dialog that lets you turn ML ON again.
General Development / ML UI rationalization
January 29, 2013, 01:37:55 AM
I think ML UI could be more straightforward, so here are some ideas what it could be like:

Audionut edit: seems imgur might be having some issues, here's another link to the gif from OP.
Feature Requests / [DONE] Menu customization
January 06, 2013, 08:54:55 PM
I am not experienced with ML so I am proposing this UI change as a user confused by my initial experience with menu customization.

The key used to enter the mode (Menu), is also used to toggle visibility. I still don't know how to exit the mode.

I was also confused that while in the menu customization mode, pressing Set works as though I was not in the mode. I expected Set to interact only with menu customization while in that mode. The Set button is habit-bound for toggling things.

I propose that the Menu button enter customization mode, and pressing it again exits the mode. While in the mode, I propose that Set toggles whether an item is visible.

I realize that on rare occasion a savvy user may want to enter menu customization mode in order to interact with a hidden item. But I argue that if they want to do that, they probably should not hide it in the first place. In either case, it is fringe possibility, whereas the current design is confusing in the common case.
General Development / Main menu design proposal
December 22, 2012, 06:09:20 PM
I would like to propose the following improvement to the main menu layout and icons:

Problems with the current design:
1) Items shift horizontally during navigation due to incorporated text label. This causes eye-hand targeting errors because the target moves.
2) Non-uniform icons and padding is messy
3) Icons unrefined

Benefits of proposed design:
1) Upper left label identifies current page consistently and in the traditional location
2) Icons don't move
3) Cleaner, more uniform icons (these can still be improved).
4) Greater contrast between selected and non-selected items

I am not up to speed in either modifying or building ML, but if someone is interested in working with me, I will provide all the necessary resources and metrics required to integrate this approach.

I am also not familiar with the organization of the project and how code is reused across camera models. I hope to use ML with my Canon 5d mkIII. If I have to choose one model to target, that would be the one.

For your reference, here is the current design in the same mode:

Feedback and collaborators welcome.