Messages

In photo mode (CR2): white level depends on digital ISO, e.g. at 160, 320 and so on it's 1/3-stop lower than at full-stop ISO. Oddly enough, at ISO 250 it's not higher than at ISO 200.

In movie LiveView: digital ISO does not affect raw data, so the white level is always the same. The level from exif should be correct.

In photo LiveView, ML alters the white level to adjust the histogram so it matches the CR2 one. That's one of the reasons why you should not record raw video in photo mode.

Current scripts only work in PicoC, not in TCC.

Use the official nightly builds, not the raw ones.

lower whitelevel by 15%

On what cameras is this needed? If raw2dng has pink highlights too, it's a bug in ML and you should report it.

Nice!

For 48fps 1920x672 (max resolution) you only need 103.5 MB/s. According to my simulator, you should already get 260 frames at 80MB/s and 700 at 95MB/s.

Try it here: https://bitbucket.org/hudson/magic-lantern/src/tip/modules/raw_rec/speedsim.py

No.

Is the edmac_memcpy, 150a9c5, fixed not for corrupt frames?

I have no idea, you have to find out

Look in menu, there are warnings... didn't try on 60D though.

Wait a minute... my latest speed optimization was 3 days ago... (1479df3+f884d7a+150a9c5)

Could it be this? https://bitbucket.org/hudson/magic-lantern/commits/61b6b1dc97a15a6c780cdae587a75679fc53aac3

Can you run a hg bisect to identify the changeset?

If the color was black, you wouldn't see the borders on a very dark image.

If you notice, a lot of things have double border in ML (black+white), including spotmeter and raw cropmarks, so you can see them no matter what's behind.

Note that maximum target level for ETTR can only be -0.5 EV or less. If I push it to 0, it will have no way to know how much it should go back if it overexposes a little bit, so the algorithm convergence will suffer.

Also, the accepted tolerance in ML is between -0.2 and 0.7 EV, so it has a preference towards underexposure (you said it's better to underexpose a while ago). I didn't think it's worth wasting another click for such a small difference.

Another source of errors: at ISO 100, ML is only constrained by shutter rounding (only the following fractions are accepted by Canon code: full stops, 3/8, 4/8 and 5/8 EV). At higher ISOs, the ISO can be set in full stops, and shutter has to be ideally the value from menu. 1 EV of rounding error is a bit too much, so I'm using 0.5 here.

You get the card speed and the idle percentage (so you know how fast it can go). Do the math.

e.g. if your resolution needs 75MB/s, ML will write at 94MB/s with a 80% duty cycle, so it will not write to card 20% of time (idle=20%).

This trick lets ML estimate how many frames you will get on subsequent recordings, even at different resolutions.

Cropmarks don't fight with overlays, because they were designed to integrate with them; but hardcoded graphics thrown on the screen will fight.

You need to mark the af dots first for it to work (set them to 0 in raw buffer).

2 was already done since the first implementation...

4 done, and seems to be a nice time saver, since it takes the next picture before quick review pops up on the screen.

- If the exposure is spot on (within a small tolerance), it takes one shot.
- If it's slightly underexposed (say less than 5 EV or so), it takes 2 shots.
- If it's overexposed, it usually takes 2-3 shots.
- If it still can't get it right after 4 shots, it gives up.

Bonus: it can be used like a simple bracketing, sort of.

Uploaded new raw2dng, with bad pixel fix from marekk. Very cool trick, didn't know about it.

Why is this a ML bug?!

It's 1728x672, resize to 3:2 (1728x1152) and it looks OK to me.

Shouldn't be int correct_height = max_res_x * 2 / 3 ?

The image covers usually a 3:2 or a 16:9 area. I don't see why Canon would have designed it for 5:3... and from the dng posted a while ago, with the square floor pattern, it should be 3:2.

Obviously, the overlays don't run on water, they need some CPU power too. Turn off some of them...

In lens.c, lens_info.raw_aperture_min and raw_aperture_max. These are not yet exposed to PicoC, but TCC should see them.

Note: raw_aperture_min is minimum raw value (that's wide open).

Was anybody able to use Auto-ETTR of the new build in photo mode?

Are raw zebras and histogram working in photo mode? That's a prerequisite for photo mode ETTR.

Yep, it's possible to control digital ISO for each scan line (just look at the bugs from 1-2 years ago). I don't see the point though.

Looks like you didn't read the post above. We don't have a 700D, and since we have plenty of things to do with the other cameras, we don't have any plans to buy one anytime soon.

Therefore, nanomad asked if somebody with C skills can volunteer to port ML on 700D. It's likely very similar to 650D, we can provide some advice about the porting process, but that's pretty much it.

From the massive interest in ML for 700D (10 retweets), you should understand that this port has a very low priority for us. Don't expect any kind of release anytime soon.

The good news: porting ML is a lot easier than you may think; a lot of things are figured out by trial and error, enabling features, seeing what works and what not, tweaking the source code here and there and so on. You need some basic C skills, common sense, a lot of spare time and the desire to learn by exploring some unknown territory.

I'm afraid it's not possible, look the thunderbolt experiments to find out why.

Ouch...

The error may indicate something in the vsync functions; maybe disable CONFIG_STATE_OBJECT_HOOKS first, then narrow down in the vsync calls?