Timelapse still picture issues

[Jumphog]

I purchased a Gitup 2 with the main intention of using it for timelapse photos after I saw that the 1.5 firmware added a 0.5s delay which is exactly what I need. Unfortunately theres some problems, can anyone suggest any fixes?

* The 0.5s option actually takes about 2s to capture each photo. Ive tried it at 16mp and 3mp - theres no difference. Ive tried setting the iso and white balance to auto but it only makes a very minor difference in the framerate.

* The quick capture stills mode seems a lot better but theres some major issues with it - mainly that it doesnt update the metering between pictures. If you start in a dark area then go to a light area everything is completely blown out and visa versa. Also when in quick capture stills theres LED indication that pictures are being taken and the screen freezes on the first frame.

* A minor point is that if you set the stills timelapse to 0.5s then use quick capture the timelapse value gets set to 'off' again.

I suspect these might need updates to the firmware to fix, but if anyone has any ideas that would be great.

(using GIT2FW_20160621 and a Sandisk ultra 16gb card)

 

[Alistair Parsons]

Have you tried video timelapse instead?

 

[Jumphog]

Thanks for the suggestion - I havent, it might work better for the exposure but I need the 16mp stills. In theory I could split the video into frames but there'll be more compression artifacts and it wont be as high res..

 

[Sattiro]

Are you microsd card ultra hight save?

 

[Alistair Parsons]

Hi, this was discussed in rcgroups thread, even tho it says 0.5s, due to the time taken to write to card, it will always be about 1.5s between frames. the only way to get faster is the quick capture. there was official response from Bill comfirming as well.

 

[Jakob Thrane]

#Sattito: Do you get faster timelapse than 1 frame per 2 secs when you use a fast card?
#Alistair Parsons: Why can it write faster to the card in quick-capture mode? And why did Gitup add the 0,5 sec timelapse option in the firmware if it isn't doable?
I ask because I find it strange and because I really hope that it is just a firmware-glicth that will be solved by Gitup soon.
2 secs between frames really is a problem in fixed wing surveying with the no distortion lenses at around 90 degrees AOV (54 degrees vertical). To get sufficient overlap on tailwind legs, you must fly higher than legal (100 meters in Denmark and many other countries, I believe) or slower than stallspeed for most airframes.

 

[Alistair Parsons]

http://www.rcgroups.com/forums/showthread.php?t=2545523&page=335

no idea why quick capture is faster, was suggested in above forum post
no response as to why its available, very fast cards may helpin other matters but havent inthis case.

even survey cameras like http://www.drones2.com.au/mapir-survey2-camera-visible-light-rgb.html
are just rebranded git2 cameras

 

[Jumphog]

Good to see theres some discussion on this. My guess is that most of the problem is that the process of taking a picture (meter for exposure, capture image, compress, write to card, maybe flush buffers) is not included in the stated delay for timelapse. With the burst mode theres no metering and the camera seems to be in a constant loop taking pictures - when you stop it theres quite a delay for the buffer to empty. It does get a little bit faster if you reduce the resolution or compression but not enough.
If the burst mode could be adjusted to use the last frame taken to adjust the metering for the next it would be fine - dont need to have every frame individually metered. Any chance of the developers adding this in?

Also interesting to note that there might be modified firmwares around, it would be amazing to get hold of the dev kit for the camera SOC. That way one day there could be my perfect camera: recording video at 720p30 with a >8mp still every 0.5s..

 

[Alistair Parsons]

That was it, no metering which is why its quicker, probably some other compromises too, im hoping the Git3 will be better