Red camera without Mac and FCP

[Seán_T]

Luki,
apple IS going after the high end, not hype, just a matter of time.
-A

Yes "Apple" and "Hype" are never seen hanging out together. :tongue:

Apple might "look" high end but if you want it to be competeive with a big iron suite you'll have to throw a fair bit of cash at it.
I really dont see too many high end facilities closing their doors in the face of the FCS2 assault and dumping their resolve's or pogle's, baselight's, lustre's, scratch's. (well maybe one or two)

Now at the end of the day its still the "Artist not the paintbrush" that gives you the look you desire. But a lot of colourist's still like horsepower, I would not want to be in a grading suite with a director and half a dozen producers with anything less then a real time colour tool.

Although I can see us picking up a copy of FCS2 so we can open up peoples project and help fix them.

 

[Seán_T]

If I may add one more thing. In the past some of the distributors and networks have insisted that an uncompressed post workflow be followed. Now I dont see this as a real issue but its interesting to think you could be in breach of contract by compressing. I doubt any real current agreement would have this. Although some bonding companies still insist on tape for recording so they can send in the bailiffs and seize something tangible (this will change).

yeah, the 4k online/conform/grade is what we are starting to plan for investing (and what i am trying to understand if this is doavle on osx).
While NAB i was under the impression that we would use FCS for this, but as i understand now color (2k) and FCP (no uncompressed 4k reimport/10bit) are not able to do that (yet)


we want to stay 4k in the pipeline - even with 2k or 1080 out, as 4k offers so more headroom for grading, track, pan/scan/scale, key etc.

luckily we already have 2k and 4k pipelines in the houses, however the 4k workflow is slow & complicated and now with red coming (we have a ~400 and ~900 reservation) it makes sense to begin to change that.

 

[david farland]

Excellent post Laguun.....Thank you

 

[Poi Boy]

Sean.
Actually that is the beauty of the apple fcs thing, you don't have to throw nearly as much cash at it to get very very close to the high end facility quality.
Aloha
-A
And yes talent always rules no matter the tool. ain't it great ?

 

[Stokestack]

The QuickTime REDCODE codec supports many pixel types, including 32-bit floating point YCbCr. We'll also support 16-bit RGB (as in a total of 64-bits) for applications that might want to use that (Shake & After Effects I think).

Shake and AE will want 16-bit RGB in the b64a (16-bit RGB) pixel format. As long as the codec offers that, you're good.

 

[Rob Lohman]

b64a is what we're supporting

 

[laguun]

b64a is what we're supporting

excellent.

 

[Brandon Rice]

Same thing is happening with HVX as well. The PC users struggle with P2 or achieve substandard results. I saw the RED footage working in the APPLE booth at NAB, nowhere else. FCP Studio 2 should generate more interest among PC users.....

Actually the HVX works flawlessly with Avid and a PC. I'm a PC+Avid guy, and I'd like to see Avid compatible with RED in the near future.:matrix:

 

[Nik Manning]

Using FCP for offline and cuts only would it be possible to finish in 4K in Motion 3? Using something like Colorista and conduit for Color grading now that Motion can motion track and do 3D?

 

[garageman]

Actually the HVX works flawlessly with Avid and a PC. I'm a PC+Avid guy, and I'd like to see Avid compatible with RED in the near future.:matrix:

I'm a Mac and Avid user and would like to see Avid compatible with RED. According to the Avid moderator on the Avid forums Avid are talikng to RED, but I don't know how true that is. Some say it's up to Avid and others that it's up to RED?

 

[Brandon Rice]

HM. that's troublesome... I hope they get on the same page soon.

 

[GlennChan]

Riddle me this then - my understanding was that there were inherent color shifts going between RGB & Y'CbCr - Andreas was all proud of his Synchromy stuff because it could do it (under carefully guarded constraints).

My understanding (from reading his website) is that it reduces rounding error when converting between R'G'B' and (video) Y'CbCr.

If you look at the math of it (according to him there's no formal branch of math that covers this) and work out the formulas, you see that you always have rounding error when going from same bit rgb <--> ycbcr. This makes sense because YCbCr defines a lot of colors that don't exist in RGB (and also because the colors don't map 1:1). If you want lossless conversions between RGB and YCbCr, then Andreas' Synchrony scheme will do it... but you need to tack on two extra bits.

Charles Poynton's book (and likely his website) should have all the right formulas.

1b- It gets a little more complex than this since there are:
--scale factors, offsets (8-bit video Y'CbCr puts legal values in the 16-235/16-240 range, whereas 8-bit rgb is in the 0-255 range); there's also video format R'G'B' which would use the 16-235 range (well, the 10-bit equivalent of it)
--video Y'CbCr puts chroma in the 16-240 range, whereas luma is in the 16-235 range (for 8-bit formats)
--depending on whether you're dealing with video or computer imagery, the transfer functions are different between sRGB and Rec. 709 and Rec. 601

2- To me, color shifting is something else... i.e. if you encode/decode Y'CbCr with the wrong formula (or set of formulas), then you will get big errors in color accuracy. An example:
http://www.spectsoft.com/wiki/RaveManual/Support/Whitepapers/Spectsoftrec601rec709diff

This can happen because there are 3 sets of formulas for encoding/decoding rgb<-->ycbcr.
Rec. 601... used for standard definition formats
SMPTE 247M (this is for the obsolete 1035-based transitional HD format; some equipment can be set to use these formulas)
Rec. 709 for all modern HD formats

If you want to resize rec. 601 values for an HD format, then you actually need to convert the Y'CbCr values from Rec. 601 to Rec. 709.

3a- I believe with Redcode you don't pick up any unnecessary rounding error when going
redcode (12-bit linear light, integer) --> FCP rendering (32-bit Y'cbcr, floating point) --> output format

Because you have an overkill of bits in 32-bit floats, you don't get unnecessary rounding error (other than what the output format is doing).

3b- If you don't devote a lot of bits to floating point then you can actually get a lot of rounding error / loss in precision (a lot more than you would think)... this gets into some wacky/not obvious math.

http://docs.sun.com/source/806-3568/ncg_goldberg.html