Timing data and other considerations

[Jack James]

I may be missing something, but it seems the timing data is too limited. I can see "tk roll", and "tk timecode", and "Tk FPS", but that's not enough. It could also be drop-frame, and it could use an NTSC timebase, meaning it will run at a slightly different speed than the timebase indicates, such as having a reported FPS of 30, but is actually 29.97. Also, there's nothing to indicate the overall duration of the take?

Regardless, encoding the timing data as a timecode only seems to me to be a mistake. It would be more accurate to have a start frame number and end frame number, from which the timecode can be calculated based on the fps, and this might avoid a whole host of problems down the line, as well as allowing for capture devices that do not support timecode. A timecode field could still be included just for reference's sake.

I also think there could be a larger issue here, which is that you seem to be assuming the base element is a take or "single clip", when you should probably be allowing for data to be recorded per track, per clip, per take. This would allow for (amongst other things) left/right stereo-3d data, and audio information to be recorded independently:

- take 1, camera A, clip 1, track 1, video, left eye, start, end, etc

- take 1, camera A, clip 1, track 2, video, right eye, start, end, etc

- take 1, camera A, clip 1, track 3, audio, channel 1, start, end, etc

- take 1, camera A, clip 1, track 4, audio, channel 2, start, end, etc

etc

HTH

[Sam Richards]

The original goal is replacing the paper, or filemaker databases, so we are not typically assuming that somebody would manually be entering the data at the granularity that you mention. We are assuming there would be additional metadata that ideally actually tracks the actual media (e.g. file-headers) that would really be the main source of some of the information you are talking about.

For frame numbers, as somebody entering information into the camera report, you wouldnt have access to that unless the database remapped it, and even then wouldnt it be safer to simply enter it as is, rather than attempt to remap it based on a potentially incorrect FPS?

As for the grouping of elements, we are typically assuming that each take is per camera, and that it would encompass everything to do with Camera A, Take 1. So that would include audio, left eye, right eye, etc. I think I know what you are talking about... the need for a higher level data tracking database, that is grouping all the media together. I believe there are systems out there that are doing that (like the codex box), but that is not what we are trying to do here. Instead we are trying to provide a data source for a VFX data-wrangler to enter additional information into a on-set database, that would then be imported into the larger system like codex, or 5th kind to be merged with the other data sources.

Does that make sense?

Sam.

 

--
You received this message because you are subscribed to the Google Groups "ves-tech-camera-reports" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ves-tech-camera-r...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jack James]

Ok sure, I'll concede the point about frames vs timecodes if as you say, the goal here is manual entry (which I did not fully appreciate). The problem then as I see it, is that this is then only one piece of the puzzle, sure it's got all the data the vfx editor needs, but then you can't necessarily reconcile it with data from other sources, such as raw camera data, or things that the editor has access to, this data is effectively "siloed" for the vfx department. Maybe that's fine; I'd personally like to see a real move towards a single data source, so that all information about a given take is available, from the location notes through to the camera metadata. For this to work within the model you've proposed, there needs to be something to uniquely identify each row of the csv file (and that has relevance to non-vfx departments), maybe that's a combination of the camera, shot and take number, but those can be rather unreliable in practice. What if there's a mis-slate, etc.

Jack

--
You received this message because you are subscribed to a topic in the Google Groups "ves-tech-camera-reports" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ves-tech-camera-reports/D0dwa2Z02TU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ves-tech-camera-r...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jack James, Surreal Road Limited

www.surrealroad.com