Some Equipment Approaches for Time Lapse

[VidThreeNorth]

Back in 2016 I bought some action cameras specifically to record fireworks and time lapse videos. One in particular was a sort of prototype version of the Gitup "Git2" with a rectilinear 4.35mm f/2.8 lens. It was not actually called a prototype, but it was a small batch special order version of their regular "Git2" which was normally assembled with a fisheye lens. The lens did have more barrel distortion that I would have liked, but because it was a pre-assembled working camcorder -- and cheap, and with higher resolution that 1080p, I decided to get one. Overall I have been very happy with it. I am still having problems with color rendition for fireworks (though I am slowly getting it dialed in), but it worked very well for time lapse right of the box.

The video I am linking was one of several attempts at getting a good sunrise time lapse. It was the best of the bunch. Some of the others were "nice" but this was simply better. Consider this video a "baseline". I have started making new versions today with the goal of making something better. Todays was not better, so this is still the best.

Over the past couple of years, I have bought some still and video cameras, partly with the hope of getting something better for time lapse (and better for fireworks). Unfortunately, nothing I bought turned out better than the "Git2" for time lapse. I will describe what I have later and what issues make them less suitable for time lapse later.

"20170130 Toronto Sunrise Git2 4.35mm 2.8 Lens [4K] v2"

 

[VidThreeNorth]

GitUp Git2 for Time Lapse

If you looked at my "baseline" 4K time lapse (above) in 4K -- which I will NOT advise you to do, you might have been very impressed with its detail, at first. After a while though, you might have felt that "well, it's very nice, but I think it could be better," and yes, I agree.

I will try to briefly identify where this setup had, and still has issues:

This special version of the GitUp Git2 costed around $140 US (plus shipping etc), back in 2016. It was eventually replaced with the "Git2P". The original "Git2" is still available, but only with a fish-eye lens. I think the "Git2P" might be available only with a rectilinear lens now. I am not sure of that, and it is unimportant. The "Git2P" uses a Panasonic sensor (Panasonic MN34120), which is probably a bit cheaper than the Sony sensor in the "Git2" (Sony IMX206). The lens on the "Git2P" is a bit shorter focal length, which almost completely eliminates barrel distortion. I have seen comparison videos between various configurations of the "Git2" and the "Git2P" and the "Git2P" seems to be the better camera, but really the only difference is the more linear lens. There is a slight difference in color rendition, but I would not say that one is better than the other. It is a matter of taste.
[2019-01-24 01:25 Correction:
While the "Git2" is now only available with the "Fisheye" lens, the "Git2P" is now available with either the "90 degree" [rectilinear] lens or the "170 degree" [fisheye] lens. So when ordering the rectilinear version, one has to be careful to order the correct camera.

Here is a link to a video by someone in Russia who tested the Git2P with rectilinear lens. While it goes through a few options, really, the most important part of the test for me is the first few seconds where his sample shows clearly the near perfect rectilinear view of the lens. It is easy to see that it is much better than the lens I am using.

"GitUp Git2p (90 degree lens, no fish eye) - Comparison of the modes", posted Apr 2, 2018 by "VideoFromMoscow", length 12:08
""]

The only question I have not found an answer to is whether there is a significant difference in low light. I have seen some low light tests and I am not sure if I saw a real difference. I thought the Panasonic looked a bit less noisy, but I did not see extensive testing, so I currently consider them about equal even in this area. I actually have another camera with the same Panasonic sensor (SJCAM SJ5000plus) but the lenses and firmware are so different that comparison would essentially inconclusive.

As I write this, the "going price" for most configurations of the "Git2" and "Git2P" are about $100 US for the camera alone, and a bit more with an accessory package.


The Known Issues of the "Git2" Approach

Mostly, the biggest issues are the same as most Action cameras like the GoPro Hero 4 series. In fact the "Git2" was closely modelled on the GoPro Hero 4, and can be used in the Hero 4's underwater housing, and uses the same USB Mini connector power cord.

Lens Focussing Related:

The biggest issue is that the lens is not designed to be focussed. The "Fisheye" version uses a nearly identical lens compared to the Hero 4 Silver (I know because I also own a Hero 4 Silver). My 4.35mm lens is probably focussed at about 3' - 4'. Nearer or farther than that is "covered" by a combination of regular optical depth of field, and firmware sharpening. On the current firmware of my "Git2" there are 3 levels of sharpening -- low, medium and high. This can be used in place of focussing. For objects farther, one can increase the sharpening. I leave it at "Medium", which means I allow "infinity" to be a bit soft.

GitUp was selling three rectilinear replacement lenses before the "Git2P" was released. There was the 4.35mm lens that came with my version of the "Git2" and two others. The "Git2P" got one of these other lenses. I eventually bought the 3rd lens which has probably not been used as a "standard" lens on a "GitUp" camera yet. Mine was the shortest focal length and had marginally less barrel distortion than the lens on the "Git2P". I have that lens waiting to replace the lens in my "Git2", but I have not had the time to get the change done. I estimate it will take 1 - 2 days of work. If/when I get that done, I will set the focal plane a bit further out than factory standard, making the camera a bit sharper at longer distances, out towards infinity. I will lose a bit of near depth of field, but I have no intention of using this camera for objects less than 4', so I will not lose any relevant functionality.

Sensor Related:

The next issues of my "Git2" are sensor related. The 16MP Sony sensor is fairly noise at low light, and there is a very bad color shift at lower light. I have been trying to get rid of this color shift problem for my "fireworks" videos, and GitUp provides a very good manual color setting capability which covers all three primaries (Red and Blue directly and Green by compensation). But I only get to record fireworks one or two times per year, so I still do not have this worked out.

Processing Related:

Lastly, the "Git2" and "Git2P" do not record true "UHD". The closest format in video modes are anamorphic 16:9 format 2880 x 2160 at 24 fps for "normal" video (not time lapse) and the same frame format in a 30 fps file for time lapse. There is also a 2880 x 2160 4:3 screen format mode also at 24 fps, which is what I use for fireworks.

When I process the anamorphic video files I stretch them to 3840 wide. There is no further "loss" of sharpness or detail at this point beyond what is normal in any image recoding, but since the detail was not recorded in the first place, the resulting video is a bit less sharp and less detailed than it would be if proper 3840 wide video were originally recorded.
[2019-01-24 partly re-written for clarity]

This is a firmware limit and not a hardware limit. If you think about it, the reason for the 2880 anamorphic format at 24 fps is obviously because the processor has hit its limit at that frame rate, and it cannot even get that much done within 30 fps. However, for time lapse, this, and other similar cameras are not recording faster than 1/2 sec. per frame. Couldn't the processor handle a full width 3840 screen width within this much time? Actually, the SJCAM M20 camcorder uses the exact same sensor and chipset and when it is used in its equivalent time-lapse mode it does indeed process full 3840 pixel width screens. The only reason that the "Git2" does not is GitUp's camera design choice. Unfortunately, the SJCAM M20 has much more limited firmware in other ways, and so, I prefer my "Git2" and the newer "Git2P".
[2019-01-24 partly re-written for clarity]

The "Git2" and "Git2P" also support "time-lapse" by still photography. Using this method the full 16MP still picture capability can be used, and frame are stored JPEGs. RAW is also available, but I think it needs a frame rate of 1 fps or slower. This has not been tested, but I know that the RAW storage time seemed long. Such a time-lapse requires you to supply your own frame assembling software. Most video editing programs should include this capability. Full "UHD" resolution will depend on your software, but is fairly common.


Conclusion:

As I wrote above, I do not recommend viewing this video in "UHD". It's pretty good, but not really wonderful. At best it probably exceeds 1440P, so that is probably the best resolution for viewing. For the record, I do not view YouTube videos at higher than 1080P. I feel that the cost is extravagant and on my computers and devices I get nothing out of higher resolutions anyway. In fact, on YouTube, I usually watch in 360P and 480P, and occasionally in 720P. The main reason I record in resolutions higher than 1080P is to support special projects. I can produce 30 fps "UHD" videos in my current equipment using the YiM1. The Action Cameras I have were my first step into "UHD" support, and they have done well enough for now. I am simply not in a hurry to go into it further.

 

[VidThreeNorth]

Action Cameras with Fish-eye Lenses

I will not go into detail about "action cameras" with 170 degree fish-eye lenses. There are sample time-lapse videos uploaded by various GoPro cameras and many others in standard fish-eye views. I have three fish-eye cameras that support "image straightening" (aka "distortion correction"). In the order I bought them they are Garmin Virb, SJCAM M20 and the GoPro Hero4 Silver. None of the "distortion correction" functions that I have seen work perfectly, but some do a fairly good job of straightening. In that regard, my SJCAM M20 looks similar to my Git2 (4.35mm). I have not made a formal comparison, but there is a similar barrel distortion curvature in both cameras.
[2019-01-24 partly re-written for clarity]

The problem with the M20 and the other cameras with this function, is that there is a general lack of controls that the Git2 has. In particular, when using the "distortion correction" none of them have any choice of the angle of view. The GoPro Hero4 claims that the image magnification is similar to their "medium" view. The other two cameras look similar. I have never tried to make an accurate measurement of any of the cameras. In fact, I have only tried the function a couple of times on the Garmin and once on the SJCAM M20. Out of the box, my Git2 had 2 field of view settings "Narrow" and "Wide", and each could be modified by using digital "image stabilization" which resulted in narrower views. My recent firmware upgrade replaces this pair of views with a digital "Zoom" setting (1x, 1.2x, 1.6x, 2.2x, 2.8x). Image stabilization is also still switchable and probably changes these view angles as well.

The extensive controls on the Git2 camera and proven "good" results on my earliest tests that stopped most of my further testing of the other three cameras. From what I have seen, none of the other three cameras can do a better job for a rectilinear view time lapse than the Git2.

There are probably a few videos using the image straightening functions that are available on some of these cameras. I do not think you will have a problem finding examples.

I will upload a couple of frame captures from my test of my M20. However, I must warn you that my M20 is modified. I took the time to re-focus the lens which comes from the factory focused too close for general use. It appears SJCAM felt that setting the sharpening high would make up for that, but I felt that the result was too soft from about 10' onward. With my re-focused lens, the over-sharpening becomes even more apparent, and as previously noted, there is no adjustment for it.
[2019-01-24 partly re-written for clarity]

The GoPro Hero4 Silver is my only other "action camera" which has user adjustable sharpening (same "high", "medium", "low" choice as my Git2).

That brings me to my next issue: These other "Action Cameras" could be modified by replacing the lenses with rectilinear lenses as well, and this is well documented. The GoPros in particular have higher resolution display screens and better construction, making them slightly better to work with than my Git2. However, there is some danger in modifying cameras. When I was working on my SJCAM M20 (re-focus), I made 2 adjustments without problems, but on my third attempt, I damaged my camera's case. It still works, but the chance was always there that I might slip up, and eventually I did.


Lastly, there are some pre-modified cameras that you can buy "off the shelf" with good rectilinear lenses. The only drawback there is that getting pre-modified equipment is expensive -- search for "Back-bone" cameras. NOTE: These modified camera are often focus-able.

Back-bone: GoPro, Sony RX0 & Yi 4K/4K+ Lens Mods | BACK-BONE

Ragecams: HD Wearable Video Custom Mods By RageCams
[2019-01-24 Spelling corrected and links added.]

"01-M20-UHD-18h03m20s157-2560-C1.jpg"
A frame grab from an SJCAM M20 "UHD" time-lapse file resized to 2560 wide. The ground is an artificially flattened surface, so the curvature is mainly the result of the imperfect correction for the fish-eye lens.
[2019-01-08 21:45]
I should have mentioned that this sample frame was from an attempt at a sunset time-lapse. The weather forecast said there was a chance that the cloud cover would break before sunset, but it didn't, so I was left with a time-lapse of clouds. This capture would have shown the sun, if the clouds had co-operated. It was the only attempt I made for a time-lapse on that camera.

"01-M20-UHD-18h03m20s157-Crop01-C1.jpg"
This detail crop from the same frame starts at the far left end, though not in a corner. There was nothing worth seeing in the corners. But the result is indicative to the quality resulting from a fisheye lens "corrected" by software and then used in a UHD video. Over-sharpening is strong and not adjustable on this particular camera. The lens is not focused at infinity, but is much better than it was out of the factory. This was my own hardware modification.

 

[VidThreeNorth]

Olympus OM-D Time-Lapse

In the first generation OM-D cameras, according to DP Review, the E-M5 did not have time-lapse, the E-M1 had time-lapse, but DP Review did not give any description. The E-M10 had time-lapse and it was reported as:

"Yes (Interval Time 1 sec. - 24 Hours, Max 999 frames. Available on making Time-lapse movie automatically)"

Since the first generation E-M5 did not have time-lapse I specifically checked the 2015 released 2nd generation ("E-M5 II") and DP Review reports that it does. So, unless there is an error in the reports, probably the only model that does not support time=lapse was the first generation E-M5. The E-M5 is also limited to a maximum of 99 sequentially captured frames using its interval timer, which further limits it very short use.

Reading the review of the E-M1, DP Review specifically mentions a limit of 999 maximum still images captured and the ability to create a maximum 100 sec. video clip at a mandatory 10 fps. That article also points out that the Panasonic G cameras support time-lapse and specifically support a wider variety of frame rates compared to the E-M1. So if time-lapse is desired, maybe a Panasonic G could get it done.

Trying Time Lapse on the E-M10

You will notice that I say "trying". I would not call my attempts successful -- just "almost".

The Output Files:

First, about the time-lapse output file of the E-M10: The compression is MJPEG. It is limited to 1280 x 720p @ 10 fps. It does not matter what aspect ratio is chosen (which is determined by the Still Picture format). If the format does not fit the 16:9 ratio, then the frame is "letter boxed" with black left and right sides. That means that if you chose 4:3 format, then you get the least actual image and the most black borders. If you chose 3:2, then it is closer to the full frame width. The only format that fills the frame is 16:9.

There is a fallacy I have heard that some people think that MJPEG retains more image information than H.264. If the bitrate in H.264 is high, it retains about the same data information, and still works out smaller than MJPEG. What people saying this don't seem to understand is that MJPEG is a LOSSY format, the same way that H.264 is. The difference is that H.264 uses a more sophisticated set of calculations. In this particular case, the Olympus MJPEG file does have one nice advantage over the more common H.264 varieties. It is using YUV 4:2:2 chroma subsampling instead of YUV 4:2:0. But again, this is a specific choice of this implementation has nothing to do with MJPEG v. H.264. You can find H.264 with YUV 4:2:2. It is just not very common.

Camera Handling:

This turned out to be an unexpected drawback of the E-M10. I will note that I have not used any of the other OM-D series cameras, so there is a chance that they might be better.

For my best attempt at this, I was trying to record the clouds in an overcast sky, with the bottom 1/3 of the image showing the ground. I wanted to focus on a structure in the distance -- not on the clouds. One of the first things I did was to turn off autofocus. I turned off autofocus for both Stills and Movie in the menu. I set the time-lapse adjustments as best as I could (999 frames, and create the output movie). I then set the zoom (Yi Technology 12 - 40 mm lens) and focus. I noticed that the spot autofocus box was showing, but at first I didn't think it would matter. I was ready to start. As I was adjusting the tilt of the tripod head, I accidentally touched the screen. The zoom lens re-focussed -- probably on the clouds. I tried using the touch focus to re-focus on the ground, but it didn't move.

I fought with this issue for a while and gave up and started the capture. The resulting time-lapse clip mainly looks at I expected, except that every now and then an out-of-focus frame shows up. The autofocus was active throughout, and failing occasionally. This is what I would have expected from autofocus on the clouds -- which is why I bothered to TURN OFF autofocus right from the start.

There may be a way to get this to work properly. In fact, I expect that with more experience I could figure it out. But to what purpose? Seriously, a 100 second low quality time-lapse file? I might eventually get around to it just to satisfy my curiosity, but it hardly seems worth the effort -- especially not when I have a pretty good camera for time-lapse in the Git2.

Even if I use the still images (which are recorded anyway), why would I want such a short time-lapse?

A Justification -- of Sorts

I can understand the reluctance of Olympus for providing a better time-lapse capability. Each frame is made with the use of the mechanical shutter. Doing really long time-lapse takes a lot shutter activations. It is easy to overlook the fact that mechanical shutters wear out. Most still photographers don't make much of a dent in the estimated life of a camera shutter, but a good time-lapse could take x100,000 shutter activations. I leave my Git2 running at a 1 sec frame rate for about 12 hours at a time, over night and into the afternoon. I create 5 min clips, and delete what I don't need.

But that raises the question, why not just by-pass the mechanical shutter? Mechanical shutters are mainly for subject matter with a lot of motion. Time-lapse is not generally going to be used for that kind of subject matter. So why not just use the camera's "video" capabilities as a basis for time-lapse functions?

[20:05 -- Later addition]
Another problem I ran into was that the E-M10 cannot be powered through the USB cable. Then again, with the 999 frame limit, that should be enough, but that is how I run the Git2 over-night. It is powered through the USB socket.

[2018-12-31 21:48]
I have spent many hours over the last few days reading the manual and going over the camera. I think I could get the time-lapse done with the same lens as before, but I decided to try a different approach. I decided to use an adapted lens which can only be used manually. On the one hand, I did get a reasonably successful time-lapse done, but I found a different problem. I have not been able to get the screen magnification "focus assist" to work with this manual lens (Minolta 28mm F2.8 MD). In fact, I do not think that it is possible to get the screen magnifier to work for this lens.

Anyway, I feel I have put too much time into this effort on this equipment, so I am moving on. It is possible that I could get things working better, but as I said before, I have no real incentive to put more effort into this approach. I already have at least one approach that gives clearly better results.

 

[VidThreeNorth]

I've posted information about the Yi-M1 as a Time-Lapse camera at:

Yi Technology -- Yi-M1

It turns out to be a pretty good camera for this use, but with some important limits. It cannot run off external power, which limits it to the battery charge, and contrast is not really controllable.

 

[VidThreeNorth]

Sony "alphas" including my "a5000" and some recent news about the a6400 and others

When I started this topic, I had my comment about my Sony a5000 basically written in my head. But on Jan 15, 2019, changed the situation giving me a bit more to say about it.

Before Jan. 15, none of the "a Series" cameras had any time-lapse capabilities built in. The function was supported by a downloadable app that was bought for a small cost. I think it was around $10 US. I never minded the price and I am generally comfortable with downloading apps for my Android based devices. I think the overall idea is great. I really like the idea. What I objected to was that Sony took the opportunity to REQUIRE an end user to supply a lot of personal information in order to open an account. What makes this requirement abhorrent at this point is that Sony's security has been breached at least twice now with large known data theft. The data theft was proven when the data was made available for sale by the culprits, and samples of the data proved the validity of the claims.

You'd think that after the second breach that Sony would realize that crooks had more to gain by stealing the data than Sony did by keeping it for "their own purposes." Moreover, I have seen no great benefit to customers for the providing of this data. And that would tend to indicate that even Sony doesn't really benefit much from having it. So why collect it at all? The collecting of data seems to be like a drug addiction that companies like Sony can't lose. Eventually we might need laws banning the collecting of unnecessary personal data of customers. That is a distasteful idea at best. My message for Sony is this regard is simple: "Just stop it. . . ."


On Jan. 15, we had announcements of the new Sony a6400 body, and coming firmware updates for the a9, a7riii and the a7iii. The Sony a6400 will come with time-lapse support (similar to what I have on the YiM1) and the coming firmware update will include similar time-lapse support for the above named cameras.

The other downloadable apps for the various Sony cameras will still need you to open an account, and there is no sign that they will stop REQUIRING you to divulge personal data to open that account. If you are comfortable with that, then fine. I'm not.

There are still OTHER WAYS to do time-lapse with the Sony "a Series" bodies, and later I might mention some. They require external controllers that trigger the camera in the usual way.

While I'm on the topic of the a6400 body, the announcement also provided MTBF information for the mechanical shutter. According to the DP Review report "[The a6400] is also built with a tough magnesium alloy design and has an extremely durable shutter that is rated for approximately 200,000 cycles." As I have written before, realistically, time-lapse is too hard on a mechanical shutter.

The files that I create tend to cover around 11.5 hours per "project". If I round that up to 12 hours (which occasionally is what I actually record), at 1 frame = 1 sec.:

1 hour = 3,600 cycles
12x = 43,200 cycles.

So if I use the mechanical shutter, I could expect an a6400 to fail in less than 4.6 recordings -- which might be as little as a week. It appears that the Sony a6400 might have better controls when using their equivalent to the Git2 "video-lapse" function and at the least, it will be able to get around the YiM1 power problems that I have run into. So it sounds like this might be one of the best cameras available for this type of task, and the full-frame alphas likewise when they get these capabilities in their respective firmware.
[2019-01-17 I should state clearly that the Yi-M1 uses its mechanical shutter if I use it to make time-lapse stills to turn into a video later, but when it creates the video internally, it does not use the mechanical shutter. At this point I do not know if the a6400 creates its video internally using its mechanical shutter or not.]

I don't know how the upper line Canons and Nikons cover time-lapse, and I doubt if will be looking into them, but it would not surprise me if some current bodies can match this, or will eventually with similar firmware upgrades.

[2019-01-30 11:32]
One thing that I have done is to use the Sony a5000 as a "reference" camera in order to find out what are the Git2 magnification settings relative to 35mm camera lenses. The following is one of my test pictures taken with the Sony 18 - 55mm SAM lens via the LA-EA3 lens adapter. Post processing was done using Corel PaintShop Pro X9.

DSC00944 -1c-rsz2400-C1.jpg

Partial EXIF:
From ARW
Date and time December 18, 2018 07:59:50
Image width 5504
Image height 3656
Components per pixel 1
Planar configuration Chunky
Pixel height 3632
Pixel width 5456
Color space sRGB [ARAW ?]
Exposure program Normal program
Exposure mode Auto bracket
Exposure bias 0.70 ev
Brightness 6.79
Exposure time 1/160 sec.
F number f/6.3
Max aperture f/3.5
Focal length 20.0 mm
Focal length in 35mm 30 mm
ISO speed 100
Metering mode Center weighted average
White balance Auto

As you can see, this image, which is equivalent to a 30mm lens on a 35mm camera is very close to the view on my "baseline" time-lapse. I estimate that something around a 35mm focal length on a 35mm camera would be about right. Likewise, I think that the 1.6x magnification on the later Git2 firmware is roughly the view of a 35mm focal length on a 35mm camera.