Aha says the tick tock man, time to deliver to the client!

[Jarred Land]

tj-

Perhaps someone from RED could let us know the details of the demo footage that's been screened - render times, system used, etc etc

I was the one who processed the frames for all the footage thats been shown, and its safe to say the time it took to render those images is irrelevant at this point.. Graeme and Rob have progressed the development so far ahead of those times that its a whole different ballgame.

Even back then.. we used Mac towers and Laptops to encode.. not supercomputers.

 

[Wade McDonald]

Correction to my previous post --

I explained the 11 stop compression into 5.5, and then went into a rant about gamma without calling it that. Gamma is the reason that Kodak invented Cineon (to retain the 11 stops of dynamic range on a computer system, or at least accurately represent them, and why you have to use a proxy log/lin color system to view them correctly) Video is based on the gamma of CRT televisions, and has a much higher gamma than film.

Again, I'll refer to the wisdom of the masses:

(from wikipedia, linked below)
"
Photographic film has a much greater ability to record fine differences in shade than can be reproduced on photographic paper. Similarly, a video screen is not as capable of displaying the range of brightness which can be captured by electronic cameras. For this reason, a considerable amount of artistic effort in photography can be invested in choosing what reduced form of the original image should be presented. The gamma correction, or contrast selection, is part of the photographic repertoire used to adjust the recorded image.
"

http://en.wikipedia.org/wiki/Gamma_correction

Again, this is my understanding from working with video engineers... I might have a few details wrong.. feel free to correct me.


-W

 

[Gopher77]

Personally I see this going the same way as digital photgraphy. Nearly all photographers shoot raw now, depending on the client they deliver either a disc of raw photos or they take them in photoshop and process and deliver finished photos. Clients are going to want different things, some will want raw, other HD etc. The beauty of RED is will be able to deliver all, and still own the RAW "negative". As far as render times, I think we have to wait till they get finished and some benchmarks can be ran. Seems to me these guys know what they're doing and are keeping us updated on their progress. So I'll just hang out and see what is what when they are finished rather then speculate on what may be.

 

[tj williams]

very interesting stuff.

very interesting stuff.

Wade: Thanks for the example. So by my calculations if I bring in 720 60 direct fm a Varicam with all the frames for my 200minute example I'd need about a 130Gig portable drive. Right very dooable from a drive perspective. On this footage did you digitize into the computer at the same compression that was on the tapes? Is it the same codec that was on the tapes?

Wade: I quite agree with your point about grading RAW footage and have done this in Photoshop. Amazing range of possibilities there. I've been willing to go to the Davinci suite for low wages to be sure we are getting a good consistent look and this is not too different. I've priced scratch and the other graders out there by the time you have a computer and array and the software you have spent some pretty serious bucks.

Jared. So what was the old rate in an approximate way? and if the new rate is better what is it now? None of us know here whether we are talking about 2 frames an hour or real time? Sure it will in all probability get better again but at least give us an idea of what we are talking about in terms of render time.

If RED Code Player is distributed somehow to the edit house, then I'm wondering about a 2K RAW to send them so they would have the abililty to make the maximum corrections. This is because much of what I shoot is intended to cut into programs with a number of other shooters and have a consistent look.

Will 2K raw take more room on disk than for instance 1080P 24 HDCam?

Will it be possible to put out HD resolutions in RAW?

 

[Finner]

Wade very nice posts. I look forward to hearing more from you in the future.

 

[Wade McDonald]

Wade: Thanks for the example. So by my calculations if I bring in 720 60 direct fm a Varicam with all the frames for my 200minute example I'd need about a 130Gig portable drive. Right very dooable from a drive perspective. On this footage did you digitize into the computer at the same compression that was on the tapes? Is it the same codec that was on the tapes?

Wade: I quite agree with your point about grading RAW footage and have done this in Photoshop. Amazing range of possibilities there. I've been willing to go to the Davinci suite for low wages to be sure we are getting a good consistent look and this is not too different. I've priced scratch and the other graders out there by the time you have a computer and array and the software you have spent some pretty serious bucks.

Yep, I maintained the footage, capped over HD-SDI using a Kona LH, in its original format (DVCPROHD 720p60 codec) -- I didn't have access to the nifty Panasonic Deck that connects via firewire, because my local rental place didn't have one at the time... my client was thrilled, and it was (albeit compressed) more than adequate for my Shake work -- there were a few artifacts in some of the greenscreen footage, but they were on the tape too, and didn't cause any problem whatsoever. However, even if you end up compressing it into DVCPROHD (which is a SMTPE standardized codec used by a number of cards -- canopus, kona, blackmagic, etc) it still meets the delivery requirements of most major networks (not sure about Discovery, as they're notorious for high requirements -- they may require something like HDCAM SR)

I hate to plug something, but if you have a mac there's a widget made by a uk plugin company that helps calc storage based on industry standard codecs for HD -- it's free, and it takes audio into account.

http://www.digital-heaven.co.uk/videospace/index.php

I ran your original request (1080i60 DVCPROHD, 200min, 2ch 48k 16bit) and it says 174.93 gig. Sounds wrong to me.

Hmm... it says my 720p60 600 minutes should have been around 525.31 gig; so perhaps my low numbers are because it was mostly greenscreen footage for composites? either that or the thing overestimates. Oh well. I'm using an 1.6 TB RAID external firewire 800 for most of my VFX work, and I've found that it's plenty fast for realtime 720p60 editing (I worried that the framerate was too much to adequately process)

Yeah, you're right about the high-end post. I'm hoping there are going to be more options in the future. I'm really impressed with Scratch, but it's a bit out of my price range too, hehe. A good one-light in REDCINE plus some basic grading with my NLE is all I plan to do for most of my in-house projects... post places are wonderful, but most of my clients don't want the extra expense... not to mention you can do a lot CC-wise if you spend a little time in your NLE, be it FCP or Avid. I'm the king of replacing expensive hardware/software workflows with lots and lots of elbow grease -- even to the point of using Shake to mask and power-window like a davinci.

There's some hope though... Apple bought up all the IP of Silicon Color's Final Touch grading system.. here's hoping that they do what they did with Shake and put the pricing at a reasonable level... NAB maybe?

-W

 

[Corrado Silveri]

Yep, I maintained the footage, capped over HD-SDI using a Kona LH, in its original format (DVCPROHD 720p60 codec) -- I didn't have access to the nifty Panasonic Deck that connects via firewire, because my local rental place didn't have one at the time...

Hey Wade, in this way you've decompress "out" and recompress "in".
The codec was the same, ok, but you modify the original footage twice...
Correct me if I'm wrong.

And yes, hoping to hear news from Apple at NAB.

 

[Antoine Baumann]

Will 2K raw take more room on disk than for instance 1080P 24 HDCam?

Will it be possible to put out HD resolutions in RAW?

Elo Williams, are you talking about HDCam or HDCam SR, and what kind of raw are you talking about?
If I remember well, HDCam is about 140Mbit/s, so around 17.5MBytes/s. RECODE raw 4k will be around 30MBytes/sec, so around 7.5MBytes in REDCODE raw 2k.
HDCam SR is 440Mbits/sec in 4:2:2 and 880Mbits/sec for 4:4:4:. 2k uncompressed raw is 2260x1270x1(raw)x10(bit log)x24(fps)= 690Mbits/sec
I am actually unsure of the raw's bit depth. I think you can record up to 12 bit (lin), which would raise up the data rate to 830Mbits/sec.

Raw is a single channel format image, and therefore it is 3 times lighter than rbg. For exemple for 2k REDCODE rgb is going to be 3 times 7.5MBytes/sec (@24fps), so 22.5MBytes/sec.

As far as I understand it, the only way to output HD resolution in raw is to process 4k or 2k raw inside redcine to an HD resolution.

Hope it helps,
antoine

 

[Nick Shaw]

For exemple for 2k REDCODE rgb is going to be 3 times 7.5MBytes/sec (@24fps), so 22.5MBytes/sec.

Remember 2k REDCODE RGB doesn't exist in camera any more, although I'm sure you can use it as an output format from REDCINE, whether derived from 2k or 4k REDCODE RAW. The closest you have is 1080p REDCODE RGB. We don't know data rates for that, but it wouldn't be unreasonable to expect that it would be similar to those for 4k REDCODE RAW. 25% the number of pixels, but 3 times the number of channels would imply 75% of the data rate, but compression efficiency decreases with image size so about the same is a good assumption.

 

[Martin Drew]

--- it doesn't work very well, unless you've got a heck of a pump (REDCODE, to extend the metaphor too far). I wouldn't give away such a pump for free to just anyone.

Great post Wade.

There are a number of ways of looking at this issue. It appears that Red's strategy is to go for market penetration, in which case giving away the RedCode codec could make a lot of sense. It is like Apple giving away iTunes in order to sell more iPods.

M

 

[Antoine Baumann]

Remember 2k REDCODE RGB doesn't exist in camera any more, although I'm sure you can use it as an output format from REDCINE, whether derived from 2k or 4k REDCODE RAW. The closest you have is 1080p REDCODE RGB. We don't know data rates for that, but it wouldn't be unreasonable to expect that it would be similar to those for 4k REDCODE RAW. 25% the number of pixels, but 3 times the number of channels would imply 75% of the data rate, but compression efficiency decreases with image size so about the same is a good assumption.

Yep you right 2k rgb doesn't exist in camera, but as you also said I was thinking as an output format from REDCINE.

I totaly aggree with the 75% of data rate from 4k raw to 1080p/2k rgb.

 

[Nick Shaw]

TJ, I think we are basically in agreement, although somebody might not think so from reading our posts!

In the long run, HD post houses will all need to have REDCINE, but in the short term freelance camera owner operators need to make the process as simple as possible for producers in order to sell in the idea of shooting on RED.

Going back to your original post, the easiest solution would appear to be, as you said, converting all rushes to DVCProHD (about a minute and a half per GB for 1080p24) so that you can give somebody a drive of reasonable size and affordability with a format on it that they are familiar with and can use immediately. If they are editing on Avid, you could convert to DNxHD (220Mb/s for 10-bit, so about twice the data rate of DVCProHD, but still perfectly feasible).

DVCProHD is an 8-bit format (but so is HDCam) and DNxHD is 10-bit (but not 10-bit log like DPX can do) so either way you are losing some of the bit depth of the original REDCODE, as well as 'baking in' the white balance, curves etc. Obviously these can be changed to an extent in the grade, but only to the same extent you would have in a tape-to-tape grade. Working direct from the REDCODE would be more like the grading flexibility you have in a film TK.

It is a dilemma. Some of the advantages of RED which you want to be able to use to sell the idea, are no longer there if you go the transcoding workflow. 35mm DoF and top quality ciné glass are still a big deal though.

A freely (or cheaply) distributed QuickTime codec would indeed make the situation easier. It would still not allow the full RAW flexibility of REDCINE, but it would mean that rushes could be handed over at the end of a shoot without the time taken for transcoding. Without REDCINE for match-back, people who want to take a traditional offline/online path will still not find it easy though.

The workflow is definitely not immediately straightforward to fit into existing industry infrastructures. It is the main reason why I as an editor reserved a RED. I've seen it happen with both the VariCam and HDV, that they took a while to catch on as formats (certainly here in the UK) because producers were loathe to shoot with them, because many post houses were not initially set up to deal with them. Rushes got dubbed onto other formats, often not very well, and people then didn't see them at their best, and formed opinions accordingly. I want to be an early adopter on the post side.

No easy answers, but lots of food for thought!

Nick

 

[Wade McDonald]

Hey Wade, in this way you've decompress "out" and recompress "in".
The codec was the same, ok, but you modify the original footage twice...
Correct me if I'm wrong.

And yes, hoping to hear news from Apple at NAB.

Technically, you're correct, but because all the points are digital, there's not a significant generational loss. This is the workflow of choice for working with most video decks... play the tape over HD-SDI to the NLE to log. I could have captured it in an uncompressed format in the NLE, but it wouldn't have recorded any more data than was already present... kinda like making a .zip file, unzipping it, copying the contents, and re-zipping... no percevable generational loss... If I had used the analog component out of the deck and put it into the NLE that way, I'd have been subject to recompression nastiness.

-W

 

[Nick Shaw]

I agree there is unlikely to be a 'significant' generational loss, DVCPro HD is a pretty good codec when it comes to re-compression cycles. However I would not call it the workflow of choice. DVCPro HD 720p60 works internally at 960x720, but HD-SDI is 1280x720. Therefore you are performing a horizontal up-scale, followed by a downscale in your work flow. Even if the re-compression loss is negligible, the scaling will 'damage' the image, particularly if you need to pull keys (unless the slight softening is helping you.)

It is what you have to do when editing HDCam in anything except Xpri (which as far as I know is the only system that works natively in the HDCam codec) but one of the reasons DV based formats get away with higher compression ratios is that the need for generation loss is reduced.

EDIT
Just did a test in Photoshop of scaling 960 to 1280 and back again. I took a worst case scenario with alternate black and white lines. In the result, the white lines became 75% white, and the black lines became 25% white, so each pixel becomes 75% of its own value plus 12.5% of each of the values of the pixels either side. Not that insignificant! And that's not taking account of what would happen to the 4:2:2 sub-sampling in this process.

I don't think your zip analogy fits here, as zip is numerically lossless.

 

[tj williams]

Thats good news about storage in DVCproCodec

Thats good news about storage in DVCproCodec

Wow WAde! Good figures anyhow....175 gig 200= min So most of my jobs could be sent to the client in DVCpro50HD on a disk like the one below?

SMARTDISK XF250F CrossFire 250GB External Hard Drive Price: $179.99 US at Amazon. equiv HDCam tapes are over $200 so this is a very reasonable way to send material to the client.

Labroprod: Bear with my computer ignorance here! RED RAW is what I was referring to. Is that the same as other forms of RAW? Currently we deliver HDcam tapes. I didn't mention but I believe that in the future we will be required to deliver in HDCam SR (Which is gonna be like betacamSp which replaced std betacam) As I understand it now most of the editoirs don't actually ingest HDCam codec but transcode it to DVCProHD?

Paraphrase Lab:"If I remember well, HDCam is around 17.5MBytes/s. RECODE raw 4k will be around 7.5MBytes in REDCODE raw 2k."

So what I conclude from this is that it is better in terms of disk space and my time to be able to send the client RED RAW 2K on the portable disk. INcluding a copy of RED Cine (or they download it) So they can pick out the circled takes for import ingest. Is that right?

Quoted fm Lab: "HDCam SR is 440Mbits/sec in 4:2:2 and 880Mbits/sec for 4:4:4:. 2k uncompressed raw is 2260x1270x1(raw)x10(bit log)x24(fps)= 690Mbits/sec i'm actually unsure of the raw's bit depth. I think you can record up to 12 bit (lin), which would raise up the data rate to 830Mbits/sec.

So to put my 200 minutes on a hard drive. in HDCam SR 444= 830Mbits sec.X60sec49800 a minX200minutes=996gig? Thats a lot different that DVCProHD, anyone knows why? Is this a math error on my part?

Quoted: "Raw is a single channel format image, and therefore it is 3 times lighter than rbg. For exemple for 2k REDCODE rgb is going to be 3 times 7.5MBytes/sec (@24fps), so 22.5MBytes/sec."

So this appears to me to mean that it is better to ship disks to my client in 2K raw (maybe even 4K raw) in terms of disk space alone, than to ship in the RGB codec at 1080?

Also If I ship in RED RAW and they have the software to grade in RED RAW
(could this be only for RED RAW or software that addresses any raw format?)
They will have much more grading and correction lattitude this way.

Quoted: "As far as I understand it, the only way to output HD resolution in raw is to process 4k or 2k raw inside redcine to an HD resolution."

So the camer itself cannot output RED RAW in 1080 or 720? Thats too bad because the files would be even smaller and probably use less time to transcode by the post house?

Nick: I agree we are in total agreement. We just come from different sides of the same problem. For me this all seems to mean that for cheaper shows like special interest shows on ed channel etc. etc. they won't grade in post. I've already seen the result! On some shows ie Discovery BBC they will be more interested in 444 and RAW to give them more room to adjust the image. Strangely this will mean that I will have to go to more trouble (grading, rendering and larger portable disks) to deliver to the less expensive shows?

This of course continues to point out as you said above the need for post houses to have and be ready to use RED CINE playback of some sort.

Do you know if all grading tools will address RED RAW?

Another question is that many times producers bring the set up chip for the camera they prefer. Is it possible to use the numbers off these, to get a matching look on the video in grading/rendering out?

 

[Nick Shaw]

So to put my 200 minutes on a hard drive. in HDCam SR 444= 830Mbits sec.X60sec49800 a minX200minutes=996gig? Thats a lot different that DVCProHD, anyone knows why? Is this a math error on my part?

Your maths is wrong, but in the wrong direction. It comes out at 9.96 Terrabits, which is nearly 1.25TB. That's because HDCam SR at that rate is 10 bit 4:4:4 1920x1080, whereas DVCPro HD is 8 bit 4:2:2 1280x1080. Plus HDCam SR is more lightly compressed that DVCPro HD.

But at the end of all that, it's not a real issue, as HDCam SR only exists as a tape format. It's not a codec you can use to put something on a drive. So best to stick to DVCPro HD to fit into current workflows, or hope that a freely distributable REDCODE codec sorts the problem by working natively in current NLEs.

 

[tj williams]

Wheeew Nick. Those are big numbers. Twas me weakness t maths that cause me ta be in the camera dept.

 

[Wade McDonald]

I agree there is unlikely to be a 'significant' generational loss, DVCPro HD is a pretty good codec when it comes to re-compression cycles. However I would not call it the workflow of choice. DVCPro HD 720p60 works internally at 960x720, but HD-SDI is 1280x720. Therefore you are performing a horizontal up-scale, followed by a downscale in your work flow. Even if the re-compression loss is negligible, the scaling will 'damage' the image, particularly if you need to pull keys (unless the slight softening is helping you.)

It is what you have to do when editing HDCam in anything except Xpri (which as far as I know is the only system that works natively in the HDCam codec) but one of the reasons DV based formats get away with higher compression ratios is that the need for generation loss is reduced.

EDIT
Just did a test in Photoshop of scaling 960 to 1280 and back again. I took a worst case scenario with alternate black and white lines. In the result, the white lines became 75% white, and the black lines became 25% white, so each pixel becomes 75% of its own value plus 12.5% of each of the values of the pixels either side. Not that insignificant! And that's not taking account of what would happen to the 4:2:2 sub-sampling in this process.

I don't think your zip analogy fits here, as zip is numerically lossless.

For reference, the Kona-based FCP codec I was using to capture from SDI was at 960x720, because I used the Varicam specific variation of the codec, rather than the stock FCP 1280x720 version i've suggested for TJ to consider using to deliver to his clients. There was no sub-pixel issues in the footage, although there were sight compression artifacts (far more annoying than the softness of an upscale) due to the DVCPRO HD codec itself on the green field... I wasn't terribily happy about that, I must say.

Additionally, the Photoshop scaling test is something I use when I teach concatenation in Shake... if you dont' concatenate operations, you end up with sub-pixel sampling, hence the % values. Every good compositor knows how to avoid it, and it really only becomes an issue outside of the usual video suite of tools or NLEs.

Yes, the zip analogy was an oversimplification. Sorry. I have a penchant for convenient metaphors. My intent was to say that there was no perceivable difference between what was on the broadcast monitor from the deck and from the computer. If you have a suggestion of using something other (better) than HD-SDI to connect the deck to the FCP system, I'm open to other ideas. Nick, in your shop, how do you deal with the "damage" inherent to getting footage off of any Varicam-based system, as it will be, either digitally (SDI) or analog (Component) be upscaled to 1280x720? Is there another way? (I am legitimately curious)

For our RED purposes, however, I can't see why scaling down to 1280x720 (or 1920x1080, for that matter) using DVCPRO HD wouldn't be a good bet for delivery to clients in most cases. Clearly, a better 10 bit codec with 4:4:4 color would be ideal, but my point in the first post was to provide options, and explain that each client will likely be different in their needs based on their final delivery intent, and that delivery via hard drives is a viable option.

I see what you guys mean about having a weak version of a REDCODE RAW decoder avalable for small producers hiring red camera owner/ops... but being a bit of a control freak myself, I'd rather make the gamma decisions myself before handing it off.

...my .02$

-W

 

[Antoine Baumann]

Labroprod: Bear with my computer ignorance here! RED RAW is what I was referring to. Is that the same as other forms of RAW?

Don't worry we are all learning a lot from this forum, and that is what so interesting here.
I think you can create any raw "format" you want. I mean REDCODE raw is one, but if you look to still cameras' raw format, even in the same brand there is different raw. With the RED camera, you will be able to record two differents raw (not including resolution difference), uncompressed raw and REDCODE raw.

Quoted: "Raw is a single channel format image, and therefore it is 3 times lighter than rbg. For exemple for 2k REDCODE rgb is going to be 3 times 7.5MBytes/sec (@24fps), so 22.5MBytes/sec."

So this appears to me to mean that it is better to ship disks to my client in 2K raw (maybe even 4K raw) in terms of disk space alone, than to ship in the RGB codec at 1080?

I think so. Like we said 4K raw is going to be around 133% of 2k/1080 rgb.

INcluding a copy of RED Cine (or they download it) So they can pick out the circled takes for import ingest. Is that right?

Not sure REDCINE will be free and downloadable, neither you would be allowed to give it to your client. For that info, we have to wait for Jim's comments.

I am not sure (again of what meant Rob,

The codec will do RAW to RGB processing as well.

but you might even be able to read "emualte" rgb for viewing out of the raw footage. So you edit in REDCODE raw, then go to REDCINE, make your gamma and other adjustment and process you EDL in REDCODE rgb (or other codec of your choise).

Also If I ship in RED RAW and they have the software to grade in RED RAW
(could this be only for RED RAW or software that addresses any raw format?)
They will have much more grading and correction lattitude this way.

I am not sure (make me the "not sure man" ) of what you are asking here. What I feel is you should first process the raw footage from the RED camera (should it be the uncompressed raw or the REDCODE raw) inside REDCINE and output in any format and codec your grading/compositing software or clients workflow might be. I do not see any better software than REDCINE to process your images, from the RED camera, in rgb or 4:4:4, then you make the final grade inside grading software like SpeedGrade, Final Touch, ...
I also think that REDCINE will only process raw footage from the RED camera, and not other raw.

Do you know if all grading tools will address RED RAW?

I am not sure ) ) any grading software accept REDCODE raw. Do you know grading tools that accept raw? If yes, may be there could be a work out for the REDCODE raw. But, again, what I feel is that you process in rgb inside REDCINE, let's say in REDCODE rgb, and then you do your final grading, let's say in Apple Final Touch, which should accept any quicktime codec install on your computer. Of course REDCODE raw is also a qt codec, but Final Touch must have a tool (or plugin) that deal with raw (in our case REDCODE raw).

 

[Nick Shaw]

Wade,
all I was suggesting was that the Firewire equipped deck would be the best way to transfer DVCPro HD material (or any DV format material for that matter) into FCP for Native codec editing. But as you said, the deck was not available to you at the time. Going via HD-SDI will always involve un-concatenated scaling, as HD-SDI only carries square pixels. I would see a possible benefit in capturing HD-SDI if you were capturing uncompressed, and laying off to a full rater format like HDCam SR. It just seems to me not the best way to go if you are scaling back down to 960 on capture.

I always try and preserve media in its native format where possible. Even when doing DV edits I work Firewire DV throughout, then convert the timeline to 10 bit un-compressed, render all, then lay off to Digi.

Antoine,
I think Rob meant that the REDCODE Quicktime codec will be able to read REDCODE RAW media as well as REDCODE RGB, and so any QuickTime application would see the RAW file as if it were RGB.