American DITs... ugghhh

[Marc Wielage]

My feelings may also be driven by the realization that I can be a bit of a perfectionist, and yet I believe that the perfect is the enemy of the good, and I am wary of being given a tool that encourages overly fine-tuning things because it may be like candy to a baby or a bone to a dog, too tempting to resist and thus slowing the creative energy down that a set needs to keep moving forward.

That's always been my argument as well -- that the danger of having on-set color-correction is that it could slow down the DP from getting through the day. I think there's a happy medium where a minute per scene could at least help the DIT establish the overall mood, but anything beyond that is just wasting time, as far as I'm concerned. To me, getting a "best light" that the editors can work with and the director can use in terms of performance is all that's necessary. Everybody knows at this point that you can spend another 100+ hours in final color to tweak the image to the Nth degree; if you do it on set, you'll wind up adjusting a lot of shots that will most likely never wind up in the show.

I mean, what am I looking at when I decide that this magenta has too much chroma? How do I know it's not the monitor? How do I know how that decision I make looking at a monitor on set matches the monitor at the post house? I have to assume that at best, all I can see on a set is an approximation and that going beyond a certain level of fine image adjustment is just wasting my time. This is why shooting raw or log is so important to me, I like knowing that I will have more information later to play with than what I see on the set.

This comment should be engraved on a gold plaque and stuck at the top of every page in this thread.

 

[Mark L. Pederson]

Re: M Most/Mark Pederson - Metadata in camera.

I am going to with Most on this one (I think? Maybe I misunderstand your position). I don't think the camera is the place to store this data. All I want off of the camera is a Global Unique ID for the clip. Why? Because you might pull the mag after a shot and then that data is lost to the ether and inaccessible. If it's on the mag it might change before someone reads it again and then it's almost worse than non-existent... it's wrong or conflicting.

This data belongs in the cloud. You might be offline and storing this on a tablet or laptop during filming but it needs to be in a database that can be uploaded to a single master database. All of the meta-data should then be re targeted to the clip info based on GUID. Then if you receive an H264 of a clip and the metadata is stripped your workflow isn't dead in the water, you simply scan the filename for the clip GUID and JOIN the data from the database. Databases, real databases not BS sidecar files, can easily track changes, they can be interacted with by thousands of artists simultaneously, they have transaction control so that you don't corrupt entries, they can be mirrored and sharded. You can write applications that interact with this data from around the world. You can also expand the data and customize it well beyond what any camera company like RED could imagine.

The camera should certainly be able to load CDLs and LUTs and monitor that out on set. It should even probably track/store what monitoring LUT was applied. But the only thing that should be stored in-camera is what the camera directly had to process. If you want extensive meta-data sync'ed to the clip then it's best that the camera pulls that metadata when possible. If for instance your camera has a fancy slate feature that tail slates every clip with meta-data in the DNxHD proxy then it should attempt to contact the on-set database for that information. It shouldn't *be* the database. Oracle, MySQL, Microsoft and Postgre etc have refined the science of storing metadata. I don't want a MongoDB server running on my Epic, and to properly store and track metadata that's the sort of system you need.

I think we are straying way off topic here - but a few comments in response to your post -

My comments were on the subject of adjusting RAW color controls directly to the camera. As you know, in the case of RED, every R3D clip contains all of that information in the actual R3D file. The meta-data that you can extract from the R3D after offloading the media (and hopefully soon - the camera itself via wifi without off-loading the media) can oviously be placed in a database.

And yes, the BEST way to do this is a "set server" running a NoSQL database (the "cloud" on the set) that syncs to a remote server (the "cloud" in the sky). And that database can collect and organize meta data from all kinds of devices and hardware and software - QTake, MOCO rigs, script supervisor apps, logging apps, playback review apps, audios files, etc.) - but there is a TON of value IMO to image/color/RAW processing related meta-data settings to be embedded in the actual RAW file the way they currently are on RED cameras. And for the record, there are some real advantages to what you refer to as "BS sidecar files" when working moving media related meta-data from devices to a database - it just depends on how the sidecar is generated. After all ... a CDL is a ... "BS sidecar file"

You are preaching to the choir with respect to all production meta-data being collected and leveraged from a database - I'm just evangelizing the (hopefully) soon-to-be-a-reality process/ability to make non-destructive color adjustments with full control over RAW functions as easy as "just change the color temp on the camera" - and the possibility of getting the full meta-data OUT of the camera live after each clip is shot over wifi - without pulling the mag - is significant to my vision of the future.

 

[Blair S. Paulsen]

Mo meta is mo bettah

Mo meta is mo bettah

Yes, a proper database is a great way to manage entire projects including media assets and with proper GUID support I can see how elements could be effectively referenced via the cloud.

Just because that is true, does it mean I can't have lots of valuable information in the sidecar file? For some shows I just want to be able to populate a few metadata fields to facilitate asset management - and having that metadata travel with the media files means it's easy to find and cross reference.

Exactly how each project manages color is a sub-set of that and, as Mark notes, new tools are expanding options for when and where color notes/settings happen. FWIW I absolutely agree that without a calibrated monitor in a decent viewing environment one needs to be realistic about what can be accomplished. Have I ever told you about my Sprinter based Road Grader Van... ;-)

Cheers - #19

 

[Gavin Greenwalt]

And yes, the BEST way to do this is a "set server" running a NoSQL database (the "cloud" on the set) that syncs to a remote server (the "cloud" in the sky). And that database can collect and organize meta data from all kinds of devices and hardware and software - QTake, MOCO rigs, script supervisor apps, logging apps, playback review apps, audios files, etc.) - but there is a TON of value IMO to image/color/RAW processing related meta-data settings to be embedded in the actual RAW file the way they currently are on RED cameras. And for the record, there are some real advantages to what you refer to as "BS sidecar files" when working moving media related meta-data from devices to a database - it just depends on how the sidecar is generated. After all ... a CDL is a ... "BS sidecar file"

Ok, I did misunderstand then. I thought you were advocating take names, scene descriptions, script notes etc in the file. And I was a little bit too hard on the poor sidecar, I would much rather an XML sidecar to embedding it in a proprietary format like R3D.

I think we can all agree too that pulling clips off of a camera over wifi without having to pull the mag is becoming a near necessity now. I would love to be able to load up the last take in Nuke on set without having to wait for the DIT to offload, checksum and then copy to a thumbdrive. I have been waiting a long time now for RED to enable that functionality over the Gig-E port... presumably that's why there is a gigE port on the Epic. Not sure what's been holding that up.