Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

EXT/ToD Timecode And/Or Still Camera Mode

Kyle Mallory

Well-known member
Joined
Jan 18, 2007
Messages
620
Reaction score
0
Points
0
Age
54
Location
Salt Lake City
Website
www.ifastudios.com
I am working on a project that is shooting time-lapse at 1/2 second intervals, from a helicopter, and time-synced with a GPS clock. The intent is to match individual frames to specific GPS coordinates by time.

In processing footage to individual tiffs, using RedCine-X, the timecode at burn-in is basically the start time + ( frame count mod time-base ). Ie, if the first frame is 14:10:15.00, the next 10 frames (5 seconds) results in an ending timecode of 14:10:15.10. Same "second" + 10-frames. If the first frame is 14:10:15.20, the ending TC would be 14:10:16.06.

I was hopeful that this would have been "14:10:20.01", taking the current EXT time at the time the frame was recorded. Currently we are syncing the clocks by hand (+/- 1sec) (good enough for them), and using the REDs internal clock.

I'm wondering if anyone has any thoughts toward a solution for this. I suspect part of the issue is the base framerate for the project. Realise that the client has no interest in 24p footage, just high-resolution images, at very regular intervals, for hours-on-end, matched to GPS coordinates.

Any input from RED would be welcome.
 
Timecode in the camera would be counting up incrementally also.
Not sure if there's a way to do what you're asking. At least not currently.
 
Hi Kyle,

Timecode doesn't really work that way and was never designed to do this sort of thing. What you are looking for is an accurate timestamp which is currently not available. There will be ways to do something like this in the future, but not Today, unfortunately.

However, since you know the exact frequency (half a second) and the start time you can easily calculate a timestamp for each frame. Basically this is what you would do:

1) extract hour, minute & second from TC (or start time metadata if using the internal clock) and convert to milliseconds

2) add frame_number * 500 to the previous calculation

3) convert back in to hour / minute / second or fractional seconds etc. (or whatever other form makes most sense for such an application)

I'm assuming the timecode format is not really useful for your application (what would go in the frame field?). Milliseconds or fractional seconds would probably be better?

Let me know if you need any assistance with the above.
 
Thanks Rob & Deanan. Yeah, I was considering doing manual calculations, but these guys are image/GIS folks, and are using RedCine-X for extraction. I offered to do some no-charge development for them to extract frames, based on time, but they want to stick to the "standard tools." Fair enough.

Deanan, I'd asked you about GPS sync solutions before, and you referred me to the Clockit stuff (which they decided weren't necessary). Would having an external clock make any difference? Will each frame hold the TC from the master clock, or does the camera again, only sync the time on the first frame, and then each subsequent frame is given an "incremented" TC?

I would like to make the case that if they consider using the Clockit GPS master clock module, that it would solve two of their problems...

I failed to suggest this in the original post (but was thinking about it, given the subject), but it would be great if there was a "Still" mode in the Project Settings that would accommodate these kinds of scenarios. Basically it would take the current time for each frame, and not specify a "playback framerate", but in RedCine-X when doing an export you could still force a new frame rate. I was surprised when I got a "Media too slow" message when shooting at 2 fps and RC42, 4k, to SSDs. It makes sense that the camera might not able able to playback at those settings, but a "Stills" mode could make these options valid, with a limitation that playback on camera wouldn't be possible, or would be at an unpredictable frame rate.
 
Hi Kyle,

It takes the start timecode and counts from there. Timecode needs to be continuos. This is why what you're asking for is a timestamp instead of timecode.

Could you send me an email (rob at red) on this Kyle?

Thanks,
 
Back
Top