Worried about depending on RED codec

ummm.... I think YCbCr is bigger RGB space it's made from! More info than that, you'll have to hire a colour scientist as you're reaching the limits of my knowledge :)

I have no problem with people doing YCbCr conversions in an appropriately high bit space (I think 2 extra is needed to maintain precision) but I do have philosophical issues with it as a recording space, when all compositing (nearly) and display, sensors and our eyes are all RGB.

For MPEG4, you're basically suggesting what HDCAM SR is using? There's no native support for that, and it's rather slow to decode in software, similar entropy encoding issues to J2k I think. Arithmetic encoding is powerful, but tricky to deal with. (Not to mention the amount of hardware Sony need to throw at it to do a real time encode from HD)

Graeme
 
Last edited:
Hi Graeme,

Im sure you're aware of the cineform codec (variable wavelet also) that seems to let you use 10 bit RAW files directly on the timeline, which I think is great for CC; it also allows around 4 streams of 1080p to play back in realtime.

anything like this on the horizon? :)
 
I'm aware of the cineform codec. It's very well done. What we're doing is a little different, but should be similar in terms of performance.

Graeme
 
Darkline said:
Im sure you're aware of the cineform codec (variable wavelet also) that seems to let you use 10 bit RAW files directly on the timeline, which I think is great for CC; it also allows around 4 streams of 1080p to play back in realtime.
Click to expand...
:thumbsup:

Graeme_Nattress said:
I'm aware of the cineform codec. It's very well done. What we're doing is a little different, but should be similar in terms of performance.

Graeme
Click to expand...
Hopeful news. Graeme, you are our bet! (it's a large community out there where I'm included myself since my RED reservation was done following our trust in your skills and well-known know-how from the plug-ins with your name, as well, your input in the forums like this one)

And you know how worthy is...
 
It's a team effort, but we're all working hard to make it happen. I've given up sleep and am running on caffeine and whisky for the rest of the year :)

Graeme
 
Graeme_Nattress said:
It's a team effort (...)
Click to expand...
Bien sur...Frédéric was a great acquisition to Jim as add-value to all of us. I like that guy as his way as his work.

Fred, I owe you an e-mail that I will send you as soon as possible -- est-ce bien?
 
Graeme_Nattress said:
ummm.... I think YCbCr is bigger RGB space it's made from! More info than that, you'll have to hire a colour scientist as you're reaching the limits of my knowledge :)
Click to expand...

I hope RED team has the resources for that color scientist! ;-)
And since yuv space (usually, afaik) is wider than rgb, there's no harm to use it as an intermedia space.

Graeme_Nattress said:
I have no problem with people doing YCbCr conversions in an appropriately high bit space (I think 2 extra is needed to maintain precision) but I do have philosophical issues with it as a recording space, when all compositing (nearly) and display, sensors and our eyes are all RGB.
Click to expand...

I think you are right in that theoretically every conversion looses one bit.
But eyes are not just rgb. Rod cells sense only luma.
And 4:2:0 still saves 50% of storage space. Sometimes that might be crucial. I think 4:2:0 has a bad reputation just because it isn't good for interlaced video and conversion from 4:1:1 dv to 4:2:0 mpg (dvd) will result actually 4:1:0 and this is often seen as "bad 4:2:0".

For example document work usually needs huge amounts of footage and is often shot without lots of light. So using the full sensor's sensivity, but recording to 1080@4:2:0 might be very useful combination.
If I would have to choose then from 4:4:4@8bit or 4:2:0@10/12bit, I would choose the latter one. Maybe others would also.

Graeme_Nattress said:
For MPEG4, you're basically suggesting what HDCAM SR is using? There's no native support for that, and it's rather slow to decode in software, similar entropy encoding issues to J2k I think. Arithmetic encoding is powerful, but tricky to deal with. (Not to mention the amount of hardware Sony need to throw at it to do a real time encode from HD)
Click to expand...

Native support for what? Hardware FRExt encoding chips?
I'm not so aware what happens in chip technology so deeply, but my guess is that FPGA could be the modern way to deal with encoders. That way you could update the "hardware" encoding chips with software.

I wasn't suggesting particulary FRExt, but anything existing or "soon to be" international standard, that is not owned by one company.
I think there too much incompabilities in ICT industry, where every company has their own standards. It leads to this "itunes only for ipods" phenomena where small companies and quality suffers and big monopolies like microsoft (os) or apple (downloadable music) profits.
 
Last edited:
Yes, we have a colour scientist!

Yes, YCbCr is wider than RGB, so an RGB cube in YCbCr takes up less volume than the YCbCr cube. This means that a lot of bits of precision to make up the large YCbCr space cannot be used by RGB or legal YCbCr values. It's therefore very wasteful to encode into it in terms of absolute precision.

Also, as we're going for absolute quality, 4:2:0 is not suitable, and neither is 4:2:2. You can practically always get better results, even if you go to YCbCr compressing the Cb and Cr further while keeping them full resolution, rather than reducing their resolution and compressing them. Far better to let the codec reconstruct a 4:4:4 image from compressed 4:4:4 data, than to reconstruct from 4:2:0.

"Native support for what? Hardware FRExt encoding chips?" No native NLE support.

The main issue with codec support is that codecs are developed for different reasons. They generally go after maximal compression efficiency at the expense of complexity and either hardware or software implementibility. They're most often not designed for editability.

Graeme
 
But if the Cb connects to the Cr and the RGB reflects the YcbCR which is multiplied by its square root, you will see how wasteful 4:4:4 is to 8:8:8 data compressed with z&X value of the wierd kind.

:Drogar-BigGrin(DBG)

Couldnt resist...I have no clue what you two are talking about Graeme & Toke lahti, except that Toke looks like hes trying to get a job at Red. :)

peace all

dalen
 
Given that the sensor, the monitor and the eye are all RGB, it makes total sense to stay in RGB as much as possible
Click to expand...

I agree that it makes sense to stay in RGB for the most part (depends on the specific RGB colorspace). For the sake of clarity though I think it's a bit over simplistic to say that our eyes are RGB. While our eyes do have three types of cones that respond to roughly red, green, and blue they overlap to a significant degree which is noteworthily different from a sensor with red, green, and blue filters. It's probably also important to take into account that our eyes have a significant disparity between the number of each of these cones and their location on the retina.

cone_rod_sensitivity.png


But eyes are not just rgb. Rod cells sense only luma.
Click to expand...

Yes and no really. They sense luma but with a peak sensitivity around 498nm which falls between blue and green which can cause some interesting things to happen depending on the light level.

Just my random thoughts whilst reading the thread =)
 
Last edited:
Yes, I was being simplistic about eyes. I do think that, however, if you keep the workflow RGB from sensor to monitor, you do gain advantages though.

Graeme
 
Graeme_Nattress said:
Yes, I was being simplistic about eyes. I do think that, however, if you keep the workflow RGB from sensor to monitor, you do gain advantages though.
Click to expand...
And still once more, you can also run in troubles, if you run out of storage when shooting, or your post production can't handle too fat footage or you end up with banding in cc'ing, because you couldn't use deep enough color space when shooting.
Ground rule: give users options and let them to choose!
 
I have a question about recompressing the RED Codec.

I know there have been some movements in post world as of late to create codecs which can be edited rendered out, reimported and redited without losing very much if any quality. (DNxHD comes to mind)

Since the red CODEC is an intraframe compression algorithm (isn't it?) would it be possible to create a conformer (Self plug for my RED conformer thread :)) which would be able to take an EDL and break up and conform RED CODEC footage into final sequence without any recompression? Or even better yet, be able to render out a a final sequence which if unmanipulated would maintain the exact same quality without a second pass of compression?

Right now the workflow I have to work with involves editing in native DV, then rendering out sequences in uncompressed targas or AVIs for color and fx/compositing. I would LOOOOVEEEEEE (I don't think I stretched that out enough, but the mods might get angry with any more letters) to be able to ditch an uncompressed workflow and stay inside of a codec if I didn't lose quality recompressing.

Matter of fact, if you made a super simple little batch file that could perform super simple operations like
"redcodec.exe \ \network\clip1.red -delete f 23536-35332 -fileout \\network\cut_up.red"
"redcodec.exe \\ \network\Big.red -resize gaussian -h 640 -w 480 -fileout \\network\small.red"

If you wrote a program for us that was that simple to write batch files for with even more extensive API support, I could only imagine the creativity and flexibility of the third party tools created by normal mortals and artists like ourselves.
 
You must log in or register to reply here.
Back
Top