PDA

View Full Version : Why RED should kill .RSX



Mark L. Pederson
09-23-2009, 07:14 PM
IMO .RSX needs to go away as soon as possible, and be replaced by a "side-car" XML file in the .RDC and here is my case:

Today, we started processing a LARGE job which was shot with multiple Red cameras, on several workstations with RED Rocket cards. PLINY, who heads up the post at Offhollywood, immediately noticed that the meta-data for the media (collected via RedCSV) indicated that all footage was shot in the same color space/gamma space - yet RocketCine-X showed different color space/gamma space settings for the cameras.

We finally figured out that Rocketcine-X defaults to the .RSX - NOT the meta-data. This really reads like a recipe for disaster to me - and it got me all wound up again on an issue that is near and dear to my heart. I want .RSX to go away and I want an XML riding with my R3D. Inside that XML ... I want a LUT.

Another example - I gave a presentation with Dennis Radeke form Adobe on RED Adobe workflows recently. During the Q&A - a gentleman (who it turns out works at DELUXE) asked "does Adobe support .RSX?" The answer was "no". But let's look at the question again -

What he really was asking was ... "is there a RED 'look' file that I can set in a RED software utility that will carry across 3rd party (Adobe) post workflow solutions?"

The answer is ... sadly ... no.

There have been a few mentions from the RED on some threads about standarising a "look" file spec in the SDK - and I know I have personally banged my spoon on my high-chair for a UNIFIED FILE SPEC between camera and RED software utilities for a long time.

When the new color science appeared in Build 20 - I was sure we'd see a "look" file spec that allowed us to move from camera to software - and software to camera. But we continue to move forward with .RSX. Third parties (Clipfinder, etc.) build tools that work with .RSX.

Suddenly ... a "short term" solution becomes "default standard" - and everyone spins around it.

I'll step back a moment and spell out EXACTLY what I want. Because ... I think you want it too. I want RED to kill .RSX. Thanks, we'd have some good times ... but it's over. You need to go. It's not you .. it's me ... whatever ... it's over.

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

I want to be able to READ a LUT from an .R3D file header - and apply that to another shot, etc.


I want a "side-car" .XML file inside the RDC folder.

The camera would write this file on FORMAT.
The camera would write meta-data values into this .XML file during POST process when camera stops record.

Now, we have am .XML file that TRAVELS with the shot. We cab EDIT, ADD, ALTER the .XML file - and never touch the .R3D files.

SCENE, SHOT, TAKE

yeah ... you know ... the MOST IMPORTANT meta-data of narrative film's post pipeline.

We still can't put it anywhere.

If RED would standardized on a "side-car" .XML file inside the .RDC - we could all ADD whatever elements we wanted - in a fully extensible, non-destructive way.

Here is where we'd write SCENE, SHOT, TAKE. Annotate.

Third parties could adapt much faster.

Doors would open to more powerful post workflows.

Greg M
09-23-2009, 07:25 PM
amen brother

Justin O'Neill
09-23-2009, 07:27 PM
I second this.

Jeff Kilgroe
09-23-2009, 07:32 PM
Amen, amen and a halleluja!

We were told long ago that there would be a new look format coming that would work between all the Red tools and SDK... It can't get here soon enough. The XML inside the .RDC makes perfect sense.

RSX support is there in the SDK and FCP now allows for loading RSX files. And some third-party tools too. IMO, this is just a band-aid solution and isn't the robust solution we're all looking for.

mikeburton
09-23-2009, 07:39 PM
Yup! I'll vote for that as well.

Blair S. Paulsen
09-23-2009, 07:50 PM
Hate to pile on, but I have been evangelizing the power of metadata since the early days of the RedOne and thought it would be pretty sophisticated by now. This is a way to producers hearts and editors will buy rounds til last call if you can nail this one.

We know you can do it Red Team!

Cheers - #19

Emery Wells
09-23-2009, 07:58 PM
No need to reinvent the wheel here. You're asking for a 1d LUT. Red alluded this would be coming long ago.

This was also the major thorn in every DITs side because their main function (painting the image on set) was suddenly removed from the equation.

The fact that the first two red software packages saved look files in two different formats (RSX and RCC) hasn't helped matters. Some Red techs create looks in Redcine and walk in with their RCC files and expect we can use them for the transfer but if we arent using Recine or Scratch then that's not an option.

Bring on the LUTs please.

Mark L. Pederson
09-23-2009, 08:00 PM
Bring on the LUTs please.

yes. contained inside an XML. inside the .RDC.

Jean Déraps
09-23-2009, 08:02 PM
This would be a serious boon to the post side of things....

Matt Gottshalk
09-23-2009, 08:02 PM
YES!

Shane Betts
09-23-2009, 08:04 PM
IMO Here is where we'd write SCENE, SHOT, TAKE. Annotate.
...DIRECTORY/CLIP NAME, TIMECODE as well. Logging info that could be turned into bins in FCP or Avid.

Gene Crucean
09-23-2009, 08:15 PM
This would be a serious boon to the post side of things....

You have nooo idea :)

Mark, thanks for posting this and I have your back on this 1000%

Jarred, for what it's worth... this is one of the little things I wanted to implement had our interview/meeting progressed further. I was too busy at the time to take it to the next level, so I apologize.

Mark L. Pederson
09-23-2009, 08:22 PM
...DIRECTORY/CLIP NAME, TIMECODE as well. Logging info that could be turned into bins in FCP or Avid.

how about ANYTHING you want to add ... that's the beauty of XML.

Extensibility.

at any given time - you could ADD whatever field(s), value (s), note(s) you want

and YES - third parties could pull it into bins and project files VERY easily.

Gene Crucean
09-23-2009, 08:24 PM
Oh and I forgot to mention but, xml IS the standard in vfx.

Mark L. Pederson
09-23-2009, 08:26 PM
Oh and I forgot to mention but, xml IS the standard in vfx.

the standard for data exchange PERIOD.

Gene Crucean
09-23-2009, 08:29 PM
the standard for data exchange PERIOD.

Very true

Shawn Nelson
09-23-2009, 08:36 PM
A solid idea Mark, I hope this gets done promptly! XML is really the highway to workflow

Hans von Sonntag
09-24-2009, 12:42 AM
I like the idea about a XML. Good Idea for VFX, MOCO etc. but nothing the average user really needs. Red's metadata possibilities, and the vision to allow a true WYSIWYG workflow with a RAW system which needs a complex information transfer from the camera to the post, is the biggest obstacle people face when working with the Red1. We need to make it easy for the people. I propose 3 modes, selectable in the menu:

1. The video WYSIWYG mode: RedSpace, Fixed 320 ASA, manual WB. RC etc. render to RedSpace.

2. The film mode: RAW-View, fixed 320 (250) ASA, fixed 5000 K. RA, RC etc. render to RedLog.

3. Expert mode: Like we have it now plus a common LUT format and XML

Iridas .Look file is a LUT format that can be read by a camera (SI2K) and read and written by Nuke, SpeedGrade and perhaps others I don't know. I like the idea of a camera LUT that is also a post LUT.

-----

Personally I only use metadata for the clients monitor. I found 250 ASA and 5000K (metadata) pictures the sensor best and hence I transcode all my footage with those values, regardless which app. we use. Using the camera matadata can lead to lost information in the hightlights or unwanted noise. I'm a big fan of the RAW-View - no mistakes possible.

Hans

Kaku Ito
09-24-2009, 05:03 AM
workaround for now.

http://205.234.135.241/forum/showthread.php?t=35226&page=2

Tony Lorentzen
09-24-2009, 05:04 AM
Mark - this is an excellent idea and I'd also love to be able to load project-specific metadata onto the camera from the SD card that would also be embedded into the clips and mags. Would be awesome to have an app that I could use to set up all the camera functions, project settings etc. and then when I get to the set I just load the SD and the camera would automatically set itself up with those settings. Sure would make my life a whole lot easier not having to go through a lot of settings on the camera every morning to make sure it's set up properly.

rick youck
09-24-2009, 07:47 AM
Thanks Mark - that is exactly what i've been hoping for since day one. it is needed, and would help make the set thru to post experience a far more straightforward process.

(fingers crossed)

rick

Mark L. Pederson
09-24-2009, 07:58 AM
workaround for now.

http://205.234.135.241/forum/showthread.php?t=35226&page=2

Kaku - I'm referring to an XML file PER CLIP. Not a timeline/edit XML for conforming. Such XMLs can be made in NLEs - and yes, various workflow tools can translate bwteen apps.

What I am talking about is an XML that travels with the R3D, inside the .RDC folder. The camera writes some meta-data to it - but you could ADD additional meta-data and annotations at any time. This XML would contain a LUT file(s) - that would pass through the post pipeline to be used as reference, or dailies, etc.

Kaku Ito
09-24-2009, 08:01 AM
Mark,

This workaround provide you individual RSX per alias. So, all of the metadata per alias can be created. Sorry my English is not good enough to clearly explain and I'm with you with better metadata handling, but it is the workaround for now.

Chris Parker
09-24-2009, 08:04 AM
hell yeah. this would kick sooooo much ass.

Sanjin Jukic
09-24-2009, 08:08 AM
Hope that RED is listening!!!

Kaku Ito
09-24-2009, 08:15 AM
I'll make it little more clearer.

Say you can have the original R3D folder, then you can create aliases. If you open from the aliases and make adjustments, then new RSX gets created in the alias location instead of the original R3D location.

The new tool Hans is coming out will let you make aliases from XML or from Clipfinder project, then by loading these aliases to ROCKETcine-X, you can have RSX to each cuts. Even the in/out points.

As you already know that Aliases won't take much size, so you can have many groups of aliases to provide sets of different versions.

Mark L. Pederson
09-24-2009, 08:25 AM
I'll make it little more clearer.

Say you can have the original R3D folder, then you can create aliases. If you open from the aliases and make adjustments, then new RSX gets created in the alias location instead of the original R3D location.

The new tool Hans is coming out will let you make aliases from XML or from Clipfinder project, then by loading these aliases to ROCKETcine-X, you can have RSX to each cuts. Even the in/out points.

As you already know that Aliases won't take much size, so you can have many groups of aliases to provide sets of different versions.

all understood Kaku - but it's another workaround based on a non-optimal solution.

I'm pushing for a future-proof, extensible hook for data tied to R3D files.

Kaku Ito
09-24-2009, 08:37 AM
I'm talking based on a special version of Clipfinder I got provided from Hans, so it might not seem to be so effective, but you'll see some value in it when it comes out.

Aside from that Deanan kept mentioning about new ways so we'll see better environment soon I hope. So, all of your input here would be taken I'm sure.

John Fairstein
09-24-2009, 01:22 PM
Yes yes yes! And I hope we can have some input into what goes into the XML sidecar file.

Brent J. Craig
09-24-2009, 01:36 PM
Add my vote. XML files are text that can be edited on pretty much any platform. It would be quite trivial for people to build apps that write custom XML files for different looks.

If it was built from the ground up to be compatible with Adobe XMP (xml) files, clips would open properly colored, cropped, etc in Adobe programs. Is there an industry standard for image-data XML yet?

As modules are released for the new cameras, they could read and write what they need into these same XML files. For example, a VFX module could record pan, tilt, angles, etc; or a slating module could record slate numbers and script notes.

John Fairstein
09-24-2009, 02:19 PM
Is there an industry standard for image-data XML yet?
Adobe offers an open standard "DNG" format for RAW still images. See http://www.adobe.com/products/dng/. This format uses an "XMP" file that is based on XML. Maybe this could be a starter for an open standard Digital Motion Picture XML. See also Adobe's DNG Specification PDF at http://www.adobe.com/products/dng/pdfs/dng_spec_1_3_0_0.pdf

Jonas Rejman
09-24-2009, 03:11 PM
Hell, it's about time !!!

I just would like to add checksums to that xml-wish-list.

JanneJansson
09-24-2009, 03:21 PM
Yes please make the .RSX go away.

Kaku Ito
09-24-2009, 08:57 PM
How is CinemaDNG coming these days?

Gene Crucean
09-24-2009, 10:48 PM
Hell no to anything Adobe. Not only can those guys not implement EXR properly into photoshop, but the programmers personally told the authors of the OpenEXR spec that they were wrong. Along with talking down to the entire VFX community. F Adobe.

I want nothing to do with that kind of mentality

Gavin Greenwalt
09-24-2009, 11:59 PM
Adobe is the company that still thinks that Alpha channels should be in sRGB 2.2 Gamma. *shakes head in disgust* That one took me about 4 years of aggrevation to figure out. And don't even get me started on their gradient tool.

Lucas Wilson
09-25-2009, 01:44 AM
I'm pushing for a future-proof, extensible hook for data tied to R3D files.

AMPAS IIF and two other similar initiatives. Not just about R3D... about a universal, industry-wide metadata/media exchange format.

A lot of big brains in the industry working on this at AMPAS that have hundreds of years between them of production and post experience. It's impressive, very inclusve, and I believe they are doing the right thing and that once it's out there, will be widely-accepted.

My $.02 from the bleeding edge...

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA

Frank Jonen
09-25-2009, 02:52 AM
Please nothing from the Adobe staple! They have no idea what they're doing lately with file format implementations and put hacks in charge where pros should be.

Red could lead the way with a clean XML format that others can adopt as well.

Look at what XML has done for Final Draft. They based their entire format now on an open XML format that other apps can read and write. Now if they'd learn how license management works they'd really have something there to show :)

XML can be 'read' by humans and allows for quick fixes by hand, lets people exchange snippets via IM.

my 2˘

Mark L. Pederson
09-25-2009, 04:11 AM
AMPAS IIF and two other similar initiatives. Not just about R3D... about a universal, industry-wide metadata/media exchange format.

A lot of big brains in the industry working on this at AMPAS that have hundreds of years between them of production and post experience. It's impressive, very inclusve, and I believe they are doing the right thing and that once it's out there, will be widely-accepted.

My $.02 from the bleeding edge...

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA

I know folks working on the IFF project. And yeah, I think it's great.

We don't need RED to adhere to a industry-wide metadata/media exchange format that isn't adopted yet.

We need a very simple, basic .XML file - something that Deanan and I could spec over a weekend.

Call it the RDC XML spec. Publish a web page ... list Tags, Elements, Attributes and a brief description. When RED adds Tags & Elements over time - they simply add these, with brief descriptions to the web page.

Third parties or users want to use that data - they know what the Tags, Elements, Attributes all mean.

If users want to ADD their own data and/or data types - they can make up whatever tags and elements they want - and check if there are conflicting Tags/Elements in the "spec" by just checking the web page.

If you do this the right way, it could exchange with ANY future metadata/media exchange format.

I'm not a huge fan of waiting for a committee ... or waiting for industry wide adoption.

My $.03 from beyond the bleeding edge...

Trevor Meier
09-26-2009, 01:12 PM
An open XML spec would give an open metadata platform moving forward, and allow us to kill a lot of our own (red-induced) headaches. We need this.

Deanan?

Gene Crucean
10-02-2009, 04:00 PM
red team: Thoughts?

Mark L. Pederson
10-02-2009, 05:17 PM
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
10-05-2009, 03:30 PM
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
10-05-2009, 03:44 PM
#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
10-05-2009, 04:22 PM
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
10-05-2009, 05:16 PM
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
10-05-2009, 05:21 PM
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
10-05-2009, 09:58 PM
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
10-06-2009, 04:42 AM
Perhaps look to the iXML used by audio hard disk manufacturers as inspiration?

Michael

Gene Crucean
10-06-2009, 07:55 PM
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
10-19-2009, 02:56 PM
Looks like RED and Co won't touch this with a 10ft pole. Bummer.

Mark L. Pederson
10-19-2009, 06:41 PM
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
10-19-2009, 06:45 PM
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
10-19-2009, 07:56 PM
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
10-19-2009, 09:33 PM
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
10-20-2009, 02:31 AM
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
10-20-2009, 02:34 AM
Woaaaa ;)
But we still need this side car xml. That is... "XML"

Amen brother.

Benjamin Rowland
10-20-2009, 07:55 AM
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
10-24-2009, 12:04 PM
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
10-28-2009, 12:16 PM
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....

Mike Mazzotta
02-24-2011, 07:14 PM
What ever happened to this? Was it ever implemented?

Stephen Strangways
02-24-2011, 08:51 PM
Things have improved somewhat, but not as far as Mark's ideal.

We now have .RMD sidecar files rather than .RSX sidecar files, and they go a step further to the "is there a RED 'look' file that I can set in a RED software utility that will carry across 3rd party (Adobe) post workflow solutions?" problem, as the .RMD files can be written and read by REDCINE-X and Storm, and read by Adobe Premiere and After Effects. (I don't use the Adobe software myself, so I don't think it can write to .RMD files, but someone please correct me if I'm wrong.)

We don't have any LUTs, and the sidecar files are not human-readable and freely extensible. We're moving in a good direction, just rather slowly, and I'm cautiously optimistic about what the future holds.

Nick Shaw
02-25-2011, 08:04 AM
…the sidecar files are not human-readable

RMD files are just XML, so are very much human readable.

gbalaji
02-27-2011, 03:26 AM
Mark,

Are you talking about something like XML files written by Arri Alexa to SxS cards?