Messages

[4) When taking the photo, ML will let the camera meter but then after metering (for example 1/100s), ML calculates the actual exposure based on the Av setting as compared to the maximum aperture and uses this value for the actual exposure (in this case 1/200)]

I would like to revive this old thread as there has not been a final answer whether or not this would be possible with Magic lantern at all:

1) We're using a chipped manual lens which has maximum aperture of the lens stored (e.g. f/2. and simulates an adjustable aperture
2) set the lens to desired aperture (eg f/4)
3) in Av, also set the "camera aperture" to f/4
4) When taking the photo, ML will let the camera meter but then after metering (for example 1/100s), ML calculates the actual exposure based on the Av setting as compared to the maximum aperture and uses this value for the actual exposure (in this case 1/200) to avoid overexposure

I understand that it would be easier to just forget about the true aperture feedback, however that's the only reason I installed those chips on my Samyang lenses ....

Cheers
Felix

@dmilligan: thanks for the link, I too had been fooled :-)
@a1ex: true that's of course possible but the delay might be annoying by interrupting a trail of light for example.

Thanks guys!

When I was looking at a dark cityscape today something came to my mind: wouldn't it be cool if it were possible to bump up the ISO during exposure?
It could be used i the same way 1. and 2. curtain flash is used, to capture the beginning or the end (or theoretically any point) of a long exposure.
Would this in theory be possible with ML?

Hi,
I was playing around with ETTR, recording a day2night2day timelapse. Upon review of the images I noticed a strange thing: sometimes the ETTR exposure corections will result in a frame that is quite underexposed, before ETTR settles with a better value - okay, this is understandable as ETTR doesn't exacxtly know what the next frame will be like, although I would expect a more "intelligent" exposure change, meaning: if the previous changes in exposure were rather small, the ETTR-step should also be rather small. But okay, that's not the issue, as I think it will easily be corrected in post. However what I don't understand: for some reason, the deflickering doesn't work at all in these situations: the frame just before the initial compensation will be greatly overexposed (by deflicker/XMP), while the following frame will be greatly underexposed.
Here are some screenshots.

First: an example of those weirdly corrected/deflickered frames

#2070 is the extremely overcorrected (by ETTR) frame, and both #2069 and #2070 are then weirdly deflickered ...





After exchanging the two deflicker-values, it looks a lot better - coincidence?



This shows that it actually happened a few times (red boxes), but not always (green boxes). Also ETTR usually did a much better job with compensation (green boxes) - why doe sit sometimes jump so much?


My setup:
Canon 5D2 with ML 2016Oct09

Intervalometer: 35 seconds
ETTR: Always on // 32" // -0,5 EV // 1% // 6 EV // 3 EV // OFF
POst deflicker: XMP // 50% // -4EV


Any ideas?

Thanks!

One question regarding ADV_INT and AETTR: Does ETTR take the ramping into account? For example, I'm changing from f/4 to f/3.5 at some point; does ETTR automatically compensate for that by chosing a shorter exposure time in order to be closer to the optimum exposure rather than overexposing due to the aperture change?

You're right, however as mentioned in the other thread regarding using GPS coordinates, I definitely see potential here to basically get rid of any flicker other than the camera-inherent (aperture flicker, Tv flicker)

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.

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).
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 :-)

Why? There's no good reason for this. The only possible thing that would happen is you end up with a less than ideal exposure. During a sunset you could end up with overexposed shots and during a sunrise you could end up with underexposed shots.

Well I am just trying to find a way to avoid "flicker" which is caused by changes of the exposure during the day (or during the night). For example:
taking pictures during the night with a house in the foreground. It's well after dusk so exposure is constant at a certain level. Now the lights inside th ehouse are turned on. Ideally this would not impact the exposure. ETTR however would decrease exposure, resulting in a darker sky. Once the lights are off, exposre increase again to the former level. The result is flicker in the timelapse. If I could tell ETTR in this situation to maintain exposure or increase only, this flicker wouldn't be there. I know this only helps in a few situations (for example a passing cloud during the day would be considered a reason to "legally" increase exposure) but maybe it could help as a first step ...

Is there a way to limit ETTR to only change exposure in one direction similar to the former bulb ramping function? When shooting a day-to-night timelapse, I usually never want the exposure to go down but only up. Would be great to have an option lke this, ideally with "turn-around" times so yould for example shoot an unattended day-to-night-to-day timelapse and tell ETTR to only keep or increase exposure until a certain time, eg 1am, and then only keep or decrease exposure.

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 ....

Hi,

I shot a flickerfree ETTR sequence using UFR sidecar by accident . Is there a way to convert them to XMP (or apply the adjustments to my CR2 files, then export them to XMP)?

Thanks!
F.