Auto Sunset, Sunrise, Day Long TimeLapse module

Started by zuzukasuma, September 11, 2013, 12:37:24 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

zuzukasuma

well,

most of us likes to shoot timelapses and our biggest problem is "flicker" on those. so, is it possible to put a calculator, script or a module in the unified to shoot timelapses without spending 10-15 minutes before shooting?

for example, a script can read from camera clock and location set to it then creates a projection for shooting timelapse, from 1/500 to 1/4 at iso 100, f/8 etc.

also, If I can help with it I'd like to build a database of 10 degree GPS coordinate* for sunset, sunrise times from this site http://www.esrl.noaa.gov/gmd/grad/solcalc/sunrise.html

*in the future 6D can shoot everything automatically, we don't have to input anything at all, just power on and run the module.

so, what do you think?
in a complicated relationship with eos m.

a1ex


zuzukasuma

in a complicated relationship with eos m.

g3gg0

i bet he did.

the question is, why do you want helpers for problems that you wont have when you used what he suggested?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

zuzukasuma

Quote from: g3gg0 on September 11, 2013, 01:09:24 PM
i bet he did.

the question is, why do you want helpers for problems that you wont have when you used what he suggested?

and I bet I've used his suggestions but my idea is totally different than what he put in magic lantern!
in a complicated relationship with eos m.

dmilligan

I'm thinking about working on a custom timelapse module that lets you program all sorts of stuff over time, including intervalometer period, exposure, focus distance, etc. I think it's possible to do some really cool stuff with capabilities like that. I'll keep you posted on how it's going.

I would probably make two ways to program any parameter over time. Either a buch of values listed in a file, or via a mathematical expression i.e. period=5+(t/sin(t))

chris_overseas

Quote from: zuzukasuma on September 11, 2013, 01:11:03 PM
and I bet I've used his suggestions but my idea is totally different than what he put in magic lantern!

You seem to be suggesting that knowing the approximate sunrise/sunset time would help the camera decide what to do? Determining the correct exposure is impossible from that - you'd still need to allow for current sky conditions, moon phase and location, streetlights/light pollution, altitude (since it affects sunrise/sunset times), shadows from landscapes or buildings, latitude, camera direction (into/away from sun), ...

If you simply want to know when sunrise or sunset is on a given day so you know when to go out shooting, you'd be MUCH better off with a mobile app like Sun Surveyor to help you plan ahead for the sun and moon conditions. Those apps are far more flexible and powerful than anything that could be built into the camera.

Having said that, I can see a little bit of merit in being able to lookup sunrise/sunset times on camera. I just don't see what it would have to do with the timelapse functionality.
EOS R5 1.1.0 | Canon 16-35mm f4.0L | Tamron SP 24-70mm f/2.8 Di VC USD G2 | Canon 70-200mm f2.8L IS II | Canon 100-400mm f4.5-5.6L II | Canon 800mm f5.6L | Canon 100mm f2.8L macro | Sigma 14mm f/1.8 DG HSM Art | Yongnuo YN600EX-RT II

zuzukasuma

@dmilligan, yep, I've read the other post about refocussing for stars, its cool and definitely worth to try, so bad winter is coming but we still have time for that
in a complicated relationship with eos m.

zuzukasuma

Quote from: chris_overseas on September 11, 2013, 01:29:40 PM
You seem to be suggesting that knowing the approximate sunrise/sunset time would help the camera decide what to do? Determining the correct exposure is impossible from that - you'd still need to allow for current sky conditions, moon phase and location, streetlights/light pollution, altitude (since it affects sunrise/sunset times), shadows from landscapes or buildings, latitude, camera direction (into/away from sun), ...

If you simply want to know when sunrise or sunset is on a given day so you know when to go out shooting, you'd be MUCH better off with a mobile app like Sun Surveyor to help you plan ahead for the sun and moon conditions. Those apps are far more flexible and powerful than anything that could be built into the camera.

Having said that, I can see a little bit of merit in being able to lookup sunrise/sunset times on camera. I just don't see what it would have to do with the timelapse functionality.

well, I think I'm having hard time explaining myself. go use your little toy!
in a complicated relationship with eos m.

a1ex

you will still have to deflicker the output, no matter how precisely you compute expo parameters
ettr exposes optimally (want math proof?)
you can do any kind of ramping in post
so why bother?

zuzukasuma

Quote from: a1ex on September 11, 2013, 01:41:33 PM
you will still have to deflicker the output, no matter how precisely you compute expo parameters
ettr exposes optimally (want math proof?)
you can do any kind of ramping in post
so why bother?

ok, nevermind, delete thread and I'll start a kickstarter campaign!
in a complicated relationship with eos m.

dmilligan

You can't ramp focus, shutter angle, interval period in post. You can sort of fake ramp them but the effect would not be the same. My goal is not flicker free or optimum exposure. Instead it's cool effect like changing the shutter angle from very small to very large and back. You would see the effect of varying amounts motion blur. Or shoot wide open and have the focus move through the scene and back. Or have an accelerating or decelerating timelapse without wasting shutter actuations by speeding up or slowing down in post (by essentially throwing out frames)

a1ex

That's a good point. You can already ramp focus, but shutter angle is not controlled directly.

g3gg0

seriously, why are people getting snappish if they want things and they got told that there is another way?
this is not making any fun.

there was *no* offense, *no* pun or anything like sarcasm, just a hint what will already cover the expectations and the response is:
  "have you read my post?"
  "go use your little toy!"
  "delete thread and I'll start a kickstarter campaign!"

damn, this is not what the magic lantern community is built on.

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

arturochu

ML community is falling apart :(
nah, just ignore those comments, btw can you do 120 fps and hack the 1dx? or do i have to make a kickstarter campaign?
Chu

zuzukasuma

Quote from: g3gg0 on September 11, 2013, 04:03:23 PM
seriously, why are people getting snappish if they want things and they got told that there is another way?
this is not making any fun.

there was *no* offense, *no* pun or anything like sarcasm, just a hint what will already cover the expectations and the response is:
  "have you read my post?"
  "go use your little toy!"
  "delete thread and I'll start a kickstarter campaign!"

damn, this is not what the magic lantern community is built on.

- language -
in a complicated relationship with eos m.

zuzukasuma

Quote from: arturochu on September 11, 2013, 04:14:42 PM
ML community is falling apart :(
nah, just ignore those comments, btw can you do 120 fps and hack the 1dx? or do i have to make a kickstarter campaign?

I'm not talking about impossible stuff - language -
in a complicated relationship with eos m.

Audionut

Insulting other users isn't helping your cause.

Also, if you feel that a developer has not fully understood your proposition, you should probably,

A)  Take note of the other features that have been described to ensure that they do not fulfill your current requirements. 
B)  Explain to the developer calmly, and in a manner that shows respect to the knowledge they have over the code they look at for hours/day, how exactly their suggestion does not fulfill your requirements so that they might have a better idea on how to accomplish your goal.

Please watch your tone in the future.

zuzukasuma

Quote from: Audionut on September 11, 2013, 04:52:50 PM
Insulting other users isn't helping your cause.

Also, if you feel that a developer has not fully understood your proposition, you should probably,

A)  Take note of the other features that have been described to ensure that they do not fulfill your current requirements. 
B)  Explain to the developer calmly, and in a manner that shows respect to the knowledge they have over the code they look at for hours/day, how exactly their suggestion does not fulfill your requirements so that they might have a better idea on how to accomplish your goal.

Please watch your tone in the future.

just did to you. use the information. I probably see the results in 12 months released by a1ex.
in a complicated relationship with eos m.

Audionut

Thread reopened.  Lets hope discussion can continue in a civil manner.

nanomad

I still don't get what this module should do. As a1ex said it's basically impossible to pre-compute the perfect flicker-free exposure in-camera.
Can you explain why ETTR + post processing isn't enough?
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

dreamingof8a

Has there been any new thinking about this?
I know it's an old (and apparently heated) debate, however I just stumbled across the thread while thinking about and searching for the same thing.

First of all, I can definitely see a merit in having this function:
When shooting a timelapse, I usually don't want to eliminate all flicker, but rather get an overall smooth, natural transition from pic 1 to pic N. If there are ocasional clouds etc I do actually want to keep the resulting flicker since this is the natural look of the scene. Just imagine there is a bright sunny day with blue skies. I'm timelapsing, and in 10 subsequent frames a cloud covers the sun behind me so the foreground in my picture gets darker, while the sky pretty much remains the same bright blue. Using ETTR and deflicker, the sky would be brightened during those 10 frames to compensate for the "flicker"/change in overal brightness. I don't think this result would be nice, I'd rather keep the "natural flicker" of the foreground, essentially using the sky as my reference point.

Back to the GPS thing now: On a bright sunny day wihtout clouds, one could in theory calculate the correct exposure by knowing exactly where and when I am taking the picture. Looking at a holy grail scenario, I could probably also calculate pretty accurately what the correct exposure transition of the scene would be like under these ideal conditions. Hence I could simply program my bulb timer according to this curve.
Obviously there might be clouds or mountains or buildings that have a strong, general impact on that curve (not talking about those natural flicker things that I actually want to keep). So in order to get good results I need to compensate for those specific conditions. So this is what I have in my head:

- Basic bulb timelapse: calculated "ideal" exposure curve for given location and time
- key frame 1 for first frame: on a cloudy day I would probably want to increase the the overall exposure as compared to the "ideal" value. Basically take a properly exposed picture and use the settings.
- key frame 2 for sunset: I would expect (needs to be looked into however) that at or around sunset, the rate at which the exposure value of the scene changes reches a maximum.
- key frame 3 for last frame: if I only take a pictures during the day without major overall changes I could just go with the same compensation as 1 and hope the weather stays the same. In case of day to night transitions, I would set ISO, F and T to values that give me good milky way pictures (if I expect a starry night). Going from night to day I might leave the end key frame open unless I have a very good Idea what the weather is ging to be like ....
- now the script would basically fit the "ideal" exposure curve in between those three key frames and calculate a compensated ideal curve.

I am pretty sure with this alone the results could be pretty good out of the box. If there are major unforseen changes to the overall exposure, they could probably be fixed in post processing (similar to the ramping script for bridge). Maybe there is even a possibility to get the gpslapse sript to continuously monitor the histogram and compensate for larger changes (eg if the sky goes form generally clear to overcast which is not really a "natural flicker" anymore) - however it would probably be hard to differenciate between "natural flicker" and general brightness.

GBTimelapse does actually exactly everything that I just desribed, so basically someone just has to convert it into a ML module .... :)

dmilligan

Quote from: dreamingof8a on November 05, 2015, 04:26:53 PM
- now the script would basically fit the "ideal" exposure curve in between those three key frames and calculate a compensated ideal curve.
And you have invented a time machine that allows you to do this?

It sounds to me like you are proposing that the camera choose an exposure curve based on three exposure key frames that happen in the future. That is impossible.

Otherwise, if you are proposing that this is something that is done in post, then simply use AutoETTR, and do this in post (already possible).

Quote from: dreamingof8a on November 05, 2015, 04:26:53 PM
however it would probably be hard to differenciate between "natural flicker" and general brightness.
It's actually much easier than you think to tell the difference, because we have exposure metadata stored in the file (so we know when and how much of an exposure jump is being caused by changing of exposure parameters or if it is 'natural flicker').

dreamingof8a

Quote from: dmilligan on November 05, 2015, 06:19:00 PM
And you have invented a time machine that allows you to do this?

It sounds to me like you are proposing that the camera choose an exposure curve based on three exposure key frames that happen in the future. That is impossible.
Well, assuming perfect weather, the exposure curve would look pretty much the same every time similar to the one shown here in the manual of GBTimelapse (which by the way extensively uses such a precalculated curve to help predict the next exposure)



This curve could be fitted to two or three points: starting exposure (known), estimated night exposure (best guess depending on weather forecast and so on) and maybe a sunset exposure again based on best guess/experience.
I could imagine that even if you are a bit off with your estimates, those errors could be handled in post pretty well.

QuoteOtherwise, if you are proposing that this is something that is done in post, then simply use AutoETTR, and do this in post (already possible).
It's actually much easier than you think to tell the difference, because we have exposure metadata stored in the file (so we know when and how much of an exposure jump is being caused by changing of exposure parameters or if it is 'natural flicker').
True, but this involves manually going through all the frames .... but right now it's definitely the way to go. And maybe you are right, it might be the only way. I'm just not fully convinced yet :-)