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 :)

Why RED should kill .RSX

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
 

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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
How is CinemaDNG coming these days?
 
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
 
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.
 
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
 
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¢
 
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...
 
Last edited:
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?
 
Back
Top