Scarlet & Thompson Viper

[tmca31]

Hi,

I'm curious to know how Scarlet stacks up against the Thompson Viper camera from the info that we know already re: Scarlet.

I know that the viper has RGB 4:4:4 10-bit possible at 1080p. Has there been any info on the colourspace of Scarlet? I saw that someone mentioned 4:2:0 @ 3K.

Anyhow just curious if anyone has any idea of the colourspace and is 10 bit possible with this camera?

Cheers

[RobinBalas]

Hi,

I'm curious to know how Scarlet stacks up against the Thompson Viper camera from the info that we know already re: Scarlet.

I know that the viper has RGB 4:4:4 10-bit possible at 1080p. Has there been any info on the colourspace of Scarlet? I saw that someone mentioned 4:2:0 @ 3K.

Anyhow just curious if anyone has any idea of the colourspace and is 10 bit possible with this camera?

Cheers

The Scarlet will as the RED ONE not be 4:4:4 or 4:2:0 as this relates to the files you make in post from RED and Scarlet - not the camera output. The camera outputs a RAW single chip bayer file - which can't be related to this way of describing the colourspace as you call it.
The chip will have 2x greens 1x blue 1x red, which for the Scarlet will be like 1.5K Green and 0.75 Blue and 0.75 Red - which is then interpolated into having some +/-70% real-life measured resolution of the chip sensor array. Forget comparisons to HDV's 4:2:0 or Uncompressed 4:4:4, it will be neither of them. Read up on the discussions on reduser forums on this.
MHO

[tmca31]

Great thanks for claering that up - Scarlet has RAW files hence chroma sampling doesn't apply.

Cheers

[ArrantAfferent]

I believe that the Thompson Viper has a CCD too.

[darkkelt]

I believe you will be able to create a 1080p RGB 4:4:4 image from scarlets raw files given the debayering from 3k. I think thats what scarlet aims to do give you very sharp very detailed full colour 1080p images. also since its based on a new sensor its likely to be more powerful than red one's sensor right now, more dynamic range, less skew , no rolling shutter issues

[shaocaholica]

Well, a camera that has a 3k bayer sensor and can create 16bit x 3channel 4:4:4 final output with very little visible compression should be a decent layman's analogy to the Scarlet.

Both the hypothetical camera mentioned above and 3k Redcode should have very similar fidelity in post. However, the hypothetical camera would also be wasting a lot of bandwidth in its 4:4:4 codec instead of using the raw sensor data.

[Andrew]

...no rolling shutter issues
That would be amazing if they could completely eliminate the rolling shutter problem. The RED One still has a slight wobble, doesn't it?

[tex098]

That would be amazing if they could completely eliminate the rolling shutter problem. The RED One still has a slight wobble, doesn't it?

I'm not sure if elimination is possible as that is inherent to these CMOS sensors but definitely would be nice if it handled camera motion without the wobble (jello-effect).

[Barry Green]

Rolling Shutter issues cover a wide variety of things. Skew/wobble is only one. Red has shown diligent effort in minimizing those effects. I doubt there's anything they can do about the strobe/HMI/flash issues, but they are actively working on minimizing the skew/wobble situation.

[Gordon JL]

Forgive me for not being technically savvy, but why is it that Scarlet will be "equivelant" to 4:2:0 in 3K, and maybe 4:4:4 in 1080, if the terms don't apply to it? So if I was to downrez the footage from 3K to 2K, I'd get better colorspace, like 4:4:4? Is the Red One similar in this regard? 4:2:0 equivelancy seems pretty low at 3K; is this an inheriant issue in CMOS bayer cameras, and is it something to worry about?

[Peter Majtan]

It's not about down-resing - it's about interpreting (converting) the RAW data. Graeme has managed to find an algorithm that translates the 3K-RAW into about 78% RGB 4:4:4 (not "pure" 4:4:4 as some would call it, but never the less). So that gives You about 2.35K RGB files. With room to further stabilize and/or reframe the footage, You will end up with pristine 2K and HD images that should blow all the 1080P cameras away...

[Dances With Cameras]

Yep, what I've read from Graeme's posts is that they're able to extract 78 % real luma resolution and ~ 52 % real chroma (color) resolution.

Luminance resolution is more important than chroma, cause the human eye is more sensitive to luminance than to color.

The true Luma rez of Scarlet will be ~2.35K and the true Chroma rez will be ~ 1.5K, which means that the 100 % true real resolution from the Scarlet [luma+chroma] will be ~1.5K.

And that [1.5K] would be equal to a 4:4:4 output, if we're talking in video and TV broadcast terms.

(Man, you can learn A LOT on these forums...)

I'm sure that the 2K will look beautiful and the difference with the true-full rez 1.5K will be negligible.

That's the whole point of 3K, cause RAW from Bayer needs to be demosaicked, which gives a slightly lower real resolution than the Bayer resolution.

A 3K RAW Bayer chip gives you a clean, rich 2K output.

Good enough [actually: great!] until the Foveon thingy becomes a real option.

My 2 pixels.

[Christoffer]

What happens when we edit the r3d files directly?
If we resize to 2K after the editing is done and it's time for colorgrading, would we end up with the same numbers?

Or must we still convert it all to 2K regular codec before editing in 2K?

[Dances With Cameras]

What happens when we edit the r3d files directly?
If we resize to 2K after the editing is done and it's time for colorgrading, would we end up with the same numbers?

Or must we still convert it all to 2K regular codec before editing in 2K?


That's a question that troubles me too, I think that the competent people here have to make this very clear.

I think that we'll need a very comprehensive and in-depth FAQ on these matters, once Scarlet is out.

[shaocaholica]

What happens when we edit the r3d files directly?


Im not sure you can. The only thing I can compare it to is Adobe DNG for still photos. If you edit a DNG that has bayer data and re export it to DNG, the new DNG will no longer have bayer data but RGB 4:4:4 data. I'm not sure if RED's R3D format supports both bayer and non bayer data.

[Peter Majtan]

Don't know about Windows, but on Mac every r3d file has automatically generated QuickTime reference files in 4K, 2K and 1K (if I remember well). These are just a place-holders (only few hundred kBs) and will "interpret" the RAW data in real-time. That way it doesn't matter how You edit Your footage - the final output is calculated directly from the r3d file, whether it is SD, HD, 2K or even 4K with all Your edits and grading applied. A fantastic non-destructive way...

[Peter Majtan]

Basically You can choose the best resolution for Your postproduction that Your HW & monitoring will support in real-time. This is in most cases 2K in pro-edit-suits and 1K in home-based studios...

[shaocaholica]

Right but I was assuming that Chris meant actually editing the source (which is a bad idea) but a reasonable question. I don't think its possible unless RED has release a codec that will re-write R3D files on your editing station and even then, if you've touched the pixels at all, you can't re-write the data as bayer RAW.

Does REDCINE allow trimming of R3Ds? Thats about all I think you'd want to do to your source footage. That and storing your REDCINE color/WB/exposure edits as meta data while still preserving the bayer RAW.

And as far as the proxies go, how do you go about color and exposure correcting the proxies? Surely you want to use a RED app so that your footage is ready to go before it hits your NLE. Do the QT ref files store any color correction meta data that is used by the RED decoder?

[Dances With Cameras]

You don't need full quality for editing, just for grading\finishing\final master.

[Eddy Robinson]

The workflow for RAW seems more like film than video in a lot of ways. Consider that until relatively recently an editor just cut for story and continuity and was working on some awful-looking moviola. Color timing was the cinematographer's problem, not the editor's.

DV has rather diluted the job of the editor (at least in the low-budget arena) in recent years since it has resulted in editors being expected to do color correction and a whole bunch of other technical things which have little to do with the craft of building the story from the images.

Also it makes for a lot of bad work habits...on the last project I worked on I kept having to remind the director/editor to stop wasting time with color correction when the picture wasn't close to being locked. This wasn't so much out of a desire to play with the CC tools, but from anxiety that the financial backers of the picture were going to look at the intermediate versions and be dissatisfied with the ugly colors. The farther away people are from the technical process, the more they imagine that post-production is just a matter of assembly, like lego. I've gotten into the habit of agreeing that this is so, but pointing out that you can't sell completed lego models in a toy store and saying that they should think of the editing cuts as prototypes rather than the final manufactured product.

[John Caballero]

Wouldn’t the r3d file situation as it stands now be comparable to the situation HVX 200 owners encountered with the MXF files at the beginning when no NLE would recognize them and you had to use the Raylight plug-in? Then the newer versions of Edius, Premiere, Final Cut, Avid eventually did and you can edit MFX files now natively in any of them? In the meantime reduser.net has a section that deals with this subject as it applies to the Red One at the moment.

[Peter Majtan]

Does REDCINE allow trimming of R3Ds? Thats about all I think you'd want to do to your source footage. That and storing your REDCINE color/WB/exposure edits as meta data while still preserving the bayer RAW.

Yes - You can trim and resize (amongst other things), but You can't export new set of RAW files. It does however support OpenEXR - which will give You a lot of room to work with - but not in a real time...

And as far as the proxies go, how do you go about color and exposure correcting the proxies? Surely you want to use a RED app so that your footage is ready to go before it hits your NLE. Do the QT ref files store any color correction meta data that is used by the RED decoder?

COLOR is also non-destructive. You can "CC" the proxies, but while outputting the final file the CC will be applied to the RAW files.

What I normally do is to take the source files and give them primary CC. Then output uncompressed files stabilized, cropped and resized to my master resolution - usually 2K or HD. Then I will run it through FCS and after the final edit and FX are done I will do "master" CC...

[Christoffer]

Chris meant actually editing the source (which is a bad idea)


Not really... save the original files and have copies of the r3d files that you work with. Then you do colorgrading of the entire finished movie instead of each individual clip. I think it's rather pointless to colorcorrect before editing, because the amount of work with that is too much. Better to colorcorrect/grade the material when it's edited so that you output a master that's already edited.

And if the editing suite develops a way to colorgrade the RAW files within the editing it's even better.

[shaocaholica]

Yeah, it would be most ideal to color grade the RAW nondestructively and without using any intermediate files either. That way, you don't have to make copies of the R3Ds, you just store your CC edits in another super small file. This is how its down with RAW still images. You never have to make a copy of the original file, just copies of all your edits(as instructions not pixel data). Just store your CC info as a separate file or as metadata and have the CC applied on the fly by the RED decoder.

It would be great if the NLE could highlight the clips to be CC after you're done editing. Then you can work on a clip by clip basis and also without any intermediate files but filtered down to only what is being used.

[Peter Majtan]

Guys the QuickTime reference files are just that - a reference. It is not a copy of the RAW file. It is a reference programming instruction telling QT to read into a memory the RAW file at a given size and then behave as if it was a "real" file. The sizes are in kilobytes, regardless of how many GB Your r3d file is. Just think of it as a place-holder...

[Peter Majtan]

It would be great if the NLE could highlight the clips to be CC after you're done editing. Then you can work on a clip by clip basis and also without any intermediate files but filtered down to only what is being used.

This is exactly what FCP and COLOR does... You actually get to see the entire time-line from FCP inside COLOR with all the edits and transitions... When You decide to output Your final files all the CC will be applied to the r3d RAW file and exported as a independent master file - if that is what You want... Or just go back to FCP and do some more adjustments. Back and forth as many times as You like. When You are done - export...