Messages

Unless it was possible to change the iso gain on a row-by-row basis this wouldn't do anything that couldn't be done easily and with more control in post right?

My impression is that quite of bit of HDR could be avoided if there was an electronic graduated neutral density filter. I used to think that a GND could be accomplished in p.p., but I had a chance to see a GND in action.

With many scenics with a bright sky, my realization was that you could reduce the exposure a stop or two to capture shadows in the foreground, with less risk of blowing highlights in the sky.

If it could be accomplished, it would only be advantageous for my "use cases" if it worked in RAW. Also, I usually shoot scenics at low ISO, so adjusting the ISO per scan line wouldn't seem to be an advantage either.

Something that might be helpful ... in the "Change Log" that accompanies the "Nightly Build", perhaps have a separate summary of [Done] feature requests. I try to glance at the "Change Log", but I can rarely decipher how that relates to revised/enhanced/new capabilities.

Also perhaps a link to discussion about a new capability? For example, I'm still trying to figure out how to get Auto-ETTR to work consistently on my 5dm2. Ok, with trial and error I can usually figure out how something works, but ....

Maybe I'm the only one this applies to, but it makes me more than a little nervous to be randomly pushing buttons with barely tested firmware that could brick my camera.
(sorry for the whining)

This is really "out in left field" ... but based on what I've seen ML being able to do with Canon firmware, the mind boggles at what a similarly talented and passionate group of Canon gurus could accomplish with DPP (Digital Photography Professional).  Perhaps incorporate some or many capabilities of GIMP (which I haven't used)? With all kinds of info from .CR2 files for extra capability beyond ACR / LR?

FWIW: Adobe is in the process of radically changing their business model from s/w purchase to Creative Cloud subscription. There are a Lot.Of.Disgruntled.Adobe.Users.   Perhaps there is a "window of opportunity" for enhancements to DPP? My impression is that Nikon users can use a free version of CaptureNX, and I believe there is a much more capable version for sale ... NX2? NX3?

Or not?

I'm mostly ignorant about using video on my 5d2, but I thought ML team members might enjoy the following  ...

http://www.dpreview.com/news/2013/05/13/canon-magic-lantern-raw-video-canon-eos-5d-iii

references a glowing hands-on-review by Alex Reid:

http://www.eoshd.com/content/10324/big-news-hands-on-with-continuous-raw-recording-on-canon-5d-mark-iii

Sorry. I don't recall seeing this info in the v2.3 documentation, or the Nightly-Build (NB) sub-forum. I guess I didn't look carefully enough and/or got impatient.

I suppose I asked, even though I had what seemed like a work-around, because my speculation was that other ML NB newbies might have a similar question.

It seems like as long as there is any valid 5d2-212.fir on the CF card, the NB will probably install properly. Maybe? Or as I've observed, after two or three attempts?

Really, I'd be glad to carefully follow instructions, if I could find the instructions.

Perhaps the development team could consider including a valid 5d2-212.fir within the NB .zip? Or is that problematic? It's a rather small 64kb file.

Sorry if this has been asked before.

When trying to install the May 13, 2013 Nightly Build, I'm getting the message:
Firmware update program
Update file cannot be found. Please check the memory card and reload the battery and try again.

When I unzip the v2.3.NEXT.2013May13, there is a 1100D-105.fir, but no .fir for the 5d2 within the zip. Should I reuse another .fir for the 5d2?

I've gotten the NB (nightly build) to work twice before on both my 5d2 and T3i, and each time had a problem like this. IIRC, the firmware doesn't report a Nightly-Build, but v2.3.  It's not a confidence builder. Obviously I'm doing something wrong, like leaving out a step. Or I shouldn't use the 5D2 in "Non Magic Mode" to format the CF card prior to installing the NB?

Should the NB .zip have a 5D2-212.fir in it? I've got one dated from 2012.July.23, which I think is from the Canon firmware update.

Or should I get the 5D2-212.fir from the v2.3 "Stable Release"? Which is also dated 2012-July-23. It does seem odd that the NB .zip has a .fir for only the 1100D. Is that "as expected"? Because it wasn't in the v2.3 Stable-Release? Or there haven't been firmware updates from Canon for the 1100D?

Sorry to be slow, but it is perhaps from an excess of caution to try something that could brick my 5D2. I really, really want to explore automated dot-tune and RAW histograms.

Does it look like the rolling release idea is going to take off?

Perhaps a "Weekly Build" that could be expected to get "extra attention" compared to a "Nightly Build"? It would be understood to be less than an "Alpha".

So far, I've been impressed by the stability of the two "Nightly Builds" I've used on my 5dm2 and T3i. Still, my concern is that a "Nightly Build" can be not much more than "compiled semi-cleanly with an acceptable number of warnings from the compiler".

My perception is that one of the great strengths of ML is that the developers are passionate about what they are working on, and, perhaps even more important ... "eat their own dog-food". I'd feel more confident about trying out features if there was a sense that something like a "Weekly Build" had been served to several of the "developer dog's" with acceptable taste ... no developer's camera was poisoned / bricked.

The big issue with rolling release is staying on top of the documentation.

Agree, reluctantly.

As an overwhelmed-by-the-wonderful-vastness newbie of ML, I'm finding the 2.3 documentation to be less and less useful. When I first started using ML 2.3 not that long ago, I was impressed by the documentation. Now it is getting more frustrating. It can be Very Disconcerting for a newbie to try to figure out something, and have the doc's conflict with "ground truth" on the camera LCD.

Also, I'm really eager to try nightly builds for Auto-Dot-Tune and RAW-histograms, but reluctant to expose my camera to what I perceive to be a risky, trial-and-error, potentially costly pre-alpha nightly build.

Perhaps there could be something like a "skin" that exposes less capabilities to beginners (what is documented in stable release?), more to intermediates, more to advanced, and everything to developers?

I recall from my days of active FOSS participation, that there is a real tendency for devs to lose track of how intimidating the learning curve can be. With something like the Audacity audio editor, at least there was very low risk of damaging your computer with a hang. My perception is that even an experienced ML user has a very real chance to brick their DSLR with a nightly build.

Yet, if ML really wants to be have wide acceptance, it needs to retain some level of user friendliness and making newbies feel somewhat welcome. The reality can be that feedback from newbies can be as, or more, valuable than from experts. Unless ML is ok with being increasingly "experts only"?  I don't think ML is likely to ever be for beginning photographers, but there are a LOT more intermediates than experts/pros.

It does bring up the question: what assumptions about the experience/expertise level does ML want to make of its "audience"? So far? In the future?

After some quick tests, RAW histogram and the zebras are matching exactly what I see from RawDigger

My understanding is that using the desktop RawDigger utility would be the "gold standard test" ... it's indication of blown highlights and ETTR should correspond closely to what shows on the camera LCD? And the blinkies (if they are also based on RAW data)?

My further understanding is that use of the ACR histograms would be less accurate, as so much is going on that adjusts the pixel values (contrast, noise, sharpening, tone curves, etc). It gets more complicated because ProcessVersion 2003 is pretty good at Recovery, PV2010 may be better, and PV2012 is even better at Recovery, as long as all RGBG channels aren't saturated.

As noted in another post, this overwhelmed ML newbie is unclear just how to get the camera set so that RAW histograms are in effect. Sorry.

I suppose you could tell RAW histograms were operational by setting up a static, high contrast situation (using tripod?) and switching back and forth between having ML on, and having ML off. Or switching between RAW and JPEG in the Canon menus while ML was active? Correct?

My impression is that when in JPEG shooting mode and the histogram curve is just before the right-hand-side, a switch to RAW in the Canon menus would show the curve before the right-hand-side to a greater or lesser extent, but definitely a noticeable difference. Correct? Or do I again have a flawed understanding?

And a even more newbie question from someone unfamiliar with "zebras" ... can "zebras" be thought of as similar to "blinkies"? Or perhaps "smarter blinkies" that give more indication of "how much blown"? Rather than just "on / off" like blinkies?

After some quick tests, RAW histogram and the zebras are matching exactly what I see from RawDigger

I infer that this would be the "gold standard test" that the RAW histograms were working?

Alright, now you have true RAW histogram and zebras. 5D2 only.
To use, simply choose RAW in Canon menu and set histo/zebra to RGB. No new menus - it should just work.

Several comments (sorry for the possible tl:dr ... and the SMF forum s/w "list" doesn't seem to be working):

• ** I installed the 2013-April-24 nightly build ... bit of a glitchy install ... had to pull battery / restart 5dm2 two or three times to get it to come back alive ... so this ML newbie has been hesitant to test beyond checking the version number to confirm installation.


• ** I'm unclear just how to get the RAW histogram in effect. I infer from the above that selecting RAW in the Canon menus and also RGB in the Canon menu for histograms would make this happen? This ML newbie is confused by the mention of zebras (which I haven't used yet).


• ** Perhaps the default "it just works" shouldn't be to have RAW histograms? Based on the "principal of least astonishment", having RAW histograms is significantly enough different ... imo ... to the Canon default that perhaps it should be an intentional choice? Rather than a silent behind-the-back choice made by ML? Plus I think it gives greater visibility to a what I feel is an impressive plus of ML for people considering using ML?  Especially if they've wrestled with the hassle of UniWB?


• ** Or not so much astonishment? I may be like most DLSR users that assumed that blinkies/histograms are based on JPEG data when JPEG selected, and RAW data when RAW selected.  I supposed I was astonished  (unpleasantly) when originally trying to use ETTR that the histogram/blinkies were always based on the JPEG engine.


• ** Which brings up the question/complication: are "blinkies" based on RAW, or remain based on JPEG even when shooting RAW? If JPEG, you almost might want to disable "blinkies" when RAW histograms are in effect to avoid confusion/astonishment. Especially if RAW histograms are displayed when shooting in RAW, but the blinkies remain JPEG based.


• ** In any case, my impression is that it is a terrific accomplishment to get RAW histograms working. Well done!


• ** But in perspective, it would perhaps seem not that complicated for Canon to implement this, with their in-depth knowledge of the "inner black box". But I suppose that applies to a great deal of ML?  I wonder if the "out of my budget" pro-level 1DX has RAW histogram/blinkies?

I don't see how this would be much faster then doing it in live view.

To me, the issue is that that histogram from 0-255 ends up being fairly low resolution when you really want to see what is going on from the equivalent of 245 to 255 illumination per channel.

A real nice-to-have capability oriented to ETTR would be a RAW-based histogram from 245-255 for just the 10x region where you were zoomed into. That would enable avoiding the specular highlights that are ok to be blown out.

And what would ML adjust to increase exposure, shutter, aperture or ISO?  You might be happy with ISO, others with shutter etc.

I would think I'd invariably be interested in shutter speed. At some point, the exposure time gets too long in dark scenes, and then you can use reciprocity to get an equivalent exposure.  For example, ML might calculate ISO 100, f8, and end up with 4 minutes. I might be willing to use ISO 400 and f5.6 to use 30 seconds (if I did the math correctly).

https://bitbucket.org/hudson/magic-lantern/src/tip/modules/ettr/README.rst?

Alright, now you have true RAW histogram and zebras. 5D2 only.

Very cool. Great work.

Would it be possible to have "Automatic ETTR" capability? It would perhaps select the maximum exposure that only blew out one of the RGBG channels. That would let ACR PV2012 do its magic at a near optimal level.

The photographer would obviously be responsible for not including a specular highlight, such as the sun or chrome, etc.

For my "use case" on panoramas, I'd pick a bright frame that excluded specular highlights, determine the suggested, automatic ETTR exposure from ML, and then set the camera on Manual with that exposure.

ML already does this auto bracketing.

Is that a capability implemented after the 2.3 stable release? So I'd need to download and install a "nightly build" to use?

BTW, is there something between the "Stable Release" and "Nightly Build" as far as stability and level of testing? I'm hesitant to try out a nightly build. Even if I wait a week or so for the "RAW histogram" to be tested by other, more experienced ML users, my speculation is that a week-old "nightly build" past that specific capability would have "latest, greatest" capabilities beyond "Raw histogram" that might be relatively unstable.

Alright, now you have true RAW histogram and zebras. 5D2 only.

I wonder if ML could figure out an appropriate HDR range of exposures automatically, especially now that RAW histograms are becoming possible.

I suppose an approach would be to figure out the exposure that accomplishes ETTR, then an exposure that accomplishes what could be thought of ETTL for the deepest blacks encountered in the frame. The overall histogram from the combined images would "fit" in a histogram, with no "spikes" on the left or right.

Alright, now you have true RAW histogram and zebras. 5D2 only.

Wow, I'm impressed. I suppose I would need to install the "nightly build" to test this out?  Would it be better for this ML newbie to wait several days or a week or more so that more experienced ML users can test out? I'm not confident I could recover from a bricked 5dm2.

Hmmmm ... I suppose it is a bit more complicated that my original thinking. Adobe ACR 5/6 with Process-Version 2010 can do a pretty good job of "Recovery" if one or two channels aren't blown. My limited experience with LR 4.x is that PV2012 is even better at that "Recovery", especially if only one channel is blown out.

So .... my impression is that even if a RawDigger-like ML capability "in the field" reports that RAW sensor values are blown out, it may be a usable frame if one or two channels aren't blown. 

Or not? I may very well have a flawed understanding of how "Recovery" works.

30 seconds is better then removing the card, or connecting camera to computer to double check highlight detail.

To me, a RAW-based histogram that took 30 seconds to build would be well worth it. I'd turn that off for subsequent shots, after getting the ETTR exposure dialed in.

A lot of the pictures I take are panoramas, which tend to have a very high dynamic range. I'm trying to use HDR less and less.

So... I'll disable this feature for now, but research continues.

Thanks for taking an interest in this. Some of the info in the posts above was over my head.

My impression is that ML doesn't really have access to the RAW sensor data, but only the JPEG preview info. I'm a bit surprised by that, but the inner workings of the firmware are a mysterious black box to me.

My experience is that I haven't really been able to reliably count on the jpeg-based blinkies for ETTR "in the field". I've played with UniWB quite a bit, and find the green cast to be annoying. I've also tried using a "Picture Style" that starts with Neutral, and lowers Saturation and Contrast by -4. That seems to work about as well as UniWB, but still flawed.

BTW, my experience is that I can get a UniWB frame to base Custom WB on by either taking a "Black Frame" at 1/8000 with the lens cap on, or the opposite, aim at the sky and expose wide open for 2+ seconds to get a completely white, blown out frame. At least the Custom WB has a very green cast.

I've found the RawDigger utility to be very informative during post processing for taking a close look at whether one or more of the RGBG channels has been blown out.

IMO, A "Raw Histogram" or "RAW blinkies" would be a terrific addition to ML, but my speculation is that providing the maximum RAW value might be more do-able for ML developers, and provide much of the value.

For my 5d2, a blown channel seems to be indicated with any channel having a value of 14737. I'd appreciate something as basic (if possible) as something like:
MaxRAW=#####

[ML will reduce the green color cast]

From earlier post related to "RAW histogram"
http://www.magiclantern.fm/forum/index.php?topic=3924.msg21395#msg21395

For now, the closest approximation is UniWB. ML will reduce the green color cast, it's not perfect, but better than nothing.

ML newbie using 2.3 on 5d2

I infer from the above, that ML has a way to use a UniWB custom WB, but to adjust the LCD display so that the green color cast is less of an issue.

Correct?

If so, how? This ML newbie hasn't noticed how this is accomplished.

Roger Cicala is the founder of LensRentals, and very knowledgeable about MFA. LensRentals has dozens (hundreds?) of cameras and thousands of lenses. He might be willing to get involved in testing automated MFA. I'll check with him.