Messages

Here is the LRTimelapse preview for luminance (pink curve) with both non corrected and corrected EXIF shutter speed info.




LRTimelapse HolyGrail correction still have some problem when ETTR changes values every 1,2 or 3 pictures (the big bumps at the center) but if you look at the second part of the curve, it's more smooth now and the weird bumps with the 1/2 EV shutter values have now disapeared.

LRTimelapse will then do the job deflickering the all sequence (even with the non corrected version), but it's still better to start from right exif values (even if I don't know if the 1/181 and 1/203 are really the "real" exposition time but it's more accurate than 1/200 which I had before for both).

I have found a way to correct all my .CR2 EXIF Data with the correct Shutter Speed Value with a simple line of code :

exiftool "-EXIF:ExposureTime<Makernotes:ExposureTime" CR2_Directory

where CR2_Directory is the folder with all my CR2 files.

Maybe it's not the best to directly change the original CR2 source file like that ?

Hi,

I tried to see what I can find in the EXIF Data (from Jeffrey's Exif Viewer online here : http://regex.info/exif.cgi)
I've uploaded the 2 jpg pictures where a bump happens between "assumed" shutter value of 1/180 and the next at 1/200 (the 2 pictures from the preview)

First, I didn't think that there were so much informations stored, there's a lot of interesting things.

Here what I've found in it (1st value for picture assumed taken at 1/180, 2nd value for picture after the bump to 1/200)

EXIF

- Shutter Speed Value : 1/197 - 1/197
- Exposure Time : 1/200 - 1/200

MakerNotes

- Target Exposure Time : 1/203 - 1/203
- Exposure Time   : 1/181 - 1/203
- Exposure Time : 1/197 - 1/197

Composite
This block of data is computed based upon other items. Some of it may be wildly incorrect, especially if the image has been resized.

- Shutter Speed : 1/200 - 1/200


I don't know what these MakerNotes are and why there are 2 lines with Exposure Time but you can clearly see that the first is taken at around 1/180 and the second at around 1/200 even the two are tagged 1/200 in the EXIF Data.

I've tested with 3 pictures before and 3 after the bumps. The 3 before have that line "Exposure Time" = 1/181 and the 3 after have "Exposure Time" = 1/ 203 in the MakerNotes

Here are a zip with the jpg pictures (3 before the bump, 3 after) like the 6 CR2 I've uploaded before : http://lets-fall.com/timelapse/Timelapse_shutter_180_200_bump_original_jpg.zip

If there's nothing that can be done to get the correct value from camera, maybe an easy script could replace the wrong EXIF data with that correct stored value and write it in the xmp file.

Yannick

EDIT : the correct Shutter Speed Value is easily found with exiftool with the tag -Makernotes:ExposureTime

And here are all the CR2 from shutter 1/160 to 1/320 : http://lets-fall.com/timelapse/Timelapse_cr2_shutter_160_to_320.zip (1.4Go)

With your test reproducing indoor sunset, did you use the lens twist trick or not? Maybe it's the fact that the lens is disconnected that lets the ETTR module choose a shutter speed with 1/2 stop (even if the camera is set to 1/3rd). I don't remember hearing 2 beeps (just 1 beep) when ETTR changed the shutter speed value during my timelapse, it could be due to a non confirmation of the new shutter value by the lens.

I've uploaded 6 CR2 files (the first 3 that are obviously taken at shutter 1/180 (but tagged 1/200) and 3 after the bump that are tagged correctly are 1/200).

http://lets-fall.com/timelapse/Timelapse_shutter_180_200_bump.zip

I'll upload the 1.4 Go zip file with more CR2 tonight (it's 4am here).

Thanks for your help.

PS : it's a sunrise timelapse

I've changed the preview for better comprehension. I'm uploading the CR2 files (1.4 Go, should be ok in 4 hours ) I have the original JPG also that are less big, but I think you will prefer the CR2.

Thanks for the infos dmilligan, it's more and more clear in my head now. I've seen the 1/2 values and it seems that there are these values that are not repercuted in the EXIF data.

In the picture below, you can see the different bumps in luminance and the shutter speed values written in the EXIF. As you can see, there are bumps that are not repercuted. These bumps are corresponding to the 1/2 values. As you said, these values exist in the camera, ETTR use them, but the Camera seems unable to write the proper value in the EXIF data (and that's what I don't understand here). The Camera writes the next 1/3 value instead of the 1/2 one.



Yannick

edit : Preview clearer

I think I have spotted the problem. It comes from the file shoot.c

Looking at the source code, the shutter speed values are rounded like that :

Code Select Expand

int expo_value_rounding_ok(int raw, int is_aperture)
{
    if (is_aperture)
        if (raw == lens_info.raw_aperture_min || raw == lens_info.raw_aperture_max) return 1;
   
    int r = ABS(raw) % 8;
    if (r != 0 && r != 4 && r != 3 && r != 5)
        return 0;
    return 1;
}

int round_shutter(int tv, int slowest_shutter)
{
    int tvr;
    tv = MIN(tv, FASTEST_SHUTTER_SPEED_RAW);
    tvr = MAX(tv    , slowest_shutter); if (expo_value_rounding_ok(tvr, 0)) return tvr;
    tvr = MAX(tv - 1, slowest_shutter); if (expo_value_rounding_ok(tvr, 0)) return tvr;
    tvr = MAX(tv + 1, slowest_shutter); if (expo_value_rounding_ok(tvr, 0)) return tvr;
    tvr = MAX(tv - 2, slowest_shutter); if (expo_value_rounding_ok(tvr, 0)) return tvr;
    tvr = MAX(tv + 2, slowest_shutter); if (expo_value_rounding_ok(tvr, 0)) return tvr;
    tvr = MAX(tv + 3, slowest_shutter); if (expo_value_rounding_ok(tvr, 0)) return tvr;
    tvr = MAX(tv + 4, slowest_shutter); if (expo_value_rounding_ok(tvr, 0)) return tvr;
    return 0;
}

It seems to do that in order to have shutter speed values that respect 1/3 or 1/2 EV increments (there is the same thing in lens.c but only in movie mode) so it let the choice between 4 shutter speed values for each 1EV step

Code Select Expand

if (r != 0 && r != 4 && r != 3 && r != 5)

On my Canon 550D (maybe it's not the same on other cameras) for each 1EV step, there are only 3 values possible : for exemple 1/100, 1/125 and 1/160

If I look at all my pictures, there are 4 bumps for each 1EV step (which is normal looking at the code) but there are only 3 values possible for the shutter speed in the EXIF data so there is one bump that is not repercuted in the EXIF cause the shutter speed value doesn't exist in the camera even it used by the ETTR. These non repercuted bumps happen at each stop with values like 1/50, 1/100, 1/200, 1/400, ...

Maybe the cause is the lens twist trick that let ETTR change the shutter speed value without being able to see if it's ok or not (I've seen some waiting for changes confirmation in lens.c)

But even if it's the lens trick that causes it, it would be great to let the camera only choose between the 3 values available for each step and not for 4.

Yannick

Thanks for the answers.

I had to use 25 sec interval in order to shot the stars for the night part of the timelapse.

If the scene have changed (for exemple with a cloud going in front of the sun), the luminosity would only have change on the ground and not in the sky. Here, that's the overall luminosity that have changed and the sun was not even out at that time.

I've well understand the purpose of ETTR to change the overall exposure between shots but when the ETTR make changes, my shutter speed should have changed in the EXIF. Here, the values are the same. There are 24 consecutive pictures with a shutter speed of 1/200 sec and there's just a big bump after the 13 first ones. The same weird bump happen after 7 of the 19 pictures at 1/100 sec.

The next exact simlar bumps only happen when the ETTR change the shutter speed to 1/100, 1/125, 1/160, 1/200 or 1/250 (I only talk here of the small part of the all sequence)

That's why I was assuming ETTR may take pictures with shutter speed different from the Canon Camera like 1/115 or 1/225 and writting the wrong value in the EXIF. I should look at the code to understand it better.

But thanks for you suggestion even I don't think the problem comes from the scene that have changed.

Dmillihan,for the f0, you're right, I've change it afterwards in LRTimelapse and added it on the capture to show the lens original value.

(how can I active auto notification on the forum? I've activated it in the options, but don't see where I can switch it on a post, it doesn't appear in the "Attachement and other options")

Hi,

I've done my first AETTR night to day timelapse yesterday with my Canon 550D and ML v2.3 with an interval of 25sec and slowest shutter at 20sec. Everything went well except a little problem. The shutter speeds written in the EXIF data into the .CR2 files seems wrong for some pictures.

As an exemple here as some exemple of 2 consecutive pictures with different luminosity even the exif file show the same shutter speed value (that's not apertuer flickering cause I used the lens twist technique and the weather didn't change between these 2 pictures).



Maybe AETTR use different shutter speeds than the ones from the 550D camera (with shorter interval than 1/3 EV) and that's the ones from the camera that are written in the EXIF data but it's just a supposition.

Is there a way to have the proper value in my CR2 files except using the deflicker module? (I don't want to apply deflicker in the camera cause I should increase my interval to let it calculate deflicker. Also I'm using LRTimelapse to postprocess my timelapses and I need to keep the exposure initial value at 0 to let me change it as I want on postprod). Or maybe there is a way to let the deflicker module only create the xmp files (with the correct shutter speed value) but without applying deflicker.

These bumps in luminosity without the right shutter speed value make LRtimelapse unable to find the right HolyGrail keyframes and induce big bumps after applying the HolyGrail compensation.
Here is what it looks like after the HolyGrail compensation. (The pink curve shouldn't have these crazy bumps with right shutter speed value in the CR2 files)



Any suggestion to sort that out will be great.

Thanks

Yannick