Why RED should kill .RSX

[Gene Crucean]

red team: Thoughts?

 

[Mark L. Pederson]

I've been brooding over this the past few days. So much so, I've started drafting a web page of the XML spec I would use from prep to delivery - some random notes and ideas - I'll link that page (maybe later tonight) when I flush it out a bit more.

I posted earlier in this thread that the camera should write the XML on format. I was wrong, because that is on the digital mag level. I want the XML to be on the clip level, inside the RDC.

Here's what I would do:

A check-box in the menu to "write XML". If you check the box, during the POST process that happens when you stop shooting - the camera writes the <clip name>.XML file inside the .RDC - with ALL THE META-DATA FROM THE CAMERA - in a category called something like <camera_data>.

Yes, I know it's redundant - that all this data is in the header - but there are some distinct advantages of having the camera create an XML with the clip name and copy this meta-data into an XML for you after each take, inside the RDC folder. I am sure we are talking about a fraction of a second to write the file.

#1: The meta-data is more accessible. Anyone can open the XML in any text editor and see frame size, timecode, etc. etc. - without accessing redline, REDcsv, or any RED application. You would be effectively REDcsv-ing as you shoot.

#2: Collecting and/or building a data-base from numerous clips would be lightning fast - as you don't have to look inside the R3D file header - you are just parsing text from XML files. FAST!

#3: Stupid easy for any third party app to look at data from the R3Ds.

#4: The XML file would be there. Waiting for anyone to add information.

#5: Now any RED app that you can change the color values/look - would write those values into this file.

You would have a reference of color values for how the clip was shot AND color/look changes made in a RED app - in one, easy to access place - that travels with the clip.

 

[Kyle Mallory]

Mark,

Any follow-up on this? I'm behind you 100%, and have been debating and struggling with similar issues in implementing some kind of 'RSX' support for Piranha. Do you think there is any benefit in moving ahead with something, and working with RED along the way to see that when it gets implemented in camera, that it does so correctly?

Ie, can we (you, me, and others) agree on a spec, and write a few simple tools to generate the XML outside of the camera, write our post tools to support that XML, and move forward with our needs, and at the same time, keep in touch with Rob/Deanan/Stuart/etc, to see that at some point it actually gets added to the camera?

I think if we could minimize the impact of code changes (and dependancies) on the camera specifically, we'd have a better shot moving this forward. Ie, can we structure the camera-generated XML so that it is the absolute simplest XML document possible, with the fewest number of elements possible? I don't think the guys working on the camera firmware want to start adding dependencies, like full-fledged XML DOM parsers and crap, into the code. Otherwise, my gut tells me we won't get anywhere until Epic/Scarlet are released.

It would be trivial to make a tool that generated the XML after-the-fact, by reading the meta from the R3D. The trick is getting the camera to read that XML.

It might even be worth exploring with RED what formats other than XML would be acceptable alternatives, such as strongly-types plain text, but that still gave room for extensibility.

 

[Kyle Mallory]

#2: Collecting and/or building a data-base from numerous clips would be lightning fast - as you don't have to look inside the R3D file header - you are just parsing text from XML files. FAST!

As a point of contention, reading meta from the R3D file is likely faster than using a XML/DOM parser, assuming you have the right tools/understanding of the file structure. I have no idea how the inner-workings of the SDK work, but my guess is that opening a clip and querying metadata from it is extremely light weight, especially for the first frame. Regardless, you're other points regarding accessibility of that information are entirely dead-on.

On a subsequent note, aside from the overhead of opening/closing files, is there any value in allowing the RDC folder to be the container for all this meta-data in the sense that stuff like annotations and custom meta-data be stored separate from any other metadata file? Ie, reddata.xml as a replacement for RSX, but perhaps an "annotations.xml" for all of the various annotations that are made about a file? This would reduce the chances of data in reddata.xml becoming corrupt do to a 3rd-party application that didn't play nice while updating the notes made about a clip, or frame.

Just some thoughts.

 

[Joshua Brown]

I'm quite surprised this hasn't been implemented yet. Please do it soon.
I originally thought this was going to be the purpose of the r3d file.
-J.A.Brown

 

[Mark L. Pederson]

On a subsequent note, aside from the overhead of opening/closing files, is there any value in allowing the RDC folder to be the container for all this meta-data in the sense that stuff like annotations and custom meta-data be stored separate from any other metadata file? Ie, reddata.xml as a replacement for RSX, but perhaps an "annotations.xml" for all of the various annotations that are made about a file? This would reduce the chances of data in reddata.xml becoming corrupt do to a 3rd-party application that didn't play nice while updating the notes made about a clip, or frame.

Just some thoughts.

Because we all treat the RDC as "the clip". We move this folder around. Copy it, etc. It moves through the pipeline. Clip data should move with the clip.

The meta-data from the camera is in the header. It's not going to get corrupted if you are writing to a side-car file.

 

[Mark L. Pederson]

It would be trivial to make a tool that generated the XML after-the-fact, by reading the meta from the R3D. The trick is getting the camera to read that XML.

I don't want or need the camera to read any XML.

I'm interested in ADDING information to the clip - and tracking LOOK settings.

And yes, I agree one could wrote a script to read the filename and meta-data and write an XML into the RDC - and that's exactly what I will do if Red doesn't implement this in EPIC. But it's a hell of a lot more elegant for the camera to do it - it's got that meta-data live - it just writes on POST. The RED ONE use to write a LOG file on POST.

 

[Kyle Mallory]

I don't want or need the camera to read any XML.

I must have misunderstood this:

I want to be able to create a LUT in any RED software app - that can be loaded INTO THE CAMERA.

The meta-data from the camera is in the header. It's not going to get corrupted if you are writing to a side-car file.

Based on all of your posts, it sounds like you want your "side-car" xml file to carry potentially a lot of information. Additionally, you want an "open standard" so many different applications can access and modify that information.

The more applications that access and modify a single resource, the higher the probability is that one of those application will corrupt that resource. Having a single XML file that contains your LUT, your SCENE, SHOT, TAKE, multiple annotations, and any additional vendor-specific extensions, that can be modified by any number of application increases the chance that you will lose that information. If an application starts writing a new annotation, and crashes, you could potentially lose all of the data. Do you want to risk all that data at the hands of any of a dozen applications in your post pipeline that might touch that data? My suggestion was multiple XML files, all contained in the RDC folder, each one containing different, but relevant information. lut.xml, meta.xml, annotations.xml, etc, etc.

In any case, I'm proposing an idea/initiative/objective to hopefully get us both what we need (and many others as well): To take the lead on developing the standard ourselves, and working with RED to see that it gets implemented as defined by us, in Epic/Scarlet at the minimum, and ideally in the RedOne in an upcoming future firmware release.

If you're not interested, then I'll stop wasting your time... if you are, then let's round up a few other like-minded individuals, put our heads together, and come up with a solution, rather than distracting RED from making the next kick-ass camera.

 

[MichaelP]

Perhaps look to the iXML used by audio hard disk manufacturers as inspiration?

Michael

 

[Gene Crucean]

It might even be worth exploring with RED what formats other than XML would be acceptable alternatives, such as strongly-types plain text, but that still gave room for extensibility.

Eh, not from my pov. It would need to be xml spec or nothing.

 

[Gene Crucean]

Looks like RED and Co won't touch this with a 10ft pole. Bummer.

 

[Mark L. Pederson]

I must have misunderstood this:

What I said was "I want to be able to create a LUT in any RED software app - that can be loaded INTO THE CAMERA."

This is not the same thing as asking the camera to read an XML filled with other meta-data/annotations. So I'm suggesting creating a LOOK file - which is a 1D LUT in some form - in a software application and exporting that file so it can be loaded into the camera. When shooting with the camera and using that LOOK file - those values are written into BOTH the header of the R3D AND the XML side-car file.

Let me say this:

I've been in too many meetings and/or conversations with other companies and software teams when the subject of LUTs come up - there is this response of ... "I'm we go down that road it will be a world of hurt, etc. etc. because there are so many "flavors" of LUTS." Sorry ... I have to call bullshit on that.

FACT: The number one concern I hear over, and over from DPs is the concern and desire to control color and reference looks through the dailies and post finishing pipeline. And regardless of what Mike Most will say ... traditional dailies colorist workflows are going away faster than HI-8.

FACT: TWO of the THREE major NLEs will support LUTS next year. But you didn't hear that from me.

FACT: We use cineCube Visual from Rising Sun Research to create 3D luts at Offhollywood - and this app allows you to export pretty much every flavor of LUT used in the industry. So ... translation tools already exist - if the industry doesn't want to settle on a standard - then maybe it's time for RSR or Stu M. to release a low cost LUT translation app that will read and translate whatever RED settles on and let us all get on with it.

RED needs to get past the RSX as soon as possible - give us a simple standard that is in the SDK - and if they want to make their own - that's cool with me - just let the app write the file the camera can read and make it logical enough for third parties to translate and export to it.

The more applications that access and modify a single resource, the higher the probability is that one of those application will corrupt that resource. Having a single XML file that contains your LUT, your SCENE, SHOT, TAKE, multiple annotations, and any additional vendor-specific extensions, that can be modified by any number of application increases the chance that you will lose that information. If an application starts writing a new annotation, and crashes, you could potentially lose all of the data.

On a CLIP basis - one would copy/clone that media prior to writing to it. Parsing and archiving back-ups of the XML (which could be easily restored) is a very basic, and obvious feature one would implement.

 

[Mark L. Pederson]

Looks like RED and Co won't touch this with a 10ft pole. Bummer.

They got a longer pole ... I'm not giving up yet.

 

[Tai Wah Lim]

They got a longer pole ... I'm not giving up yet.

Mark, just watched Michael Cioni $3 tutorial on onset monitor and production monitor color. He kind of states that the look onset will never be the same when view in production even if the two monitors are calibrated the same. He offers a psychological solution instead of a technical one. Which i tend to agree at the moment. From your scientific mind, are you saying that applying a LUT on set and have that translated to another LUT for production will provide the same look? We will need a translator for different production set then. Is this worth the bother? Lim

 

[Gene Crucean]

They got a longer pole ... I'm not giving up yet.

Woaaaa



From my perspective, RED has the biggest pole lol. Mainly because they are doing to Sony, Panasonic, Arri, Canon, etc. what I've wanted to do for a looooooong time.

But we still need this side car xml. That is... "XML"

 

[Mark L. Pederson]

Mark, just watched Michael Cioni $3 tutorial on onset monitor and production monitor color. He kind of states that the look onset will never be the same when view in production even if the two monitors are calibrated the same. He offers a psychological solution instead of a technical one. Which i tend to agree at the moment. From your scientific mind, are you saying that applying a LUT on set and have that translated to another LUT for production will provide the same look? We will need a translator for different production set then. Is this worth the bother? Lim

Lim - YES it is worth the "bother".

While it is very true that many monitors used in production are not set up an calibrated correctly - this is actually a very silly "excuse" to not manage color though your pipeline - including on set.

I am very much against "on set color correction" in any kind of traditional "paintbox" method -however - I am very much a fan of the DP shooting tests - coming into the post environment - were there is proper color management - and setting looks with the colorist. But we need an efficient way to export these looks to the camera - so they are applied on set, and occasionally altered slightly.

Giving the DP the ability to see on set, a closer representation to how he/she wants his/her film to look like and keeping those looks through dailies is really an obvious need. Is it necessary to make a good film? Of course not. People have made amazing films with shit video taps for a long time. But most also had a dailies colorist working at night, working from notes from the DP, spending countless hours to make the dailies look closer to the DPs vision of the film.

I haven't seen Michael Cioni's video yet - but you can't use a "all monitors on set look different" argument against using viewing LUTs. That is like saying everyone's TV (plasma/LCD/etc.) at home is different - so why bother to color grade a film for DVD or television. Do you NEED to use LOOKS/LUTS? Of course not. But if I were a DP, I'd use them all day long.

And for the record, monitors on every level are improving. At IBC I was blown away by the new 10-bit consumer/prosumer monitors in the JVC booth. You will see BETTER monitors being used in production, set up more accurately. You are not going to stop the technology there. And fact of the matter - you can say "when shooting RED - the monitor is just a sexy video tap" until you are blue in the face (I know I do) and IT JUST DOESN'T MATTER. If there is a monitor on set - people LOOK at it. And they THINK with it. I've watched some major DPs who came up though film ("non-digital" guys) shoot and it amazes me how they can't help themselves but to make decisions off of the monitor. I always joke that they should put a VIEW option on the RED ONE that outputs a crappy black and white image with flicker to simulate an old film tap - and THEN maybe DPs would embrace shooting RAW slightly differently. But that will never happen. You are going to see DPs demand/desire MORE ability to manage color viewing on set efficiently.

 

[Mark L. Pederson]

Woaaaa
But we still need this side car xml. That is... "XML"

Amen brother.

 

[Benjamin Rowland]

Mark, I hope with your influence, we'll see the changes made that you've outlined in this thread. Many thanks for all of your contributions to the RED community.

 

[Tim Whitcomb]

They got a longer pole ... I'm not giving up yet.

I actually think the lack of direct RED response on here is a GOOD SIGN
that they are not only listening, but I am thinking we could see this addressed in the Oct 30 EPIC-X announcement. :wink5: Nothing else makes sense.

This is a very reasonable request. unless we are missing something and they feel this could somehow threaten some of their proprietary technology?

Curious, do any other camera manufactures offer this XML capability? ARRI? Genesis? Sony? Viper? , Silicon Imaging?

thanks Mark. Great idea!

 

[walter.volpatto]

Agree...

A LUT loaded in camera to simulate any output device/film stock and will be carried in post ( actually the post should provide it... )

3D 17x17x17 standards LUTs please....