Linking AETTR to intervalomter

[garry23]

Wouldn't it be great if the ML intervalometer had a user variable to call AETTR every nth frame.

Joke!!!!!!!! Or not!

Please don't shoot a humble photographer trying to refine his craft.

[Audionut]

Wouldn't it be great if the ML intervalometer had a user variable to call AETTR every nth frame.

Please explain how that would be useful?

[garry23]

Thanks.

At the moment I achieve .CR2 holy grail timelapses by using the always on AETTR approach. Although I have David Milligan's script running in Bridge, for greater Timelapse post processing I personally use LRTimelapse and/or Panolapse.

Although at the moment it seems to handle the ML AETTR changes, ie it picks up and accounts for the (near) continuous exposure changes, I haven't really stressed this workflow yet.

Over the next few weeks I plan to test it some more, ie with an AETTR based 'ramping'.

My simple thought is to give LRTimelapse a 'simpler' task by getting ML to undertake an AETTR (reset) every nth frame. For example, carry out a fixed number of holy grail changes through capture sequence.

I think having two AETTR based approaches, ie one continuous and one based on every n frames, will allow greater holy grail experimentation, especially when using LRTimelapse.

But as I seriously said earlier, I may be wrong.

[Audionut]

Yeah, I don't see how that would be useful.  You are more then likely to end up with bigger problems, if the exposure changes radically during this 'nth' period.
And while deflicking can be a time consuming process, at least it can be achieved.  Overexposed images are forever gone!

If you're not worried about maximum SNR for each image, and allow some headroom for increased exposure, you may want to try dmilligan' Intervalometer ramping module.

What camera are you using Greg?

[garry23]

Sorry, I'm not clear I understand you, as I'm virtually guaranteed step changes when my ISO changes.

LRT handles these steps seamlessly, plus it deflickers.


 

[Audionut]

What exactly don't you understand?

[garry23]

I think we should stop this virtual conversation as I sense you are getting frustrated with me and that is not my intention.

You imply radical exposure changes could create issues.

The point with the holy grail approach is that you do have radical of step changes.

For example, this evening I used AETTR with an exposure limit of 1s, so when gone AETTR algorithm reached this limit it bumped up the ISO to 200, ie created a radical step change.

I stopped the timelapse then, but AETTR would have continued stepping up the ISO.

This is no different to adding an AETTR reset every nth frame.

However, enough as I'm not a coder and thus such dreams must remain just that....dreams.

[Audionut]

You have AETTR enabled, it adjusts the exposure.  If I understand you correctly, now AETTR would be disabled until some nth frame, where AETTR would activate again, fix exposure, disable for some nth amount of frames, enable, etc, etc?  Correct?

So explain to me, what happens when the Scene Luminance becomes significantly brighter during this nth period, where AETTR is disabled.


Remember, when ISO bumps 1 full stop with AETTR enabled, other exposure settings compensate.  With AETTR disabled, what exposure settings are changing to compensate for increasing/decreasing scene luminance?

[glubber]

If i understand you right Garry, you're trying to adapt the ML intervalometer to the "holygrail" workflow of LRTimelapse, right?
http://lrtimelapse.com/tutorial/

Simplified saying for this workflow the exposure is adjusted (manually or per tablet app) when the scene gets too dark/bright.
But between those adjustment steps ISO/Shutter stay fixed.
F.e. doing a Sunset-timelapse: Shuttertime or ISO are bumped up everytime the exposure is getting significally too dark.



Those "few" exposure steps are balanced in post by the LRTimelapse. Sudden luminance changes are handled by a deflicker module of LRT.

So these regular adjustment (every nth-frame) steps could be done by AETTR.


If memory serves me right, some kind of "LRTimelapse holygrail" function was implemented in a nightly 2.2 build??? But I never used it tho

Hi,
In a nightly build I've seen a "LTR holy grail" option in the timelapse submenu.
Does that mean that the new algorithm is now integrated in ML and that we therefore do not need this workflow anymore ?

Thanks

I hope this helps and i didn't confuse everybody.

[garry23]

@glubber

Thanks for taking the time to add to this post and help me get across my thought on a non-contiguous AETTR function in the timelapse 'module'.

As you say, the idea is that you would start the timelapse having carried out an ETTR or simply set an exposure manually.  The timelapse would start, and as indicated on your blue curve, which shows the overall scene luminance, the luminance would fall or rise, according to if it's a sunset or sunrise, until a specified nth frame, when the timelapse would call AETTR and make an exposure adjustment. The exposure settings would then remain fixed until the next nth frame when another ETTR call is made. 

Using this regular interval AETTR process would complement the continuous AETTR algorithm that is currently implemented.

As I say, timelapsers would then have two auto holy grail 'ramping' approaches using AETTR. The continuous one, as now, and the regular, nth frame, one I am suggesting.

As I said above, I'm not a coder so if this AETTR functionality was added to the ML timelapse areas, someone would need to add it.

Using LRT, as you do, it would be simple for this software to auto detect the regular key frames and deflicker.

Once again thanks for posting.

[Audionut]

Since the chances are great of overexposure during these nth frames, I don't expect anyone would pick this up, especially considering the current functionality works fine.

[garry23]

I take your point for the sunrise case. 

My partial thinking would work for sunset, ie where you would not get an over exposure following an AETTR in the nth frame.

Thanks for discussing this and, like others, I will simply carry on enjoying ML-enabled timelapse and continuous AETTR, which with LRT gives me a fully automatic holy grail tool set.

Thank you.

[Audionut]

I take your point for the sunrise case. 

And any other time that exposure suddenly jumps.     Say, the sun peeks out and says "boo", from behind some clouds.

My partial thinking would work for sunset, ie where you would not get an over exposure following an AETTR in the nth frame.

Which is where the current AETTR functionality works best.  When there is suddenly underexposure, AETTR has valid data to make an accurate decision on the first attempt at correcting the exposure settings.  When there is suddenly overexposure, AETTR has to start guessing how much to correct the exposure. 


When I was asking questions, this wasn't me being difficult, this was me giving you the opportunity to describe a strong user case for the new functionality.  Why?

If this new functionality was to be implemented now, then next week, myself and other would be fielding questions such as, "Why does AETTR only work every now and then in my timelapses", "Why am I getting overexposure when using AETTR".

Personally, I am happy to answer these questions when the added functionality is a benefit to the community, but so far, this functionality would appear to only be useful during consistently darkening sunsets, and when using third party proprietary applications.

The risks are, it adds nothing over the current functionality when used correctly (worse from an SNR standpoint), is yamlmo, and it will confuse some members of the community.

See the problem?  It's not a case of just coding something because it's useful to one or few members.  It has to fit within the guidelines of the development project, as a whole. 

The good thing about open sources projects, is that you are free to develop things for yourself.  Now, if you're not a developer, you don't have to drop everything, and start learning to code.  Make small efforts here and there, and with community help, before you know it, you will be able to accomplish simple development tasks yourself, and you won't have to rely on others doing it for you, or grumpy old bastards like me.   

[garry23]

@Auidinut

Once again thanks for the positive education and I really appreciate your patience with me.

I am an ML convert and have given talks on ML to my camera club.

I also try and blog about ML at my humble blog http://photography.grayheron.net

Once again, your positive feedback is much appreciated.....I only wish I could code :-o)