video_av.mo (Aperture priority)

Started by pparent, November 05, 2017, 12:29:37 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

pparent

[Edit:] code of the module: https://github.com/pparent76/ML_video_av

Hi,

I'm in the process of developing a video_av_expo module. Basically it will allow to have a fixed aperture in video mode but adapt dynamical shutter speed and iso to get a good exposure.  Iso will allawys be set to its lowest possible value, and will only be increased if shutter speed is at its minimum.

I sounds like a pretty easy module, but I'm having a problem with a basic thing that is blocking me: I can't get proper exposure estimation.  Canon av value is not processed in video mode (500D) . So I tried to use auto_ettr_get_correction() but it fails to work because raw_hist_get_percentile_levels fails because raw_update_params() returns 0. No idea why...

For now I've started my tests by modifying autoexpo module, but I will write a clean module as soon as it works properly.

How can I get exposure estimation in video mode in a module?

Any help appreciated!

a1ex

For H.264, my advice would be to look for Canon's histogram data, which is real-time and - at least on recent models - available for every single frame, and expose for the median computed from there. That requires a bit of reverse engineering - I've noticed it some years ago, just need to remember where.

Using ETTR correction for H.264 will not give good results (guess why it only works with raw video) and is very slow.

On 500D, overriding ISO and shutter per LiveView frame (to get smooth correction, rather than jumps) is also going to be a bit difficult. Other features that require per-frame overrides (such as HDR video or gradual exposure) are not available on this camera. Probably doable with ADTG registers.

You may already get the desired result with Canon's AE - just untwist the lens a bit to disable the aperture control.

pparent

Hi,

Thanks a lot for your answer.

Untwisting the lens in video mode does work thanks a lot! :)

Couldn't we have an option to partially overriding the lens properties? (By modify lens.c & movtweaks.c)  I will try to test that (except if you tell me that's impossible). It would probably avoid to have to untwist the lens and loose auto-focus.

Thanks again


a1ex

ETTR correction depends on raw histograms. Since optimal exposure for RAW != optimal exposure for H.264, the ETTR module does not even bother to try it in movie mode if the raw backend is not enabled. That's why the ETTR routines fail.

I wouldn't recommend using RAW-based exposure adjustments for H.264, because it won't account for Canon's rendering, picture styles etc (for example, a non-overexposed RAW can easily give a clipped histogram in H.264).

If it's a one-shot adjustment, then you could expose from our YUV histogram; just keep in mind it's not directly mapped to EV, so you will need an iterative procedure until the exposure settles. The YUV-based white balance from ML works that way (ancient code; should be updated for RAW, where a single iteration would be enough).

Partial overriding of exposure parameters might work as well; didn't try overriding that way.

pparent

Ok thanks a lot.

Actually what I wanted initially was only to know Am I underexposed, overexposed or fairly well exposed, to adapt iteratively.

But if we can get to override on some parameters it would be a lot simpler an cleaner. This line makes me think that there is hope it could maybe be possible:

CONTROL_BV_TV = CONTROL_BV_AV = CONTROL_BV_ISO = CONTROL_BV_ZERO = 0; // auto

I'll keep you informed.

Pierre.

pparent

I've made it! So exciting!  :)

Basically what I did is add in lens.c

in PROP_HANDLER( PROP_SHUTTER_AUTO ) at the begining:

Quote
if (dont_override_tv && CONTROL_BV)
{
if (ABS(buf[0] - lens_info.raw_shutter) > 0 && buf[0]  )
                    {   bv_set_rawshutter(COERCE(buf[0], 0x60, 0x98));  bv_auto_update(); return;}
}

in PROP_HANDLER( PROP_ISO_AUTO ) at the begining :
Quote
if (dont_override_iso && CONTROL_BV)
{
bv_set_rawiso(buf[0]); bv_auto_update(); return;
}

I will write a clean patch soon with new menu entry allowing to choose whether to override iso and tv or not.

ps: Though I must admit that exposure changes are not as smooth as in fully automatic mode. There must but some trick to smooth exposure changes in fully automatic mode.

pparent

Actually what I'm going to do is:

1- A minimalistic patch on lens.c/.h simply adding 2 lines: a property "shutter_auto" to "lens_info" struct, and "lens_info.shutter_auto=buf[0];" at the begining of in PROP_HANDLER( PROP_SHUTTER_AUTO ) .
2- A module video_av_expo.mo, that adapts tv and iso automatically while smoothing changes in time as nicely as possible.
3- video_av_expo.mo will have the feature to choose Av value and then apply it to the lens, rather than needing to go physically through all intermediaries values, as currently the case.

I'll post the code as soon as ready probably in less than a week!

pparent

Hi,

Here is a demo of a video shot with my module on 500D in Av mode, to get an idea of how smooth it will be:

https://www.youtube.com/watch?v=Pga949uc4Ys

It still requires improvement, I'll keep working on it in following days/weeks, and eventually it will work just fine! I'll publish the code as soon as it is clean enough and usable.

I used set_movie_digital_iso_gain_for_gradual_expo() to smooth things out and FRAME_ISO in read-only mode.

Pierre.

Danne


pparent

I've put my under development code here.

https://github.com/pparent76/ML_video_av

There are still some bug in smooth mode, that provoke few glitches, that I will try to solve on Sunday.

DeafEyeJedi

Quote from: Danne on November 09, 2017, 02:40:06 PM
Cool, keep it up!

+10

This is all really intriguing and an interesting project of yours. Definitely following this one @pparent!

Ideally this feature would be somewhat extremely useful for gimbal work.  8)
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

pparent

The current version on my github is usable on 500D. I expect it to work for other "rebel" model (550D, 600D, 650D, 700D,..), but I cannot be sure before some test is done. I may buy a 550D some day, when I have money and find a good deal.

Options of the module
*Smooth changes:whether we want changes to be progressive or not
*Allow jumps: wether we allow jump changes in expo when huge expo changes are required (e.g instant change from dark to daylight).

Other demo videos 500D 
* Small expo changes, low light, using the canon's expo lock button to change expo only when desired, f2.3:
https://www.youtube.com/watch?v=uaHAz3Y-A8U&feature=youtu.be
*Medium expo changes f2,5: https://youtu.be/ey-Q1uXLu2k
*Extreme expo changes, with jumps enabled f1.8: https://youtu.be/pRJcHhET1Qw


Magic lantern testing build with this module
(As it requires a small modification to core you have to update magic lantern completly)
USE AT YOUR OWN RISKS
*500D.111: tested on my camera  https://own-mailbox.com/magiclantern-Nightly.2017Dec01.500D111.zip
*550D.109: not tested yet. https://own-mailbox.com/magiclantern-Nightly.2017Dec01.550D109.zip

Todo
*For cameras with FRAME_ISO and FRAME-SHUTTER override, take advantage of this to make the system,  smoother, a lot faster and more reliable.
*Make the module work for raw video mode.

Usability
*Taking the expo at the beginning of the scene and lock it: perfect
*Scene with few and progressive light changes: very good. Example: daylight selfy youtube video during sunset, dawn, or cloud passing-by.
*Scene with big light changes: Could be better, but good for amateur shots (*) and will be better in the futur for cameras with FRAME_ISO override.

(*)Anyways I think only amateur shots would involve this kind of huge changes in light in the same shot.

Next?
My next module will focus on focus in video mode.

pparent

New important improvements:

*Enable the possibility to use FRAME_ISO_OVERRIDE for those who have it
*Various improvement on other cams: faster and correct some bugs
*Add the possibility to choose a threshold of expo delta, before we actually change expo: adds a lot of stability.

Testing images: (At your own risks).
*https://www.own-mailbox.com/magiclantern-Nightly.2017Dec10.550D109.zip]https://www.own-mailbox.com/magiclantern-Nightly.2017Dec10.550D109.zip
*https://www.own-mailbox.com/magiclantern-Nightly.2017Dec10.500D111.zip

Not yet tested on 550D but I will soon have one.

Todo
*Test that it works on 550D, and if possible other "Rebel" model.
*Make the module work for raw video mode (I will not work on that soon).

pparent

I have a 550d from today.

I tested my module on it, it works well, after very few adjustments related to FRAME_ISO_OVERRIDE.

Unfortunately FRAME_ISO _OVERRIDE, really does not bring much on this camera because there is no FRAME_SHUTTER_OVERRIDE to go along.

I will soon sell my 500d but it will make sure the module still works on it.

Working image on 550d:
http://www.own-mailbox.com/magiclantern-Nightly.2017Dec12.550D109.zip

If anyone else than myself could test it, it would be great! I would be great also to test on 600D,650D,700D,750D,...

pparent

Just wanted to mention that I've been using my module (latest git version) for some time now in various projects, and it's been very useful to me.

DeafEyeJedi

I bet. Any chance you could share your branch where I could actually try and compile your module for certain cameras that I could test on?
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

pparent

@DeafEyeJedi

I shared the code i the form of a patch to the ML core source (on lens.c/lens.h) + a standard separate module.

https://github.com/pparent76/ML_video_av

The patch to the ML core source is very simple simple you can apply it by hand if  lens.c/lens.h source has changed since (it's just about adding two functions, and two variables).

Once the patch applied the module can be compiled as a normal module.