While I respect the attempt, I think you're vastly overestimating the influence one product can have on an entire industry. There have been many, many attempts to standardize metadata - the ASC and SMPTE have both had committees dealing with this very subject for quite some time - and all of them have failed. There are many reasons for this, some of which are obvious and some of which aren't. But suffice it to say that all of the industry players would have to agree before anything could really be implemented successfully - and that includes manufacturers and end users. That's a very difficult and unlikely scenario. The DPX format itself - the closest thing any of us in the industry have to an accepted, exchangeable standard file - has numerous variations, a number of which break certain software that otherwise conforms to the "standard." Hell, even file naming conventions are unique to each facility. If you want to try and standardize some of these things, and can do it within the sphere of the individual companies that you deal with regularly, then more power to you. But as for the industry accepting something because one company - i.e., Red - suggests it, well..... all I can say is good luck with that.
Welcome to our community
Be a part of something great, join today!
Tools & reverse engineering
- Thread starter Rob Lohman
- Start date
While I respect the attempt, I think you're vastly overestimating the influence one product can have on an entire industry. There have been many, many attempts to standardize metadata - the ASC and SMPTE have both had committees dealing with this very subject for quite some time - and all of them have failed. There are many reasons for this, some of which are obvious and some of which aren't. But suffice it to say that all of the industry players would have to agree before anything could really be implemented successfully - and that includes manufacturers and end users. That's a very difficult and unlikely scenario. The DPX format itself - the closest thing any of us in the industry have to an accepted, exchangeable standard file - has numerous variations, a number of which break certain software that otherwise conforms to the "standard." Hell, even file naming conventions are unique to each facility. If you want to try and standardize some of these things, and can do it within the sphere of the individual companies that you deal with regularly, then more power to you. But as for the industry accepting something because one company - i.e., Red - suggests it, well..... all I can say is good luck with that.
Kevin Halverson
Well-known member
Having struggled within other industries in an attempt to extract a consensus to establish a working standard, there are always those that don't like the direction that the emerging specification is taking and they break away. As soon as any player of any real size breaks away, others follow and pretty soon, you have little consensus left.
The only time that I have seen this work is when there is a single body that holds control over a license that they grant to others in exchange for an agreement to abide by the rules of the standard. Then, in order to be in compliance they are constrained. The industry that I work in is audio, but the size of the players is similar and they are just as individualistic as in this industry.
Someone needs to have a trademark or something that others would perceive as being desirable to have access to in order for their to be an incentive to comply. I have no idea what this 'carrot' would be, but without something, I really don't think anyone will ever get an agreement.
The only time that I have seen this work is when there is a single body that holds control over a license that they grant to others in exchange for an agreement to abide by the rules of the standard. Then, in order to be in compliance they are constrained. The industry that I work in is audio, but the size of the players is similar and they are just as individualistic as in this industry.
Someone needs to have a trademark or something that others would perceive as being desirable to have access to in order for their to be an incentive to comply. I have no idea what this 'carrot' would be, but without something, I really don't think anyone will ever get an agreement.
jbeale
Well-known member
I have very little insight into the post industry... I'd say if people really don't want a standard then it won't happen, and it sounds like that's the case here. Still, anything that has wide prevalence is a de-facto standard. If Red ships as many cameras as they've projected, I'd guess that whatever file format that comes out of the camera is a de-facto digital cinema standard just by the weight of numbers. Of course from that point everyone will diverge into DPX, TIFF, ProRes, Cineform or whatever else, but at least the camera file would be a standard.
Gavin Greenwalt
Well-known member
- Joined
- Dec 29, 2006
- Messages
- 7,614
- Reaction score
- 0
- Points
- 36
- Age
- 40
I don't think a standard will ever emerge. You have a composite with 62 layers... which one do you take the meta data from? Do I have to add a node tree to keep the metadata from a background plate for the TC and another to keep the metadata from the lens settings on a miniature shoot?
Everybody's requirements are different. How a studio designs its pipeline is a very personal, very specialized and very thoroughly thought out process It's not arbitrary it's the result of experience, best practices and flexibility. While editing is a very standardized workflow, it's a known quantity. You throw in VFX and you're by definition creating something unique.
The best and only solution is what I've always advanced (and Mark started building) a database driven asset and project management tool. Let a computer keep track of what is what. When the VFX footage returns let the database remember what its TC was and what data you need.
Everybody's requirements are different. How a studio designs its pipeline is a very personal, very specialized and very thoroughly thought out process It's not arbitrary it's the result of experience, best practices and flexibility. While editing is a very standardized workflow, it's a known quantity. You throw in VFX and you're by definition creating something unique.
The best and only solution is what I've always advanced (and Mark started building) a database driven asset and project management tool. Let a computer keep track of what is what. When the VFX footage returns let the database remember what its TC was and what data you need.
- Thread starter
- #45
Rob Lohman
Red Team
Absolutely NOT!!!!
This is exactly the problem we're trying to AVOID! The problem is the footage such a tool creates, not the tool itself.
Please please do not do this.
How soon would you realistically need to do this? (please don't say asap)
Kevin Halverson
Well-known member
Hi Rob,
I need a solution by the second week of January at the latest, but a few days before to test it out would be better!
Kevin
FYI, pushing a trimming tool ahead of schedule (yes it was on the schedule) will delay win/lin commandline render versions and other tools. The problem is that we have lots of users (probably 100:1) that really need the win/lin command line versions before anything else. End result is a ripple effect on the schedule for other tools/features which needs to be weighed carefully.
Kevin Halverson
Well-known member
Well as I have a tool that works now for my own purposes, I can certainly wait and don't want to upset the current schedule, so feel free to push off my requirements. You can add to that my need for the win/lin command line versions of other tools (I assume this might include RedCine), so I am fine with what I have now. I would just like an official tool at some point in the future so I don't have to use my own forever. By the way, I wouldn't advocate a 'destructive' tool, only one that can generate new output with a different file name than the input one.
Kevin
Kevin
- Moderator
- #49
Jeff Kilgroe
Well-known member
Gavin Greenwalt
Well-known member
- Joined
- Dec 29, 2006
- Messages
- 7,614
- Reaction score
- 0
- Points
- 36
- Age
- 40
We were hoping to release 10 second Greenscreen and bluescreen r3d files today. *ducks*.
I'll talk it over with Ken and Steve to try to figure out how to proceed. I have about 30GB of green and bluescreen footage of various setups and testing procedures. Since RAW is a selling point on RED we wanted to let people have some r3d footage to develop themselves and independently discover what they found to be the best practices for generating their own uncompressed chroma screen footage.
Mark L. Pederson
REDuser Sponsor
I hear you. But I am not trying to have an influence on an entire industry, just my own productions and business.
- Banned
- #53
-excellent- news!
with a commandline for redcine and/or trimming tools many of the red-specific work flow issues we see right now in full feature production become fixable.
guess i should prebook some database coders soon.
- Banned
- #54
Hey Gavin, thanks for being the fileformat pioneer and building these tools!
- Thread starter
- #56
Rob Lohman
Red Team
did you not get the idea behind this thread? Please do not encourage people to do this
Gavin Greenwalt
Well-known member
- Joined
- Dec 29, 2006
- Messages
- 7,614
- Reaction score
- 0
- Points
- 36
- Age
- 40
Laguun usually misses the hint.
- Banned
- #59
yeah, sure.
just wanted to acknowledge the work you invested in coding & research, even when your tool isn´t not wished for atm. no need to go ballistic and post personal attacks.
*sarcasm on*
i hereby officially condem the foolish attempt you undertook when writing the trimming tool.
better?
*sarcasm off*
- Banned
- #60
i understand the idea, i agree, and i also unterstand that to freeze a design of a fileformat is something which isn´t trivial in the infancy of a product - but necessary for an sdk.
we won´t encourage anyone to use the workarounds and the problems which can occur with such tools especially in newbie hands are indeed ugly.
just wanted to give the author credit for his work, as redportals or metacheaters authors got their kudos.
i think this tools however demonstrates the need for a good documentation & sdk of the fileformat, once the cameras are out en masse - as there will badly coded workaround and niche tools floating around when the posthouses r&d guys begin to write their typical "gets the job done" tools.