[Sareesh Sudhakaran] “The first is an encoding format, the second is a color model. Neither are color spaces. The color space you are probably working in is most likely Rec. 709, and there’s nothing you need to do about that. “
That’s a good environment description in a nutshell.
For the web, it might be confusing to introduce a term like sRGB, which is based on Rec709, but the reality is that the de facto streaming standard codec is H264, and you want as compact a file as possible, so the Y’CbCr codecs lend themselves to that right away. Both sRGB and Rec709 use the same primaries and aim for a similar white point, but that is not the whole question as I read it.
If part of your workflow is linking back to the original RED RDM files, or whether you are dealing with ProRes 422 Alexa source media, or 4:4:4, then you are already dealing with the original, non-transcoded, which is a good way to go. Beyond that, however, especially where Final Cut (up to 7) is concerned, then RGB does become an issue — however, unless you really need full bandwidth RGB channels for VFX work, its a waste of drive space and processing efficiency. Once your grade is locked, then a lot of 8-bit is perfectly acceptable for moving forward, especially for web. We do still run into scaling issues (0-1023 vs 64-940) depending on intermediate conversions, and FCP deals very poorly with that.
There are legends around Final Cut dropping to 8-bit for RGB processing, maybe someone else can confirm that… I just don’t use RGB unless forced into it with a dpx flow or dated Animation codec for a graphic that needs an alpha channel that someone has imbedded.
The reality is that that is not necessarily a bad thing as it is a trip wire for problems that will crop up in web compressions. Sorting out whether that’s important or not depends on your monitoring solution and the quality of the preview.
jPo
“I always pass on free advice — its never of any use to me” Oscar Wilde.