Messages

Feel free to implement color playback. If it's just as fast as the grayscale, that's even better.

Some cameras set them to 0 (e.g. 60D), others correct them and output clean raw data (5D3). I don't know if there are other situations.

Good point. "Always ON" now works just like before, and "Auto Snap" will take more pics until ETTR is achieved.

https://bitbucket.org/hudson/magic-lantern/commits/74c8b0b4f29d

Yeah, instead of 0% it prints milliseconds.

With 68MB/s and 10% idle, you can push it to around 75, no?

In this context, idle means it's not writing to the card. So, 10% of time is writing at ~80MB/s, 90% of time is just waiting for buffers to fill.

When idle time becomes 0, the buffer will slowly fill up and recording will stop eventually.

If there's a tiny bit of idle time, it's likely that recording will not stop (continuous recording). With this hint, you know how far you can go (this is used by ML to predict how much you will record at current settings).

The grayscale preview does just that.

Wait a minute, you aren't getting any idle time at all?!

Why don't you wait for module settings to be implemented?

Or you are not aware that all this is bleeding edge?

Why not just setting FPS override to 10?

I have no idea how to solve that, it's specific to digic 5 cameras.

Optimize for low light.

All Canon tasks are idle in photo mode.

Does it boot without card?

I'm not aware of any side effects from these two mistakes, actually I always do exactly the same things on 5D2 (sensor cleaning on and removing the card with camera on).

Sounds good, and having some reference footage is great for fine-tuning the convertors.

For example, it was quite hard to find a banding correction algorithm that covers pretty much all practical cases, and I could use this to verify any future changes in this algorithm.

I'd say you can open a separate thread for this; it may become quite large.

This is heavily underexposed... maybe you need to get a Nikon

Okay, check this one: https://bitbucket.org/hudson/magic-lantern/commits/7382b2586b14

I've just realized that I didn't have to save the entire histogram from previous shot, but just a few key values (e.g. how far the highlights are from the median). If less than half of the image is overexposed, the median would still be correct, so I'll assume the highlight position didn't change.

This is an idea. I've used 3 percentile values (not just median) for better robustness. If the scene did not change, it should be spot on (only one test shot) even if 90% of the image is overexposed.

Of course, for this to work, the algorithm needs a properly exposed shot first. So, if the first thing you do when you start the camera is to take an overexposed image, it will fall back to the old method. But in normal usage I expect it to work very well.

Can you upload a DNG?

Well, auto ETTR is an iterative algorithm; in ideal cases it gets spot on in a single iteration, but:

a) if there's overexposure, it has no way to know how much to go back (and it tries to guess based on how big is the overexposed area); sometimes it works, sometimes not.
b) if the image is really underexposed (say -10 EV), the noise will affect the results, so it will need another iteration
c) if the scene changed, anything can happen

For a) things can be improved by looking at Canon metering indicator (problem: can't read it in M mode on all cameras), or by extrapolating the histogram in the clipped area (based on data from previous shots). If the scene is static, the second approach should be very accurate, but it needs some non-trivial math.

Just solved the underexposure warnings in LV, with the dynamic range numbers from DxO.

Yeah, I'm trying to warn people not to record in photo mode; I've disabled the raw_rec operation in photo mode, and other guys are enabling it back...

Sigh...

For outliers, median rejects them very well, but it's harder to compute than mean. But yeah, a hot pixel in that area may affect the results.

Do you have any samples with black band and no noise?

See the post from Ilias. You need to do the ISO test again btw; the ML version you have used had wrong metadata for white levels.

Press info to turn on the display before running the benchmark.

LOL, do you know how to take pictures with your camera? That's the photo mode...

You need the display enabled, otherwise the benchmark will choose to play mode. These two give almost identical results, but it's unlikely to get these speeds in LiveView.

I've just picked a random example. ExpSim does not use the exposure values you pick from menu; they use some complex algorithm to get something with equivalent brightness.

Raw exposure in ExpSim is done in full-stop increments. For smaller increments, Canon applies digital gain to the raw data, and this is the reason I had to do the same trick by faking the white level.

Otherwise, you would have histogram data and ETTR hints rounded to full stops, and overexposure warnings not working at all at certain shutter speeds.

Movie LV is accurate for raw video, because you record that.

Photo LV is not accurate because ISO 100 at 1 second is done as ISO 3200 1/30 or whatever Canon chooses.

White point in movie LV is constant.

White point in photo LV is also constant, but ML changes it to make the histogram match the CR2 ones as closely as possible.

So... in photo LV, overexposure indicators are OK, but underexposure ones are random.

Yes, underexposure zebras are random now, need disabling...