Your plan will not work in so far as it does not allow for time consuming area filters needed, although you can do "single pixel" color adjustments with LUT "on the fly", any complex area filters take too long to process "on the fly" by the player at 4K (well maybe it could be done but would require many complex image processing chips and a large memory size and power use and so cost too much for a low cost consumer player), they need to be done before encoding for release format (mostly in non real time). An example of that issue is that I think it has been said that RED ROCKET does not produce "finish" results the same as REDCINE-X, it seems maybe because extra filters were not implemented in the RED ROCKET hardware, mostly it seems RED RROCKET just de-compresses the images and re-sizes them, but does not ant-OLPF sharpen (un-sharp mask) or do heavy area filtering?
When I get my de-Bayer/image processing program out, it will do that kind of workflow in that the edit list can go back to the True RAW data to re-render for each output format, it saves quite a bit of render farm time that way because only the selected frames need to be rendered and the True RAW frames do take less diskspace than making RGB conversions of all frames. But in that case, the area filters would be part of the rendering before the result files were compressed for release formats.
I would think that RED RAY ingests RGB frames like any other compressed distribution format does like H.262 etc.
I'm sorry that I couldn't meet up at NAB, got too busy color grading on a feature and also I got called to teach RED ONE at an University from this month. Anyways, what software would provide outputting to REDray format?
Kaku, we will provide the software necessary for a REDray encode.
That is awesome news Graeme...are you working with Avid for smoother integration? it would be great to be able to add RedRay as a device, but as of now it would be some manner of export to SSD rather than a traditional playout like we now do on Symphony Nitris or other...
Did you read far too much Arthur C. Clarke, Asimov and E.E 'Doc' Smith growing up Graeme?
I think something that most of these posts are missing is the idea that REDCODE, as shot by cameras, and the REDCODE that will be used as the distribution codec are different things. REDRAY is not about decoding a live Epic signal, it's about encoding RGB values (because that's what you get after you modify, VFX, color, finish, title, conform, etc your project) into a codec that can be used for distribution. They are two different situations: one is for capturing light and storing sensor data to be decoded/interpreted later, the other is to take a finished RGB signal and compress (and presumably protect/encrypt to assuage studio's fears) it for network distribution. Although they are probably based on the same ideas, they are not the same thing.
Correct there are two versions of the REDCODE codec - REDCODE RAW for camera (which is obviously RAW) and RED delivery codec (which accepts RGB)
|« Previous Thread | Next Thread »|