Messages

Alex

I suggested the above as I thought you had worked outa way to display a RAW histogram in LV, rather than 'just' in review mode.

In other words if a RAW histogram can be displayed in LV I would like to suggest a user option to display, say, the right hand highlight stop as a zoomed in histogram would be very useful

May I simply endorse the above and ask if it would be possible to factor in a user variable that allows the user to select the entire histogram or a fraction of it, from the 100% highlight end. It could be in stops or fractions of the full histogram.

I have written this to hopefully help the broader ML community better understand some of the 'feature requests', in this case ETTR.

Obviously it is written from an 'IMO stance' as ETTR and other strategies to maximize dynamic range, or captured image data fidelity, are not universally agreed upon.

First, to maximize the captured data's fidelity for post processing I believe we need to try and accomplish several things with our exposures (other than ensure they are in focus etc): minimize noise, maximize S/N and capture the most tonal information on each sensor element (RGBG). However, trying to accomplish all these at once, for a real world scene, is near impossible.

For example, to minimize noise we should only shoot with a camera cooled to its lowest operating temperature, eg to minimize dark current noise. The longer we shoot and if we shoot on hot days this noise contribution will increase, just like entropy.

To maximize S/N we should seek to capture the maximum number of photons, and no more, ie achieve a Full Well situation. However, although we may be able to do this for a real scene, it will only be achieved in the few sensor elements in the brightest part of the scene, it a very small % of the overall statistics of the captured image. For instance the subject/focus of the scene may be in the mid tones or lower, ie not a specular highlight that is creating the Full Well situation.

I believe we all now know that DSLR cameras do not capture and process light like our eyes or film. The process is linear and thus this is why there is apparent merit in ETTR and bracketing strategies. That is trying to get the maximum tonal graduation into the capture, without 'blowing out' important data.

So far so good.

I think bracketing is not 'contentious' as we usually are on a tripod and at the base/lowest ISO, ie where we can guarantee that some of the sensor elements capturing the scene information we deem important will be at their Full Well level, albeit only a few %, unless we 'over bracket'.

I think the issue comes when we introduce the ISO factor, ie when doing a handheld bracketing set or seeking a handheld ETTR single exposure. In both cases we may need to increase the ISO to achieve a good shutter speed, eg the slowest bracket greater than 1/FL, say OR greater than 1/50, say.

I for one take a lot of handheld 3-brackets on my 5DMkIII and have confidence that increasing the ISO will not create too many issues in post processing. However, from my reading on sensors etc, I will not increase the ISO above about 1600-3200, as this will transition me from the region where the camera noise sources dominate to where the sensor limitation dominate, ie I'm just not capturing enough photons at high ISO. This transition will vary for each camera, but the bottom line is, that if we follow an ETTR strategy, there is an upper limit (ISO) we should all be aware of.

In conclusion, I believe ML is on the right track by giving the user choices to maximize DR and S/N wrt the scene, ie extended bracketing (although with my 5DMkIII this is less importance compared to my 50D) and a RAW LV histogram (a transformational feature).

Finally, IMHO, using all the ML features without understanding the camera-system's limitations could bring disappointment.

Thanks for the clarification, I should have worked that out for myself!

I think many ML supporter are eagerly waiting a raw histogram in LV.

One, most probably silly, thought is could ML be used to provide the user a overexposure warning in the view finder?

My thought was that ML could high jack part of the canon display, for example could ML be used to flash the exposure indicator? Or one of the other canon display figure to give an unambiguous warning to the user that the raw histogram is clipping?

As I say, most probably a silly thought.

ML already does this auto bracketing.

All

There has been a lot of posting in the CHDK community on quasi-RAW histograms, that is giving the user a higher bit depth histogram, ie beyond the JPEG 8 bits.

The result is that I can now use Shot_histogram and inspect, say, the high end. The way the scheme works is that the algorithm lays down a sampling field and creates a sampled histogram, of defined bit depth, from the image.

As I say, it is not a true RAW histogram, but it is of higher fidelity that the 'native' one.

The downside is that it takes on-camera processing time, however, for its main use this is not so important. For example, I use it in am auto bracketing script as well as an ETTR script. It also has uses in timelapse scripts, eg bramping decision making.

Bottom line, the CHDK approach is not a RAW histogram, but it certainly seems to work for my scripts.

The above is just and observation and not a request.

Regarding the 10-11 stop DR range above, I believe this always creates confusion.  If you take where Canon sets the black point and the max value of a 14-bit histogram, then the camera is only able to capture about 5-6 stops of tonal data, as measure in Ev from the top of the histogram.

In other words half the tonal range is held in the right Mose 'stop', and then half again in each stop until he black point is reached, hence ETTR strategies.

I think using Auto bracketing solves most problems, other than a desire to shoot fast brackets.

Of course I could be totally wrong!

Surely we have this in the form of auto bracketing. In other words select auto and the Ev step and ML will take as many brackets to cover the dynamic range of the scene. I have seen auto bracketing take 15 images. In other words you are not limited to a max of 9, you simply can't specify or predict the number of brackets past 9!

All

Once I manage to get the DotTune function up and running in my 50D I will cross check with the other AFA process I use, ie FocusTune.

I have found FocusTune to work well and it provides graphical plots that help provide confidence that you have indeed hit the sweet spot, ie it will be good to see DotTune and FocusTune align!

Cheers

Garry

All

As I don't build myself, I will wait for the next nightly build and add to trsaunders' testing, ie I have the following Canon lenses: 50mm, 100mm macro, 70-200 F4, plus I have 10-20 Sigma and 150-500 SAigma.

Cheers

Garry

trsaunders

You beat me to it: that is testing on the 50D.

However, although I downloaded the latest nightly build (23 Feb), for some reason I don't see the same ML start layout as you.

Strange?

Any idea why this should be?

Also, no AFA function.

Cheers

Garry

I thought you might say that. In other words ML can not control the MLU across separate shutter operations, as in LV.

A pity.

Thanks for the quick reply.

When I take a sequence of brackets, say using auto detect, and have MLU engaged, my 50D seems to engage and disengage MLU every shot.

Whereas if I put the camera in LV and use bracketing, the mirror remains up throughout the sequence, is all I hear is the shutter operating.

Is there a way to get the mirror to go up and remain up throughout a bracketing sequence when  NOT in LV ?

Alex

Some of the CHDK community have sent time pushing the limits. For instance, as I say, I use a histo call that covers 12bits, and it could be extended to 14bit. It is achieved by sampling  the sensor RAW. Also all the exposure calls work in APEX 96 space.

What is was suggesting is that at least we look at where CHDK is as we construct an ML requirements set of functions. For instance, I know one of the CHDK community has added in functions in CHDK few sensor level exposure reading such that in camera  holly grail timelapse can be smoothly achieved.

Obviously some of the ML functions will be unique to ML, eg mirror up functions, if possible, however, any will and I suggest should be common.

Bottom line: whatever the ML. Developers, such as yourself, can do will be great; IMHO there could be beneficial if the ML community took stock of the CHDK scripting status, especially in the 1.2 developers trunk.

Regarding extending scripting functions/calls, as a CHDK user as well as a ML user, would it be a good start to emulate some of the CHDK scripting functionality. For instance, I have an autobracketing script that runs in CHDK where i access a CHDK histogram call to get the histogram at a 12bit level, ie the level my S95 and G11 operates at. This page gives an example of the functions http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page

Just a thought, as the CHDK community have done a lot for scripting of P&S cameras, so why reinvent the wheel, lets bootstrap!

I don't know about ML's HDR video mode, as I would have thought the data content would be much lower than shooting in RAW. But I may be wrong.

I have used the ML intervalometer to take multiple images of star fields and then used software to stack the images with the intention of reducing the hi ISO noise content, ie I was shooting at an ISO of 1600 or 3200.

G

ETTR is an emotive subject. The fact our camera meters to 'midde gray' does mean that we are not fully exploiting the data capture in RAW, ie the binning of data is not linear in RAW. This is why we use exposure compensation.

I believe ETTR has its maximum value when you are capturing a dynamic range that is addressed by a single image.  What we don't want to do in this situation is clip any highlights with 'structure' in them, ie details we wish to see. I will ignore speculars.

As the histogram and blinkies are calculated from an over sampled JPEG, ie a few percent of the RAW data, it is often hit and miss that we have pushed as much data to the right as possible. My simple understanding is that with ETTR we are increasing the s/n at a given level, ie noise stays about the same, but we 'just' gather more signal.

For scenes with a wider dynamic range we have bracketing.

Bottom line: I believe a RAW based measure of highlight clipping would take ML to another high.

Garry

For those of us who favor ETTR capture this would be a great feature. In addition, if the actual histogram presentation can not be made more readable, ie bigger, I wonder if ML could have the option to present the right most quarter only.

At the moment I use blinkies to estimate the ETTR exposure, but of course this is on a highly JPEGed image.

Bottom line: I wonder if ML could support the ETTR shooter?

Garry

Just to be clear my suggestion is only to use the external device as a means to change ML settings, ie increase readability of the ML menus in the field.

Unfortunately I am not a programmer.

Cheers

Garry

A simple idea, that I recognize may not be possible. But here goes. Would it be possible to add an iPod, iPhone or android to ML as an external input/output interface for ML.

That is you can use your iPhone, say, as the way to change ML settings, ie more readable than the LCD screen.

Cheers

Garry

Francis

Like you I strive for a natural looking image.

I guess there are two ways of 'looking' at HDR-touched imagery. First HDR as a style. Second as a technique to overcome the limitations of our camera sensors to capture life's dynamic range.

I am one who tries to use HDR to overcome my camera's limitations.

As I say, Canon users are very fortunate to have ML, especially the auto-Bracketing capability.

Cheers

Garry

I now virtually only use the auto bracketing setting for my HDR captures. Of course I use a Tripod and I am not too critical to motion. If I need to capture a quicker sequence I will revert to the in camera AEB and high speed, and accept I am imited to 3 shots (50D)..

All these images were taken with the 50D in ML auto HDR mode:

http://grayheron.smugmug.com/Landscapes/Kasha-Katuwe-Tent-Rocks/26654412_hTH9fn#!i=2229550236&k=nrg77xR

You can't beat ML!

Cheers

Garry

With the GPS adapter you get the geo info of the shot you took.

But the new canon GPS unit only works with the very latest camera, ie 5d kk iii

Cheers

Garry

Forgive if this has been requested before: I looked and could not see any reference.

With the release of the Canon GPS adaptor, I wonder if Magic Lantern coud be used to extract the relevant EXIF info for those 'older' cameras that can not access the GPS info directly.

Cheers

Garry